Pipenv: लॉक करना धीमा है (और अनावश्यक डाउनलोड करता है)

@colllin क्या आपने यह देखने के लिए जांच की है कि सर्वर से संपर्क करने वाले पाइप कमांड - जैसे pip search (मुझे लगता है) - भी धीमे हैं?

मुझे समान व्यवहार दिखाई देता है, लेकिन यह एक ज्ञात समस्या और नेटवर्क पर निर्भर है। किसी कारण से, मेरे कार्य नेटवर्क से pypi.org तक पहुंच अविश्वसनीय रूप से धीमी है लेकिन यह मेरे होम नेटवर्क से सामान्य रूप से तेज़ है। मुझे लगता है कि लॉकिंग हुड के तहत बहुत सारे पीआईपी लेनदेन करता है, इसलिए सर्वर तक धीमी पहुंच ऑपरेशन को बहुत धीमा कर देती है।

संपादित करें: यह भी हो सकता है कि आपके पास हल करने के लिए बहुत सारी उप-निर्भरताएं हों - एक बार बनाया गया पर्यावरण कितना बड़ा है (उदाहरण के लिए आपके पाइपफाइल में कितने शीर्ष-स्तरीय पैकेज हैं, और कितने पैकेज pip list द्वारा वापस किए गए हैं) एक बार पर्यावरण बूटस्ट्रैप हो गया है)?

विचारशील प्रतिक्रिया के लिए धन्यवाद।

pip search मेरे लिए विशेष रूप से तेज़ या धीमा नहीं है... ~1 सेकंड?

मेरे डोमेन ज्ञान की कमी के लिए मुझे क्षमा करें: क्या इसे वास्तव में खोज को पिप करने की आवश्यकता है? क्या इसने सब कुछ स्थापित नहीं किया? क्या इसे सिर्फ यह लिखने की जरूरत नहीं है कि पहले से क्या स्थापित है? या... चूंकि यह वैसे भी लॉक फ़ाइल के अस्तित्व को सुनिश्चित करता है, क्या यह ऐसा कर सकता है क्योंकि यह संकुल को

मैं अनुमान लगा रहा हूँ... pipenv हुड के नीचे पाइप का उपयोग करता है? तो स्थापना प्रक्रिया एक ब्लैक बॉक्स है, और यह अपने स्वयं के पाइप प्रश्नों ~ एक पाइप खोज ~ किए बिना क्या स्थापित किया गया था/के निर्भरता ग्राफ को नहीं जान सकता है?

संपादित करें: इस विशेष रेपो में 1 शीर्ष-स्तरीय पैकेज है, और ~ 65 पैकेज pip list द्वारा लौटाए गए हैं।

मैं परियोजना में योगदानकर्ता नहीं हूं और फिलहाल मैं सभी बारीकियों को नहीं जानता, लेकिन मेरी समझ यह है कि लॉकिंग चरण वह है जहां सभी निर्भरताएं हल हो जाती हैं और पिन हो जाती हैं। इसलिए यदि आपके पास ~ 65 निर्भरता के साथ एक शीर्ष-स्तरीय पैकेज है, तो यह लॉकिंग चरण के दौरान है कि उस पहले पैकेज की सभी निर्भरताएं (पुनरावर्ती) खोजी जाती हैं, और फिर निर्भरता ट्री का उपयोग यह हल करने के लिए किया जाता है कि किन पैकेजों को स्थापित करने की आवश्यकता है और (शायद) उन्हें किस मोटे क्रम में स्थापित किया जाना चाहिए। अंतिम भाग के बारे में निश्चित नहीं है।

यदि आप बिना लॉकफाइल के पिपफाइल से पाइप इंस्टाल करते हैं, तो आप देखेंगे कि यह पैकेज को वेनव में स्थापित करने से पहले लॉकिंग चरण करता है। इसी तरह यदि आपके पास लॉकफाइल है लेकिन यह पुराना है। मुझे संदेह है कि --deploy विकल्प का उपयोग करके लॉकफाइल और इंस्टॉल करना तेज़ होगा, जैसा कि --no-lock विकल्प होगा; पूर्व मामले में आपको एक त्रुटि मिलती है यदि लॉकफाइल पुराना है, बाद में आप शीर्ष-स्तरीय पैकेज (घोषित पर्यावरण) और सभी पैकेजों के वास्तविक स्थापित (लॉक) वातावरण के तार्किक विभाजन को खो देते हैं। कम से कम मैं इसे इस तरह समझता हूं।

पिपेनव हुड के नीचे पाइप का उपयोग करता है या नहीं - मुझे लगता है कि यह करता है - इसे अभी भी पैकेज निर्भरताओं और इसी तरह के बारे में पीपीआई सर्वर (एस) से जानकारी प्राप्त करने की आवश्यकता है, इसलिए पीआईपी खोज के बारे में मेरा प्रश्न कितनी तेजी से या के लिए एक प्रॉक्सी था पीपीआई सर्वर के लिए अपना रास्ता धीमा करना उस तंत्र के बारे में प्रत्यक्ष निहितार्थ से है जिसके द्वारा पिपेनव अपना काम करता है।

पिपेनव में डिपेंडेंसी ट्री को लॉक करने के लिए आवश्यक समय की तुलना करना और pip install -r requirements.txt का उपयोग करके एक नए वेनव में आवश्यकताओं को स्थापित करना एक दिलचस्प प्रयोग हो सकता है। मुझे लगता है कि उन्हें निर्भरता समाधान चरण के दौरान बहुत समान चीजें करनी चाहिए।

क्या हमने कहीं स्थापित किया है कि बीटीडब्ल्यू अनावश्यक डाउनलोड हो रहे हैं? मुझे संदेह है कि ऐसा ही है, लेकिन इसे साबित करना वास्तव में मददगार होगा

एफवाईआई pip install -r requirements.txt तुलना एक निर्भरता ग्राफ को लॉक करने में लगने वाले समय से तुलना के बिंदु के रूप में जानकारीपूर्ण नहीं होने वाला है। पिप वास्तव में एक समाधानकर्ता नहीं है, किसी भी वास्तविक अर्थ में नहीं। मुझे लगता है कि मैं अंतर का वर्णन कर सकता हूं। जब पाइप आपके requirements.txt स्थापित करता है, तो यह इस मूल प्रक्रिया का पालन करता है:

• सूचीबद्ध पहली आवश्यकता खोजें
  
  
  
  • इसकी सभी निर्भरताएं खोजें
  
  
  • उन सभी को स्थापित करें
  
  
• सूचीबद्ध दूसरी आवश्यकता खोजें
  
  
  
  • इसकी सभी निर्भरताएं खोजें
  
  
  • उन सभी को स्थापित करें
  
  
• सूचीबद्ध तीसरी आवश्यकता खोजें
  
  
  
  • इसकी सभी निर्भरताएं खोजें
  
  
  • उन सभी को स्थापित करें
  
  

यह बहुत तेज़ हो जाता है क्योंकि पीआईपी वास्तव में परवाह नहीं करता है अगर _पैकेज 1_ की निर्भरता _पैकेज 3_ की निर्भरताओं के साथ संघर्ष करती है, तो यह सिर्फ _पैकेज 3_ में स्थापित होती है, इसलिए आपको यही मिलता है।

पिपेनव एक अलग प्रक्रिया का पालन करता है - हम एक संकल्प ग्राफ की गणना करते हैं जो आपके द्वारा निर्दिष्ट निर्भरता के _all_ को संतुष्ट करने का प्रयास करता है, इससे पहले कि हम आपका वातावरण बनाएं। इसका मतलब है कि हमें यह निर्धारित करने के लिए डाउनलोड करना, तुलना करना, और कई बार _बिल्डिंग_ पैकेज भी शुरू करना होगा कि आपका वातावरण आखिरकार कैसा दिखना चाहिए, इससे पहले कि हम इसे स्थापित करने की वास्तविक प्रक्रिया शुरू कर दें (इस पर बहुत सारे ब्लॉग पोस्ट हैं कि यह क्यों है पायथन में मामला है इसलिए मैं इसमें और अधिक नहीं जाऊंगा)।

उस समाधान प्रक्रिया के प्रत्येक चरण को हैश की आवश्यकता के कारण अधिक कम्प्यूटेशनल रूप से महंगा बना दिया जाता है, जो कि एक सर्वोत्तम अभ्यास है। हम आने वाले पैकेजों को प्राप्त करने के बाद हैश करते हैं, फिर हम उनकी तुलना हैश से करते हैं जो पीईपीआई ने हमें बताया था कि हमें उम्मीद करनी चाहिए, और हम उन हैश को लॉकफाइल में स्टोर करते हैं ताकि भविष्य में, जो लोग एक समान वातावरण बनाना चाहते हैं वे ऐसा कर सकें संविदात्मक गारंटी कि वे जिन पैकेजों से निर्माण करते हैं वे वही हैं जो आपने मूल रूप से उपयोग किए थे।

पिप खोज इनमें से किसी के लिए भी एक खराब बेंचमार्क है, वास्तव में इस काम को करने के लिए पाइप का कोई भी टूलिंग एक खराब बेंचमार्क है - हम इसके प्रत्येक टुकड़े के लिए पाइप का उपयोग करते हैं, लेकिन इसे कंसर्ट में और कई निर्भरताओं में एक साथ रखकर बनाने और प्रबंधित करने के लिए वातावरण और रेखांकन वह जगह है जहाँ पिपेनव का मूल्य जोड़ा जाता है।

स्पष्टीकरण का एक बिंदु - एक बार जब आप पूर्ण निर्भरता ग्राफ को हल कर लेते हैं, तो स्थापना आदेश अब और मायने नहीं रखना चाहिए। हुड के तहत हम वास्तव में हर स्थापना के लिए --no-deps करते हैं।

एक छोटे से साइड-नोट के रूप में, पाइप खोज वर्तमान में पाइप के टूलिंग का एकमात्र टुकड़ा है जो अब बहिष्कृत XMLRPC इंटरफ़ेस पर निर्भर करता है, जो अप्राप्य और बहुत धीमा है। यह किसी भी अन्य ऑपरेशन की तुलना में हमेशा धीमा रहेगा।

लॉकिंग numpy (और कुछ नहीं) मेरी मशीन पर 220 सेकेंड लेता है (नीचे देखें)। ऐसा लगता है कि अधिकांश समय 200 एमबी से अधिक डेटा डाउनलोड करने में व्यतीत होता है, जो कि काफी हैरान करने वाला है, क्योंकि पूरे सुन्न स्रोत में 4 एमबी है। हालांकि स्पष्ट रूप से भले ही वह तत्काल था, फिर भी वास्तविक प्रसंस्करण के 25 एस हैं, और यहां तक ​​​​कि कुछ हैश की गणना करने के लिए यह अत्यधिक लगता है। बाद के लॉकिंग, Pipenv.lock को हटाने के बाद भी, 5 s लगते हैं।

11:46 ~/Co/Ce/torchdft time pipenv install
Creating a virtualenv for this project…
Using /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6 (3.6.5) to create virtualenv…
⠋Already using interpreter /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6
Using real prefix '/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python3.6
Also creating executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t
Creating a Pipfile for this project…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (ca72e7)!
Installing dependencies from Pipfile.lock (ca72e7)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 0/0 — 00:00:00
To activate this project's virtualenv, run the following:
 $ pipenv shell
        7.81 real         6.39 user         1.64 sys
11:46 ~/Co/Ce/torchdft time pipenv install numpy --skip-lock
Installing numpy…
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/f6/cd/b2c50b5190b66c711c23ef23c41d450297eb5a54d2033f8dcb3b8b13ac85/numpy-1.14.5-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
Installing collected packages: numpy
Successfully installed numpy-1.14.5

Adding numpy to Pipfile's [packages]…
        4.97 real         2.88 user         1.81 sys
11:46 ~/Co/Ce/torchdft time pipenv lock --verbose
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done

Locking [packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:
  numpy

Finding the best candidates:
  found candidate numpy==1.14.5 (constraint was <any>)

Finding secondary dependencies:
  numpy==1.14.5 not in cache, need to check index
  numpy==1.14.5             requires -
------------------------------------------------------------
Result of round 1: stable, done

Updated Pipfile.lock (4fccdf)!
      219.24 real        25.14 user         5.77 sys

Numpy अब काफी तेज होना चाहिए (मैं वास्तव में एक परीक्षण मामले के रूप में आपके उदाहरण का उपयोग कर रहा हूं!) मेरे सबसे हालिया परीक्षण के अनुसार, मेरे पास एक वीएम पर ठंडे कैश पर ~ 30 के दशक में था।

क्या आप नवीनतम रिलीज़ के साथ किसी सुधार की पुष्टि कर सकते हैं?

मेरे लिए भी इसमें काफी सुधार हुआ है। मैं अब बहुत तेज़ कनेक्शन पर बैठा हूं, और 14 सेकेंड जितना कम हो गया, लेकिन वह तब था जब डाउनलोडिंग 30 एमबी/सेकेंड पर चली गई। numpy के स्रोत कोड की एक प्रति के अलावा क्या डाउनलोड किया जा रहा है?

मुझे लगता है कि हम अनावश्यक पहियों को डाउनलोड कर रहे हैं (निश्चित नहीं)। हम पहले से ही स्थिति का मूल्यांकन कर रहे हैं।

मैंने अपने Pipfile.lock को एक fe परिवर्तनों को अनइंस्टॉल करके काफी बदल दिया है और अब इसे एक अलग मशीन पर तैनात करना फ्रीजिंग है। इसके लिए कोई विशेष फिक्स?

यह अनुशंसा नहीं की जाती है कि आप अपने लॉकफ़ाइल को मैन्युअल रूप से संपादित करें। अधिक जानकारी के बिना मदद करना संभव नहीं है। कृपया एक अलग मुद्दा खोलें।

यदि आप पिपेनव लॉक के प्रदर्शन को बेंचमार्क करना चाहते हैं, तो आपको अपनी निर्भरता में pytmx जोड़ने का प्रयास करना चाहिए ...
पिपेनव लॉक हमारे लिए 1 घंटे या उससे अधिक समय लेता था (हमारे पास बहुत धीमा इंटरनेट है), और pytmx को हटाने के बाद, हम लगभग 5 मिनट तक नीचे आ गए और अंत में पिपेनव अधिक उपयोगी है।
मुझे पता है कि pytmx एक बड़ा पैकेज है क्योंकि यह एक बड़ा मोनोलिथिक लिब है और यह opengl/pygame और अन्य संबंधित चीजों पर निर्भर करता है, लेकिन इसे pipenv लॉक करने में 1 घंटा नहीं लगना चाहिए, चाहे पैकेज कितना भी बड़ा क्यों न हो

मेरे लिए एक घंटा नहीं लगता

$ cat Pipfile
[packages]
pytmx = "*"

$ time pipenv lock --clear
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock (eb50ab)!

real    0m2.827s
user    0m2.287s
sys 0m0.390s

इसके अलावा PyTMX, PyPI पर 20kb से कम है, और केवल छह पर निर्भरता है (जो कि बहुत छोटा है), इसलिए नेटवर्किंग कोई समस्या नहीं होनी चाहिए। आपके वातावरण में कुछ और होने की संभावना है।

आप सही कह रहे हैं कि यह मेरे विचार से छोटा है, यह स्पष्ट रूप से pygame पर निर्भर नहीं है और इस तरह, यह सुनिश्चित नहीं है कि यह इतना लंबा क्यों ले रहा था!
मैं अधिक जानकारी खोजने की कोशिश करूंगा लेकिन मेरे पास एक शीर्ष सीपीयू और एसएसडी है इसलिए मुझे अभी भी लगता है कि समस्या हमारे धीमे इंटरनेट से संबंधित है

@techalchemy मैंने फ़ाइल को मैन्युअल रूप से संपादित नहीं किया। मैंने pipenv uninstall package_name का उपयोग करके बहुत सी निर्भरताओं को अनइंस्टॉल किया और बाद में इसे सर्वर पर चलाया। यह बहुत देर तक लॉक अवस्था में रहा।

मुझे इस चर्चा पर अंधेरे में यादृच्छिक शॉट्स के साथ ऊर्जा खर्च करने में कोई दिलचस्पी नहीं है। कृपया एक प्रतिलिपि प्रस्तुत करने योग्य परीक्षण केस प्रदान करें।

यहाँ मुझे आशा है कि एक प्रतिलिपि प्रस्तुत करने योग्य परीक्षण मामला है
https://github.com/Mathspy/tic-tac-toe-NN/tree/ab6731d216c66f5e09a4dabbe383df6dc745ba18

करने का प्रयास
pipenv install
इस लॉक-लेस रिपोजिटरी में अब तक 700 एमबी या उससे अधिक डाउनलोड किया गया है, जबकि यह प्रदर्शित होता है
Locking [packages] dependencies...

थोड़ी देर में हार मान लेंगे और --skip-lock साथ फिर से चलाएंगे जब तक कि यह ठीक न हो जाए

मैंने देखा कि lock वास्तव में धीमा था और files.pythonhosted.org से बड़ी मात्रा में डेटा डाउनलोड किया गया था, जो scipy flask आदि पर निर्भर एक छोटी परियोजना के लिए 800MB से अधिक है।

इसलिए मैंने files.pythonhosted.org पर किए गए अनुरोधों को सूँघ लिया, और यह पता चला कि पाइप या पिपेनव पूरी तरह से अनावश्यक डाउनलोड कर रहे थे, जो lock दर्दनाक रूप से धीमा कर देता है।

उदाहरण के लिए, एक ही संस्करण numpy को कई बार पूर्ण रूप से डाउनलोड किया गया था। और इसने विंडोज़/लिनक्स के लिए पहियों को डाउनलोड किया, हालाँकि मैं एक मैक का उपयोग कर रहा था।

मेरा सेटअप:

$ pipenv --version
pipenv, version 2018.05.18

$ pip -V
pip 18.0 from /usr/local/lib/python2.7/site-packages/pip (python 2.7)

क्या अतिरिक्त पिपफाइल यहां डिबगिंग के लिए सहायक हैं?

सबसे अधिक संभावना है @AlJohri , चल रही प्रक्रियाओं/ताले/आईओ के बारे में कोई जानकारी भी मदद करेगी

करीब 5 मिनट पहले ही यहां फंसे रहे। पहले सोचा था कि यह किसी प्रकार की पाइप स्थापित समस्याएँ हो सकती हैं और होमब्रे के माध्यम से सब कुछ नए सिरे से स्थापित किया है, लेकिन फिर भी वही समस्या है। कोई विचार क्यों?

अंत में लगभग 6 - 7 मिनट के बाद समाप्त हुआ। पायथन और पिपेनव के लिए बहुत नया है, इसलिए डिबगिंग के लिए आवश्यक फाइलों को खोजने के बारे में थोड़ी मदद बहुत अच्छी होगी! :)

यह इस बिंदु पर बहुत बुरा है कि मैं नए पायथन libs स्थापित करने या मौजूदा लोगों को अपग्रेड करने से डरता हूं।

निर्माता की एक वार्ता को देखने के बाद, मैंने pipenv का उपयोग करने का निर्णय लिया। लेकिन यह बहुत धीमा है।

आपकी अंतर्दृष्टिपूर्ण प्रतिक्रिया के लिए धन्यवाद।

@techalchemy अगर ऐसा कुछ है जो मैं मदद करने और इसे ठीक करने के लिए कर सकता हूं। मुझे योगदान देकर बहुत खुशी हो रही है।

मैंने देखा कि lock वास्तव में धीमा था और files.pythonhosted.org से बड़ी मात्रा में डेटा डाउनलोड किया गया था, जो scipy flask आदि पर निर्भर एक छोटी परियोजना के लिए 800MB से अधिक है।

मुझे संदेह है, हालांकि निर्णायक सबूत नहीं है, कि scipy बहुत लंबे pipenv लॉक समय के साथ सहसंबद्ध है।

कई बार वास्तव में दर्द होता है, मैं PyPDF2 और टेक्स्ट को स्थापित कर रहा हूं; पिपेनव को लॉक होने में ~10 मिनट लगे।

पिपेनव का धीमापन वास्तव में हमारे लिए देव प्रक्रिया में बाधा डालता है। मैं अब सभी को सलाह देता हूं कि जब तक यह समस्या हल नहीं हो जाती, तब तक pip + virtualenv से चिपके रहें।

इस पर कोई भी समाचार? मदद करने का कोई तरीका?
https://github.com/pypa/pipenv/issues/1914 . का धोखा

/ संपादित करें: बीटीडब्ल्यू, pipenv install लॉकफाइल में संस्करणों को अपडेट क्यों करता है? o.Ò मैंने इसे लॉक करने का समय समाप्त होने के बाद ही चलाया और अब जब मैं नई लॉक फ़ाइल को देखता हूं तो मुझे लगता है कि पांडा को 0.23.4 से 0.24.0 तक अपडेट किया गया था, numpy 0.16.0 से 0.16.1, आदि ... जब तक मैंने pipenv update नहीं किया तब तक ऐसा होने की उम्मीद न करें ...

मुझे लगता है कि यह जल्दी से इंस्टॉल हो जाता है और धीरे-धीरे लॉक हो जाता है, इसलिए जैसे ही आपको Installation Succeeded संदेश मिलता है, काम करना जारी रखना अच्छा है ... जब तक कि आप कुछ और इंस्टॉल नहीं करना चाहते ...

या लॉक फ़ाइल को कुछ रेपो में धकेलने की आवश्यकता है।

क्या install वैसे भी लॉक से पहले होना चाहिए, यह देखते हुए कि lock पहले से ही एक अलग कमांड है? इस बीच में install विकल्प विवरण में यह निर्दिष्ट होना चाहिए कि लॉकिंग भी होती है, और शायद --skip-lock की भी सिफारिश करें।

साथ ही, इस मुद्दे को पिन करने के बारे में क्या?

पिपेनव वास्तव में एक अद्भुत उपकरण है और मैं इसकी सिफारिश करता था, लेकिन 8 मॉड्यूल वाला एक प्रोजेक्ट लॉक नहीं हो सकता ... यह बस समय समाप्त हो गया। इस मुद्दे को सुलझाने में कोई दिलचस्पी नहीं दिख रही है और यह बहुत निराशाजनक है। मैंने पढ़ा है कि अब आप pypy से डाउनलोड किए बिना निर्भरता प्राप्त कर सकते हैं, क्या यह इस मुद्दे के लिए एक समाधान है? यहां उस विकल्प के बारे में कोई बात नहीं दिख रही है। फिलहाल उपकरण मेरे उद्देश्यों के लिए अनुपयोगी है।

pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') pipenv lock -r 87.22s user 18.57s system 11% cpu 15:02.77 total

यह इस परियोजना की मुख्य प्राथमिकता कैसे नहीं है? पिपेनव इतना धीमा है कि यह काफी अनुपयोगी है। न केवल कुछ असामान्य पक्ष मामलों का उपयोग करता है यह हमेशा सुपर धीमा होता है।

अंडर-द-हूड क्या हो रहा है, इसके बारे में बहुत कुछ जानने के बिना, मैं सोच रहा था कि यह निर्भरता ग्राफ के स्थानीय कैश के साथ अच्छी तरह से हल किया जा सकता है।

इसके बारे में सोचें: यदि हम उस पैकेज को कैश करते हैं x-1.2.3 पर निर्भर करता है y>=3.4 , तो हम स्थानीय रूप से बहुत सारे काम कर सकते हैं जो वर्तमान में एक बार में पैकेज डाउनलोड करने, उनका विस्तार करने और निर्भरता की जाँच करने में किया जाता है। . lock चरण तब उतना आसान होगा जितना:

• पिपफाइल की तुलना कैशे से करें और सुनिश्चित करें कि हमारे पास वह सब कुछ है जो हमें चाहिए।
• यदि नहीं, तो कुछ भी नया डाउनलोड करें और वहां निर्भरता की गणना करें
  
  
  
  • परिवर्तनों को कैश करें
  
  
• इंस्टॉल।

हर मामले में, जबकि पहली बार धीमा हो सकता है, बाद के ताले दर्द रहित होंगे, नहीं?

मैंने अभी एक छोटी परियोजना के लिए पाइप के बजाय पिपेनव का उपयोग करने का निर्णय लिया है। पहली चीज़ जो मैंने की वह थी pipenv install -r requirements.txt । यह अब लगभग 10 मिनट के लिए निर्भरताओं को बंद कर रहा है। इसलिए, मैं पिप पर वापस जा रहा हूँ।

दोस्तों, यह समस्या आपको बहुत सारे उपयोगकर्ताओं की कीमत चुकानी पड़ रही है। मैं इसे शीघ्रता से संबोधित करने का प्रस्ताव करता हूं।

मेरे मामले में सर्वर पर निर्भरता स्थापित करना सर्वर को घंटों तक लटका देता है। मैं 1 जीबी रैम के साथ एडब्ल्यूएस ईसी 2 इंस्टेंस t2.micro का उपयोग कर रहा हूं। इतनी रैम कुछ निर्भरता वाले एकल एप्लिकेशन के लिए पर्याप्त है लेकिन इंस्टॉलेशन सभी मेमोरी लेता है और सर्वर को पुनरारंभ करके इसे काम करने का केवल एक ही तरीका है।

यह समस्या इतने वर्षों से लंबित है और इसका कोई समाधान नहीं किया गया है। मैं देखता हूं कि कई मुद्दे बिना किसी समाधान के बंद हो रहे हैं।

इतना अच्छा उपकरण उपेक्षित हो रहा है। मैं इस मुद्दे से सदस्यता समाप्त कर दूंगा क्योंकि मुझे लगता है कि यह कभी हल नहीं होगा। कोंडा जैसी किसी चीज़ से चिपके रहेंगे या वर्चुअलएन्व का उपयोग करके इसे मैन्युअल रूप से करेंगे।

मान लीजिए मैं https://github.com/sdispater/poetry एक शॉट दूंगा:|

क्या कोई व्यवस्थापक कृपया इस थ्रेड को टिप्पणियों के लिए बंद कर सकता है? ऐसा लगता है कि चर्चा में कोई उपयोगी अतिरिक्त सामग्री नहीं जोड़ी जा रही है।

समस्या को ठीक करने की दिशा में काम पर नज़र रखने वाले टिकट की सदस्यता लेने में मुझे खुशी होगी।

धन्यवाद!

मुझे संदेह है कि 99% लोग इस उपकरण का उपयोग कर रहे हैं और इस धागे पर शिकायत करने वाले प्रोग्रामर हैं। रोने के बजाय, अपना समय वहीं लगाएं जहां आपका मुंह है और एक पीआर जमा करें।

हैलो @idvorkin ,

मैंने एक बार कोशिश की है।
मामूली सुधार के विलय को प्राप्त करने में सप्ताह लग गए।
वास्तविक फिक्स आकार के साथ चर्चाओं की मात्रा की तुलना करें।

मैं निश्चित रूप से इस परियोजना में कोई और सुधार प्रस्तुत नहीं करना चाहता।

तो आपकी सलाह उतनी व्यवहार्य नहीं है जितना आप मान सकते हैं।

@Jamim कई उपयोगकर्ताओं की ओर से (और मुझे व्यवस्थापकों पर भी संदेह है), आपके योगदान के लिए धन्यवाद। मैंने आपका पीआर पढ़ा, और मुझे निराशा के साथ सहानुभूति हो सकती है। हालाँकि, मुझे इस पर w/ @techalchemy से सहमत होना होगा:

बेशक हम उस पुस्तकालय की परवाह करते हैं जिसे हम बनाए रखते हैं, लेकिन मैं सुझाव दूंगा कि सकारात्मक बातचीत करने के लिए वाक्यांश शायद सबसे प्रभावी तरीका नहीं है।

मैं व्यवस्थापकों से कभी नहीं मिला, लेकिन अगर वे मेरे (और शायद आप) जैसे कुछ भी हैं तो वे व्यस्त जीवन वाले इंसान हैं जिनके जीवन इस परियोजना पर खर्च करने के लिए ऊर्जा होने से पहले ही प्रतिबद्धताओं से भरे हुए हैं।

इसी तरह, मैं शर्त लगाता हूं कि यदि आपने (या किसी और ने) प्रदर्शन की समस्या को ठीक कर दिया है, तो आपके पास ऐसे कई लोग होंगे जो आपको इसे विकसित करने, परीक्षण करने, मर्ज करने में मदद करेंगे, या यदि आवश्यक हो (और मुझे अत्यधिक संदेह है) एक कांटा बनाएं .

मैं उस समय के लिए आभारी हूं जब इस परियोजना के डेवलपर्स इस पर खर्च कर रहे हैं, लेकिन मेरा सुझाव है कि इसे बोल्ड में चेतावनी दी जानी चाहिए कि यह परियोजना अभी तक उपयोगकर्ता प्रशंसापत्र के ऊपर README.md , वर्तमान में यह है लोगों को अपने वर्तमान pip/virtualenv स्टैक को pipenv से बदलने के लिए कीमती समय बिताने के लिए गुमराह करना जब तक कि उन्हें इस धीमी लॉकिंग के बारे में पता नहीं चल जाता और वे समझते हैं कि वे इसका उपयोग नहीं कर सकते हैं।

जब तक उन्हें इस धीमी लॉकिंग के बारे में पता नहीं चल जाता और वे समझ जाते हैं कि वे इसका उपयोग नहीं कर सकते।

जबकि मुझे गति प्राप्त करने में बहुत खुशी होगी क्योंकि यह वास्तव में बहुत धीमी है, इस तरह के अतिशयोक्ति की कोई आवश्यकता नहीं है।

मैं हर दिन ठीक पिपेनव का उपयोग कर रहा हूँ। वर्कफ़्लो में सुधार यह सामयिक धीमेपन को बहुत अधिक प्रदान करता है। उदाहरण के लिए स्क्रिप्ट चलाने के विपरीत, लॉकिंग केवल कुछ ऐसा नहीं है जो मैं हर समय करता हूं।

आप कितनी बार लॉक करते हैं कि यह वास्तव में ऐसी समस्या बन जाती है जो आपको लगता है कि आप इसका उपयोग नहीं कर सकते हैं? :मुह खोलो:

@bochecha मेरा कथन आपकी राय में अतिशयोक्तिपूर्ण हो सकता है, लेकिन यह मेरे अनुभव के आधार पर एक तथ्य है, मैंने कुछ सहकर्मियों से पिपेनव के बारे में सुना, आज मैंने एक पुरानी परियोजना को अपडेट करने की कोशिश की, इसकी निर्भरता को अपडेट किया, आदि मैंने सोचा कि पाइप/वर्चुअलएन्व से अपडेट करने देता है pipenv अद्यतन प्रक्रिया के भाग के रूप में। मुझे एक निर्भरता को अद्यतन करना था, जांचें कि चीजें इसके साथ कैसे काम करती हैं, यदि आवश्यक हो तो कोड के कुछ हिस्सों को अपडेट करें और फिर एक और निर्भरता को अपडेट करें, हर बार जब मैं pipenv install <something> भागा तो मुझे एक हास्यास्पद लंबे समय तक इंतजार करना पड़ा, पहले मुझे लगा कि यह गणना कर रहा है कुछ और यह इसे भविष्य के लिए कैश कर देगा क्योंकि मुझे विश्वास नहीं हो रहा था कि यह उत्पादन के लिए तैयार पैकेज मैनेजर होने का दावा करने में एक समस्या है। ~10वां पैकेज स्थापित करने के बाद मैंने इसके बारे में खोजना शुरू किया और मुझे यह धागा मिला, मैंने Pipfile और Pipfile.lock हटा दिया और अपने पीआईपी/वर्चुअलएन्व वर्कफ़्लो पर वापस चला गया। मैं कविता को आजमाने के लिए ललचा रहा था लेकिन मैं एक और घंटा जोखिम में नहीं डाल सका।

उदाहरण के लिए जेएस समुदाय में यह चीजें होती हैं, लेकिन मुझे पायथन समुदाय में इसकी उम्मीद नहीं है, हमारे समुदाय में इस तरह की समस्याएं नहीं हैं और हमें इससे बचने की कोशिश करनी चाहिए, README.md में एक अस्वीकरण से बचा जा सकता है यह असुविधा इसलिए मैंने अपनी टिप्पणी में इसका सुझाव दिया। यह आज मेरा समय बचा सकता है और मुझे लगता है कि यह अन्य नवागंतुकों के लिए समय बचाएगा और उन्हें इस परियोजना के साथ कोई बुरा अनुभव नहीं होगा ताकि वे संभावित भविष्य के उपयोगकर्ताओं के रूप में बने रह सकें।

मैं सासन से सहमत हूं। हर कोई इस मुद्दे से समान रूप से प्रभावित नहीं होता है लेकिन हममें से कुछ बहुत बुरी तरह प्रभावित हुए हैं। मैंने ओपन सोर्स प्रोजेक्ट बनाए हैं जो वास्तव में पूरी तरह कार्यात्मक या उत्पादन के लिए तैयार नहीं थे और जब यह मामला था तो मैंने उस पर एक अस्वीकरण डाल दिया ताकि मैं लोगों का समय बर्बाद न करूं अगर वे धक्कों के लिए तैयार नहीं हैं।

मैं इस परियोजना पर काम करने वाले लोगों के लिए पागल नहीं हूं, लेकिन मैं उस व्यक्ति पर थोड़ा पागल हूं, जिसने इसके बारे में सार्वजनिक रूप से बात की, इसे 0 अस्वीकरण के साथ एक महान उपकरण के रूप में बेच दिया। नतीजतन, मैंने अपना बहुत सारा कीमती समय एक उपकरण को काम करने की कोशिश में बर्बाद कर दिया, लंबे समय में समय बचाने की उम्मीद में, लेकिन मुझे पाइप और अपनी स्क्रिप्ट पर वापस जाना पड़ा, क्योंकि पिपेनव ने काम नहीं किया मेरे समय और बैंडविड्थ विवश वातावरण में।

हर बार जब मैं पिपेनव इंस्टॉल चलाता हूं

जब आप इसे पिपेनव में ले जाने का प्रयास करते हैं तो क्या आप अपने मौजूदा प्रोजेक्ट से केवल एक बार लॉक/इंस्टॉल करने के लिए pipenv install -r requirements.txt बारे में जानते हैं? यदि आप नहीं करते हैं, तो समस्या दस्तावेज़ीकरण में से एक हो सकती है?

इससे पहले कि मैं सकारात्मक हूं कि पिपेनव पाइप/वर्चुअलएनवी वर्कफ़्लो के लिए एक अच्छा प्रतिस्थापन होगा, मुझे लगता है कि हम सभी जानते हैं कि हमें इसकी आवश्यकता है और मुझे लगता है कि जिस दिन पिपेनव उत्पादन के लिए तैयार है, यह कई लोगों/परियोजनाओं के लिए एक बड़ी मदद होगी।

@bochecha जैसा कि मैंने समझाया था कि मुझे एक पैकेज का एक नया संस्करण स्थापित करना था, कुछ सामान करना था और फिर अगले पैकेज के साथ जाना था, हो सकता है कि अगर मैंने इस प्रक्रिया को पाइप के साथ किया और फिर पिपेनव में माइग्रेट किया तो मुझे समस्या बिल्कुल भी दिखाई नहीं देगी, लेकिन मैंने पहले पिपेनव में माइग्रेट किया और फिर पैकेज को एक-एक करके अपडेट किया और यह वास्तव में कष्टप्रद था। मुझे खुशी है कि यह आपके उपयोगकेस के लिए काम करता है, लेकिन मुझे यकीन है कि यह मेरे जैसे कई लोगों के लिए काम नहीं करता है (उपरोक्त टिप्पणियों पर एक नज़र डालें)। इसका उल्लेख README.md में किया जाना चाहिए, कम से कम यह उल्लेख किया जाना चाहिए कि "प्रत्येक लॉकिंग में लंबा समय लग सकता है, इसलिए यदि आपके उपयोगकेस में बहुत सारे पैकेजों को जल्दी से स्थापित/निकालना शामिल है तो आपको इस समस्या के होने तक pipenv का उपयोग करने से बचना चाहिए। हल किया गया" (फिर से बोल्ड में, और प्रशंसापत्र के ऊपर) यदि आप किसी के प्रभावित होने से पहले समस्याओं की घोषणा करते हैं, तो हर कोई आभारी होगा, यदि समस्याएं दूसरों को प्रभावित करती हैं और आपने उन्हें चेतावनी नहीं दी है, तो हर कोई नाराज हो जाएगा।

माना। मैंने कविता में देखना शुरू कर दिया और फिर भी पिपेनव का फिर से उपयोग करने के बजाय प्रति प्रोजेक्ट अपने ओएस में एक और उपयोगकर्ता जोड़ने के बावजूद। यदि यह डिफ़ॉल्ट सेटिंग्स के साथ आकस्मिक उपयोग के मामलों के लिए ठीक काम नहीं कर रहा है तो यह इम्हो टूट गया है।
यह एक सुपर उपयोगी उपकरण है! बस यही एक चीज है जो इसे मेरे लिए बहुत बेकार बना देती है। और दुख की बात है कि मेरे पास योगदान करने के लिए बहुत कम समय है:|

निश्चित रूप से, मध्य देव सत्र में एकाधिक इंस्टॉल करने के दौरान लॉक की प्रतीक्षा करना परेशान है, लेकिन इसे प्रबंधित किया जा सकता है।

महत्वपूर्ण बात यह है कि स्थानीय परिवर्तनों को रेपो में धकेलने से पहले एक लॉक फ़ाइल उत्पन्न होती है। मैं देव सत्रों के दौरान —skip-lock ध्वज का विवेकपूर्ण उपयोग करता हूं, और pipenv lock अंत में एक बार प्रतिबद्ध होने से पहले।

परियोजना के लिए धन्यवाद। लेकिन,
लॉकिंग है

PIP_NO_CACHE_DIR=off
यह एनवी लॉकिंग को और तेज़ बनाता है, अगर इसमें पहले से ही एक पाइप पैकेज कैश स्थापित है।

नमस्ते @yssource और सभी,

परियोजना के लिए धन्यवाद। लेकिन,
लॉकिंग है

यह परियोजना मृत प्रतीत होती है, इसलिए यदि आप गति की समस्या को समाप्त करना चाहते हैं तो कृपया काव्य में माइग्रेट करने पर विचार करें जो काफी तेज है।

@ जमीम , कविता का सुझाव देने के लिए धन्यवाद। व्यक्तिगत रूप से, किसी कारण से मैं इस पर नहीं आया। इसका रीडमी पढ़ने के बाद यह कोशिश करने लायक लगता है। यह पिपेनव पर भी कुछ लाभों को सूचीबद्ध करता है (https://github.com/sdispater/poetry/#what-about-pipenv)।

यह कहते हुए कि, परियोजना का मृत होना एक सकल अतिरंजना है, और अगर मैं पिपेनव लेखकों के जूते में होता, तो मुझे यह अपमानजनक लगता। लेखक ने कल ही अंक खंड में उत्तर दिया। यह सिर्फ इस लॉकिंग मुद्दे की अनदेखी की जा रही है, शायद इसलिए कि इसे ठीक करना कठिन है।

रिकॉर्ड के लिए, कविता प्रदर्शन के मुद्दों से भी ग्रस्त है:
https://github.com/sdispater/poetry/issues/338

मुझे अपनी सभी परियोजनाओं में एक ही समस्या है।
इसका कारण पाइलिंट लगता है।
पिपेनव (पाइप) इसे सफलतापूर्वक स्थापित कर सकता है, लेकिन लॉकिंग हमेशा के लिए लेता है!
pipenv, version 2018.11.26

djbrown@DESKTOP-65P6D75:~$ mkdir test
djbrown@DESKTOP-65P6D75:~$ cd test
djbrown@DESKTOP-65P6D75:~/test$ pipenv install --dev pylint --verbose
Creating a virtualenv for this project…
Pipfile: /home/djbrown/test/Pipfile
Using /usr/bin/python3 (3.6.9) to create virtualenv…
⠸ Creating virtual environment...Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python3
Also creating executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python
Installing setuptools, pip, wheel...done.

✔ Successfully created virtual environment!
Virtualenv location: /home/djbrown/.local/share/virtualenvs/test-PW-auWy_
Creating a Pipfile for this project…
Installing pylint…
⠋ Installing...Installing 'pylint'
$ ['/home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/pip', 'install', '--verbose', '--upgrade', 'pylint', '-i', 'https://pypi.org/simple']
Adding pylint to Pipfile's [dev-packages]…
✔ Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
⠇ Locking...

मैंने पिपेनव के बारे में बहुत सुना और आज इसे आजमाया,
लॉकिंग भी मेरे लिए बहुत धीमी है। लगभग 2 मिनट हो चुके हैं, अभी भी लॉकिंग पर अटका हुआ है।
डाउनलोडिंग बहुत तेज है, लेकिन समस्या लॉकिंग की है।
क्या यह मसला हल हो गया है?
मैं उपयुक्त से पॉप ओएस 19.10, पिपेनव, संस्करण 11.9.0 का उपयोग कर रहा हूं, पायथन 3.7.5।

मैं इसी विषय पर #1914 की इस उत्कृष्ट टिप्पणी पर ध्यान आकर्षित करना चाहता हूं https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038 जो बताता है कि प्रत्येक निर्भरता को डाउनलोड करना और निष्पादित करना अब आवश्यक नहीं है।

मुझे आश्चर्य है कि क्या कोई देव इस दृष्टिकोण की व्यवहार्यता पर टिप्पणी कर सकता है।

मैंने देखा है कि पर्यावरण को हटाने और लॉकफाइल को अपडेट करने के लिए इसे स्क्रैच से फिर से बनाना वास्तव में तेज़ है।
यह pipenv lock और pipenv install some-package चलाने के लिए सही है

मुझे वास्तव में pipenv लेकिन उतना नहीं जितना मुझे अपनी बैंडविड्थ और समय पसंद है। तो मैं इस मुद्दे को हल करने का उपयोग कर समाप्त करता हूं:

$ pipenv --rm
$ virtualenv .
$ source bin/activate
$ # Create a requirement file (Cause pipenv lock -r > requirements.txt... you know!)
$ pip install -r requirement.txt

डेवलपर्स को शुभकामनाएं...

@ravexina सुझाव के लिए धन्यवाद, मैं निश्चित रूप से कोशिश करूँगा