Pipenv: लॉक अपडेट करना बहुत धीमा है

हम जागरूक हैं और इस विषय को ट्रैक करने में कई समस्याएं हैं। देखें #1785 #1886 #1891 और पीआर #1896

npm और यार्न को अपने निर्भरता ग्राफ को निर्धारित करने के लिए प्रत्येक संभावित पैकेज को पूरी तरह से डाउनलोड और निष्पादित नहीं करने का लाभ है क्योंकि निर्भरताएं प्लेनटेक्स्ट में निर्दिष्ट हैं। पायथन निर्भरता के लिए हमें हल करने और गणना करने के लिए प्रत्येक पैकेज की सेटअप फ़ाइलों को पूरी तरह से डाउनलोड और निष्पादित करने की आवश्यकता होती है। बस यही हकीकत है, थोड़ी धीमी है। यदि आप 2 मिनट प्रतीक्षा नहीं कर सकते हैं या आपको लगता है कि यह ट्रेडऑफ़ के लायक नहीं है, तो आप हमेशा --skip-lock पास कर सकते हैं।

अन्य मुद्दों में ट्रैक करने के लिए बंद।

वही यहाँ मैं इसे अभी आज़मा रहा हूँ और django स्थापित करना पहले से ही 10 मिनट और जा रहा है

ऐसा लगता है कि यदि आप एक समय में एक जोड़े को स्थापित करने का प्रयास करते हैं तो यह धीमा होता है लेकिन यदि आप एक समय में एक करते हैं तो यह थोड़ा तेज़ काम करता है

यदि आप एक पिपफाइल प्रदान कर सकते हैं जो धीमे व्यवहार को पुन: उत्पन्न करता है तो यह सहायक होगा - धन्यवाद

पायथन निर्भरता के लिए हमें हल करने और गणना करने के लिए प्रत्येक पैकेज की सेटअप फ़ाइलों को पूरी तरह से डाउनलोड और निष्पादित करने की आवश्यकता होती है

क्या यह अभी भी मामला है जब पैकेज का अपना Pipfile.lock , या जब संभव हो तो निर्भरता निर्धारित करने के लिए pipenv इसका उपयोग करेगा?

निर्भरताओं को निर्धारित करने के लिए जब संभव हो तो पिपेनव इसका उपयोग करेगा?

नहीं। पिपेनव एक एप्लीकेशन डिपेंडेंसी रिजॉल्यूशन टूल है। जब किसी अन्य एप्लिकेशन द्वारा एक निर्भरता को पायथन पैकेज के रूप में उपयोग किया जाता है, तो यह अब एक एप्लिकेशन नहीं है। इसकी निर्भरता setup.py (या setup.cfg या जो भी आप PyPI पर अपलोड करने के लिए उपयोग करते हैं) द्वारा निर्धारित की जाती हैं। लॉक फ़ाइल से निर्भरता लोड करना निर्भरता नरक के लिए एक निश्चित मार्ग है, हम शायद ऐसा कभी नहीं करेंगे।

यह अभी भी बहुत धीमा है

@iddan अनुस्मारक के लिए धन्यवाद, कप्तान स्पष्ट!

क्षमा करें, एक ओएसएस अनुरक्षक के रूप में मुझे पता है कि कभी-कभी उम्र के कारण मुद्दों को कैसे खारिज किया जा सकता है। बस यह बताना चाहता था कि इस मुद्दे पर भी चर्चा हुई, यह अभी भी प्रासंगिक है

ऊपर --skip-lock का @techalchemy नोट अद्भुत है। यह एक अधिक सुलभ या प्रचारित विकल्प होना चाहिए। क्या हम इसे कहीं डिफ़ॉल्ट के रूप में सेट कर सकते हैं?

@techalchemy क्या होगा अगर मेरे ब्रांड के नए मैक प्रो के साथ 20 मिनट लगते हैं?

ऊपर --skip-lock का @techalchemy नोट अद्भुत है। यह एक अधिक सुलभ या प्रचारित विकल्प होना चाहिए। क्या हम इसे कहीं डिफ़ॉल्ट के रूप में सेट कर सकते हैं?

जहां तक ​​​​मैं इकट्ठा करता हूं, पिपेनव का अत्यधिक लाभ यह है कि आश्वासन निर्भरता एक साथ अच्छी तरह से खेलेंगे - न केवल आपके लिए, बल्कि बाद में आपके कोड में काम करने वाले किसी भी व्यक्ति के लिए। उस आश्वासन का उत्पाद, लॉक फ़ाइल, किसी की अपेक्षा या इच्छा से अधिक समय लेता है, _देवों सहित_ - # 2200 देखें।

हालाँकि, मुझे लगता है कि आप इस अवसर को भी समझ सकते हैं कि पिपेनव को पाइथन समुदाय में अच्छी तरह से अर्थ देवों को बड़े पैमाने पर एक वर्कफ़्लो की ओर ले जाना है, जो भविष्य के योगदानकर्ताओं पर कम सिर-खरोंच लगाते हैं - जो केवल आगंतुक हो सकते हैं, उन्होंने " पता लगाएँ कि देव वातावरण कैसे सेटअप करें" चरण; और भविष्य के अनुरक्षकों द्वारा फेंके गए कम हाथ - जो केवल पीआर लेखकों द्वारा ड्राइव-बाय हो सकते थे, उन्होंने "गंभीर रूप से गहन परियोजना आंतरिक के साथ चारों ओर पंगा लेना" चरण के दौरान छोड़ दिया था।

यदि --skip-lock को पिपफाइल में एक स्थायी ध्वज या एक पिपेनव कॉन्फ़िगरेशन में एक सेटिंग बनना था, तो पिपेनव की धारणा धीरे-धीरे "बेहतर पाइप" की ओर बढ़ जाएगी, और क्षितिज में एक और कदम पत्थर लुप्त हो जाएगा क्योंकि समुदाय अंततः उतरा था एक कम समझौता करने वाला आध्यात्मिक उत्तराधिकारी।

इसे केवल एक env var, या किसी अन्य विधि के रूप में उपलब्ध छोड़ने के लिए बेहतर है जिसका अनुप्रयोग _ "आपके उपयोगकर्ता-विशिष्ट स्थानीय कॉन्फ़िगरेशन, आपकी गलती" _ क्षेत्र में पूरी तरह से टिकी हुई है, जिससे पिपेनव को बिना हार के लॉकफाइल पीढ़ी की सुस्ती के गुजरने वाले चरण को दूर करने की अनुमति मिलती है। पैकेज प्रबंधन में _स्पष्टता पर अस्पष्टता_ की ओर वास्तव में लाभकारी सांस्कृतिक बदलाव।

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

तो _yes_, लॉकफ़ाइल जनरेट करना धीमा है, और _yes_, यह निराशाजनक है जब आप केवल pip install --save । लेकिन यह केवल इसलिए है क्योंकि हम वर्षों से एक हाथी को कोठरी में घुमा रहे हैं - यह मानते हुए कि हमारे पास बाहरी निर्भरता से अपेक्षाओं और इरादों की उलझी हुई गड़बड़ी नहीं है, क्योंकि _ "यह मेरी मशीन पर ठीक स्थापित है"_।

लॉकफाइल पीढ़ी धीमी है _only_ क्योंकि यह स्पष्ट कर रही है कि हमने क्या लिया है। लेकिन _क्योंकि_ यह दर्द होता है , हम चीजों को समायोजित करेंगे ताकि ऐसा न हो। हमने अपना हाथ तोड़ दिया क्योंकि हमने उन चीजों को करने के लिए खुद को धक्का दिया जिन पर हम विश्वास करते थे। निश्चित रूप से, हम उस हाथ का फिर कभी उपयोग न करके दर्द से बच सकते हैं- या जब तक यह ठीक हो जाता है तब तक हम इसे कास्ट में डाल सकते हैं।

मैं आपको बताने वाला आखिरी व्यक्ति होगा कि आज अपने लिए पिपेनव को सुविधाजनक न बनाएं (अन्यथा मैं एक छोटा डेवलपर बनूंगा - _हालांकि, जूरी अभी भी बाहर_), लेकिन मैं आपसे लॉकफाइल पीढ़ी की बढ़ती निराशा को देखने के लिए आग्रह करता हूं दर्द होता है जबकि पाइथन समुदाय एक मजबूत, स्वस्थ शरीर के रूप में विकसित होता है जिसमें एक कास्ट को हटाते समय वास्तव में अपेक्षित एक से अधिक पूरी तरह से काम करने वाले अंग होते हैं। हमने इसे पायथन 3 में बनाया है। आइए इसे stdlib में निर्भरता प्रबंधन के लिए बनाते हैं।

लॉक फ़ाइल बनाने में मेरी मशीन पर 38 मिनट का समय लगा। विंडोज 10 चलाना और पायथन 3.7 . का उपयोग करना

केवल सुन्न और तकिया पहले से ही स्थापित थे और सुन्न को स्थापित करने में <1 सेकंड और इसे लॉक करने में 25 मिनट का समय लगा। क्या पिपेनव लॉक पर हर लिब को जबरन संकलित करता है या यह कैसे काम करता है?

FYI करें लगातार स्किप लॉक auto_envvar_prefix लिए स्विच को फ्लिप करने के लिए किसी का इंतजार कर रहा है जो एक क्लिक सेटिंग है। मैं मूल कार्यक्षमता पर 100% केंद्रित रहा हूं इसलिए मुझे अभी तक इसे देखने का मौका नहीं मिला है, लेकिन मुझे संदेह है कि यह इतना मुश्किल नहीं है

टीएलडीआर; विशिष्ट pipenv install मंगलाचरण: समय : 144.82 वास्तविक 33.68 उपयोगकर्ता 5.77 sys. --skip-lock : समय : 4.54 वास्तविक 5.33 उपयोगकर्ता 0.87 sys.

पंडों-डेटारेडर इंस्टॉल पहले प्रयास में विफल हो जाता है, संभवतः lock लटकने का कारण। क्या यह कोई समस्या है जिसे कोई अन्य पैकेज के साथ देख रहा है?

संस्करण 2018.11.26 . का उपयोग करना

$ pipenv --version
pipenv, version 2018.11.26

requirements.txt

sklearn
pandas
numpy
matplotlib
statsmodels

विशिष्ट pipenv install आमंत्रण। time (बीएसडी) का उपयोग करके समयबद्ध निष्पादन।

परिणाम : 144.82 वास्तविक 33.68 उपयोगकर्ता 5.77 sys

$ time pipenv install -r requirements.txt
Requirements file provided! Importing into Pipfile…
Pipfile.lock (0fdb67) out of date, updating to (a65489)…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
✔ Success!
Updated Pipfile.lock (0fdb67)!
Installing dependencies from Pipfile.lock (0fdb67)…
  🎅   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 15/15 — 00:00:04
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
      144.82 real        33.68 user         5.77 sys

w\ --skip-lock आह्वान

परिणाम : 4.54 वास्तविक 5.33 उपयोगकर्ता 0.87 sys

$ time pipenv install -r requirements.txt --skip-lock
Requirements file provided! Importing into Pipfile…
Installing dependencies from Pipfile…
  🎅   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 6/6 — 00:00:01
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
        4.54 real         5.33 user         0.87 sys

मुझे लगता है कि https://github.com/pandas-dev/pandas/ एक समस्या हो सकती है? यह मेरे लिए भी समय के साथ एक सामान्य बात है।

हालांकि pytest भी एक मुद्दा हो सकता है:\

यह मेरी मशीन पर भी खत्म नहीं होगा:

Installing pandas…
Adding pandas to Pipfile's [packages]…
Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Traceback (most recent call last):
  File "c:\python36\lib\site-packages\pipenv\vendor\pexpect\expect.py", line 109, in expect_loop
    return self.timeout()
  File "c:\python36\lib\site-packages\pipenv\vendor\pexpect\expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x00000292ADCCCDD8>
searcher: searcher_re:
    0: re.compile('\n')

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

@ theY4Kman सलाह के लिए धन्यवाद। pipenv एक ही ubuntu और बैश संस्करण के साथ एक और पीसी पर ठीक काम कर रहा है ...

पाइपफाइल के लॉक होने की प्रतीक्षा करते हुए इसे पढ़ें...:) अगर कोई समाधान होता तो बहुत अच्छा होता।

ऐसा लगता है कि हमें पायथन पैकेजों को पार्स और कैश करने और मशीन के अनुकूल प्रारूप में वितरित करने के लिए किसी प्रकार के एपीआई की आवश्यकता है। इसलिए हमें अब पूरे पैकेज को डाउनलोड करने और उन्हें पार्स करने की आवश्यकता नहीं होगी।

मेरा मानना ​​​​है कि बंडलर और रूबी रत्न ऐसा कुछ बनाए रखता है और उसका उपयोग करता है।

जावा में पीओएम फाइलें (एक्सएमएल) भी हैं जिनमें पैकेज निर्भरताएं और पैकेज के बारे में अन्य जानकारी होती है। उन्हें संकलित जार से अलग से अपलोड किया जाता है।

प्रत्येक नए पैकेज प्रबंधक के पास कुछ अलग मेटा फ़ाइलें होती हैं (एनपीएम/यार्न, संगीतकार, ग्रेडल/मेवेन, कार्गो, रूबी रत्न/बंडलर, ...)

संबंधित मुद्दा:
https://github.com/pypa/warehouse/issues/474

आप संपूर्ण बंडल को डाउनलोड किए बिना PyPi से निर्भरता की जानकारी प्राप्त कर सकते हैं (देखें PEP 566, जिसने PEP 426 का स्थान लिया)।

package_name = 'Django'
PYPI_API_URL = 'https://pypi.python.org/pypi/{package_name}/json'
package_details_url = PYPI_API_URL.format(package_name=package_name)
response = requests.get(package_details_url)
data = json.loads(response.content)
data['info'].get('requires_dist')
data['info'].get('requires')
data['info'].get('setup_requires')
data['info'].get('test_requires')
data['info'].get('install_requires')

@techalchemy क्या आपने ऊपर टिप्पणी देखी?

यह काफी लगातार हो रहा है, अनिवार्य रूप से pipenv शहर के चारों ओर जा रहा है जबकि कुछ "लॉक" कर रहा है: यह मुद्दा क्यों बंद है?

समझें कि --skip-lock जाने का रास्ता है, लेकिन यह बिल्कुल स्पष्ट नहीं है कि "इंस्टॉल करना" में कुछ सेकंड क्यों लगते हैं, और "लॉकिंग" हमेशा के लिए लेता है: यह बहुत अच्छा होगा यदि कम से कम लॉक कमांड कुछ प्रगति का उत्सर्जन करेगा /अपडेट लॉग: जैसे-जैसे चीजें खड़ी होती हैं, यह भी स्पष्ट नहीं है कि यह किसी प्रकार के while True हमेशा के लिए फंस गया है ...

मैं कम से कम यह जानना चाहूंगा कि क्या यह मैं कुछ गलत कर रहा हूं, या सिर्फ पिपेनव की "फीचर"।

हमारे प्रोजेक्ट में pipenv lock इतना धीमा है। इसने निश्चित रूप से हमारे सामान्य उपयोग को प्रभावित किया। एक नया पैकेज जोड़ना अब हमारे लिए एक वास्तविक दर्द बन गया है। क्या वैसे भी हम इस व्यवहार को डीबग कर सकते हैं?

मैं PyTorch को स्थापित करने का प्रयास कर रहा हूं और इसे लॉक होने में 20 मिनट का समय लगा और फिर यह निम्न त्रुटि को खींचता है:

Installing initially failed dependencies…
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 1992, in do_install
[pipenv.exceptions.InstallError]:       skip_lock=skip_lock,
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 1253, in do_init
[pipenv.exceptions.InstallError]:       pypi_mirror=pypi_mirror,
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 859, in do_install_dependencies
[pipenv.exceptions.InstallError]:       retry_list, procs, failed_deps_queue, requirements_dir, **install_kwargs
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 763, in batch_install
[pipenv.exceptions.InstallError]:       _cleanup_procs(procs, not blocking, failed_deps_queue, retry=retry)
[pipenv.exceptions.InstallError]:   File "/usr/local/lib/python3.6/dist-packages/pipenv/core.py", line 681, in _cleanup_procs
[pipenv.exceptions.InstallError]:       raise exceptions.InstallError(c.dep.name, extra=err_lines)
[pipenv.exceptions.InstallError]: ['Collecting pytorch==1.0.2 (from -r /tmp/pipenv-pb00kf8t-requirements/pipenv-vae35p2d-requirement.txt (line 1))', '  Using cached https://files.pythonhosted.org/packages/ee/67/f403d4ae6e9cd74b546ee88cccdb29b8415a9c1b3d80aebeb20c9ea91d96/pytorch-1.0.2.tar.gz', 'Building wheels for collected packages: pytorch', '  Building wheel for pytorch (setup.py): started', "  Building wheel for pytorch (setup.py): finished with status 'error'", '  Running setup.py clean for pytorch', 'Failed to build pytorch', 'Installing collected packages: pytorch', '  Running setup.py install for pytorch: started', "    Running setup.py install for pytorch: finished with status 'error'"]
[pipenv.exceptions.InstallError]: ['ERROR: Complete output from command /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' bdist_wheel -d /tmp/pip-wheel-f_h8w1pz --python-tag cp36:', '  ERROR: Traceback (most recent call last):', '    File "<string>", line 1, in <module>', '    File "/tmp/pip-install-hix3yz6v/pytorch/setup.py", line 15, in <module>', '      raise Exception(message)', '  Exception: You tried to install "pytorch". The package named for PyTorch is "torch"', '  ----------------------------------------', '  ERROR: Failed building wheel for pytorch', '    ERROR: Complete output from command /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' install --record /tmp/pip-record-xr7o93_5/install-record.txt --single-version-externally-managed --compile --install-headers /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/include/site/python3.6/pytorch:', '    ERROR: Traceback (most recent call last):', '      File "<string>", line 1, in <module>', '      File "/tmp/pip-install-hix3yz6v/pytorch/setup.py", line 11, in <module>', '        raise Exception(message)', '    Exception: You tried to install "pytorch". The package named for PyTorch is "torch"', '    ----------------------------------------', 'ERROR: Command "/home/alex/.local/share/virtualenvs/pytorch-umelu-tG/bin/python3 -u -c \'import setuptools, tokenize;__file__=\'"\'"\'/tmp/pip-install-hix3yz6v/pytorch/setup.py\'"\'"\';f=getattr(tokenize, \'"\'"\'open\'"\'"\', open)(__file__);code=f.read().replace(\'"\'"\'\\r\\n\'"\'"\', \'"\'"\'\\n\'"\'"\');f.close();exec(compile(code, __file__, \'"\'"\'exec\'"\'"\'))\' install --record /tmp/pip-record-xr7o93_5/install-record.txt --single-version-externally-managed --compile --install-headers /home/alex/.local/share/virtualenvs/pytorch-umelu-tG/include/site/python3.6/pytorch" failed with error code 1 in /tmp/pip-install-hix3yz6v/pytorch/']
ERROR: ERROR: Package installation failed...

त्रुटि अपठित है, पता नहीं क्या गलत हुआ। पर्यावरण में पाइप के साथ स्थापित करना ठीक काम करता है! यह वास्तव में एक शो स्टॉपर है। आवश्यकताओं पर वापस जा रहे हैं। txt...

यह वह समाधान है जिसका मैं अभी उपयोग करता हूं:

export PIPENV_SKIP_LOCK=true

फिर pipenv install foo लॉक नहीं होगा और जब आपके पास pipenv lock चलाकर समय हो तो आप मैन्युअल रूप से लॉक कर सकते हैं।

@awhillas बहुत यकीन है कि आखिरी पंक्ति आपको बस इतना ही कहती है:

आपने "पाइटोरच" स्थापित करने का प्रयास किया। PyTorch के लिए नामित पैकेज "मशाल" है

लॉकिंग निर्भरता महत्वपूर्ण है इसलिए मुझे नहीं लगता कि "लॉक लॉक" एक स्थायी समाधान है। साथ ही, मैं बस यह नहीं खरीदता कि "लॉकिंग निर्भरता" (जो कुछ भी संभवतः हुड के नीचे प्रवेश कर सकता है) अधिकतम रूप से अनुकूलित है क्योंकि यह अभी है और कार्यात्मक रूप से पूरा करने के लिए कई मिनट या घंटे की आवश्यकता होती है। वास्तव में, मेरा पिपेनव लॉक एक पिपफाइल पर कई मिनट तक चलता था, जिसमें असफल होने से पहले 5 निर्भरताएं होती हैं - नीचे से जुड़ी स्टैक - और उस समय के दौरान उपलब्ध सीपीयू का केवल १०-१५% और मेमोरी का एक छोटा घूंट।

क्या हम कम से कम कुछ सामूहिक प्रयास कर सकते हैं ताकि बाधाओं का पता लगाया जा सके और उनका पता लगाया जा सके? मुझे लगता है कि इस प्रक्रिया को उचित रनटाइम में लेने की प्रतीक्षा में वहां कुछ मूर्खतापूर्ण कम लटकते फल हैं।

pipenv version 2018.11.26

पिपफाइल के लिए:

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]

[dev-packages]
keras = "*"
tensorflow = "~=1.13"
setuptools = "*"
wheel = "*"
twine = "*"

[requires]
python_version = ">=3.6"

Pipfile.lock (63b275) out of date, updating to (5e165c)…
Locking [dev-packages] dependencies…
Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 109, in expect_loop
    return self.timeout()
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x105a17210>
searcher: searcher_re:
    0: re.compile('\n')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/bin/pipenv", line 11, in <module>
    load_entry_point('pipenv==2018.11.26', 'console_scripts', 'pipenv')()
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/decorators.py", line 64, in new_func
    return ctx.invoke(f, obj, *args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/cli/command.py", line 254, in install
    editable_packages=state.installstate.editables,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1992, in do_install
    skip_lock=skip_lock,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1221, in do_init
    pypi_mirror=pypi_mirror,
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/core.py", line 1068, in do_lock
    lockfile=lockfile
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/utils.py", line 649, in venv_resolve_deps
    c = resolve(cmd, sp)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/utils.py", line 517, in resolve
    result = c.expect(u"\n", timeout=environments.PIPENV_INSTALL_TIMEOUT)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/delegator.py", line 215, in expect
    self.subprocess.expect(pattern=pattern, timeout=timeout)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/spawnbase.py", line 341, in expect
    timeout, searchwindowsize, async_)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/spawnbase.py", line 369, in expect_list
    return exp.expect_loop(timeout)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 119, in expect_loop
    return self.timeout(e)
  File "/usr/local/Cellar/pipenv/2018.11.26_2/libexec/lib/python3.7/site-packages/pipenv/vendor/pexpect/expect.py", line 82, in timeout
    raise TIMEOUT(msg)
pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x105a17210>
searcher: searcher_re:
    0: re.compile('\n')

पिछली टिप्पणी के एक परिशिष्ट के रूप में, pip lock अलग से चलाने में उचित समय लगा, ~15 सेकंड, पहली बार pip install --skip-lock चलाने के बाद। तो शायद लॉक का पोस्ट-इंस्टॉलेशन पुराना है या अन्यथा दोषपूर्ण है। :)

FYI करें मैंने पाया कि टेंसरफ़्लो धीमे/समय समाप्त होने वाले लॉक का अपराधी है, अगर वह प्रोफ़ाइल pipenv में मदद करता है! (अभी भी इसे एक पिपेनव समस्या मानें ...)

Tensorflow कई पैकेजों में से एक है जो पिपेनव को मूल रूप से एक बेकार उपकरण बनने का कारण बन सकता है। हालांकि, मुझे ग्रुप प्रोफाइलिंग का सुझाव पसंद है। मुझे लगता है कि इस समस्या से निपटने के लिए यह एक उत्कृष्ट विचार है। बस पुन: पुनरावृति करने के लिए, पीईपी ५६६ ने पूरे स्रोत को लोड किए बिना एन्यूमरेटिंग निर्भरता (पीपीआई के माध्यम से) को सक्षम किया, जो मददगार हो सकता है: https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038

@brandonrobertz जो मैं देखता हूं, निर्भरताओं के सभी पैकेजों को डाउनलोड करना वह जगह है जहां अधिकतर समय बिताया जाता है। इसकी पुष्टि पहले भी हो चुकी है।

इसे कैसे सत्यापित करें:

• लॉकिंग सक्षम के साथ एक नया Pipfile और उसमें scipy (उदाहरण के लिए) स्थापित करने का प्रयास करें
• लॉकिंग पूर्ण होने तक प्रतीक्षा करें। (मेरी मशीन पर लगभग 5 मिनट लगते हैं)
• Pipfile.lock निकालें
• pipenv lock चलाएं - अब लॉक करने में बहुत कम समय लगेगा (मेरी मशीन पर 6 सेकंड), क्योंकि सभी पैकेज पहले ही डाउनलोड हो चुके हैं और पिपेनव कैश में रखे गए हैं जो आमतौर पर ~/.cache/pipenv

यहाँ Dockerfile मैं इसका परीक्षण करने के लिए प्रयोग किया जाता है:

FROM python:3.6
ENV WORKDIR=/work/
WORKDIR /work/
RUN python3 -m pip install --upgrade pip
RUN python3 -m pip install pipenv
RUN PIPENV_SKIP_LOCK=true pipenv install scipy
RUN date
RUN pipenv lock
RUN date
RUN rm Pipfile.lock
RUN pipenv lock
RUN date

@shtratos हाँ, यह समझ में आता है और अन्य ने सुझाव दिया है कि इस मुद्दे में thread. निर्भरता को डाउनलोड करना और पार्स करना महंगा है। उन चरणों में से कुछ ऐसा लगता है कि उन्हें पीपीआई निर्भरता एपीआई से खींचकर समाप्त किया जा सकता है।

कुछ पुस्तकालयों के लिए यह शायद काम नहीं करेगा, खराब गुणवत्ता और खराब प्रथाओं (setup.py या आवश्यकताओं.txt का उपयोग नहीं करने) के कारण। लेकिन चूंकि कुछ प्रमुख अपराधी बहुत लोकप्रिय पुस्तकालय (टेंसरफ्लो, numpy) प्रतीत होते हैं, इसलिए इसे सुपर स्लो प्रोसेस में फॉलबैक के साथ लागू करना एक अच्छा रास्ता हो सकता है।

क्या आप मुझे उस कोड को खोजने की दिशा में इंगित कर सकते हैं? मैं इसे एक कांटे में समानांतर करने पर एक छुरा ले सकता था।

मुझे लगता है कि https://github.com/pandas-dev/pandas/ एक समस्या हो सकती है? यह मेरे लिए भी समय के साथ एक सामान्य बात है।

हालांकि pytest भी एक मुद्दा हो सकता है:\

मुझे ऐसा नहीं लगता, यह मेरी मशीन पर ठीक काम करता है, समस्या उससे कहीं अधिक सामान्य लगती है

मेरे मामले में समस्या पिलिंट लगती है। pipenv install pylint चलाने पर यह हमेशा लॉक हो जाता है https://github.com/pypa/pipenv/issues/2284#issuecomment -569457752 देखें

मुझे अपनी सभी परियोजनाओं में एक ही समस्या है।
इसका कारण पाइलिंट लगता है।
पिपेनव (पाइप) इसे सफलतापूर्वक स्थापित कर सकता है, लेकिन लॉकिंग हमेशा के लिए लेता है!
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...

हम जागरूक हैं और इस विषय को ट्रैक करने में कई समस्याएं हैं। देखें #1785 #1886 #1891 और पीआर #1896

npm और यार्न को अपने निर्भरता ग्राफ को निर्धारित करने के लिए प्रत्येक संभावित पैकेज को पूरी तरह से डाउनलोड और निष्पादित नहीं करने का लाभ है क्योंकि निर्भरताएं प्लेनटेक्स्ट में निर्दिष्ट हैं। पायथन निर्भरता के लिए हमें हल करने और गणना करने के लिए प्रत्येक पैकेज की सेटअप फ़ाइलों को पूरी तरह से डाउनलोड और निष्पादित करने की आवश्यकता होती है। बस यही हकीकत है, थोड़ी धीमी है। यदि आप 2 मिनट प्रतीक्षा नहीं कर सकते हैं या आपको लगता है कि यह ट्रेडऑफ़ के लायक नहीं है, तो आप हमेशा --skip-lock पास कर सकते हैं।

अन्य मुद्दों में ट्रैक करने के लिए बंद।

4 अन्य मुद्दों में से 3 अब बंद हो गए हैं और शेष ने 2018 के बाद से कोई गतिविधि नहीं देखी है। यह समस्या अभी भी बनी हुई है, तो शायद इसे फिर से खोलना एक अच्छा विचार होगा?

पायथन निर्भरता के लिए हमें हल करने और गणना करने के लिए प्रत्येक पैकेज की सेटअप फ़ाइलों को पूरी तरह से डाउनलोड और निष्पादित करने की आवश्यकता होती है

मुझे नहीं लगता कि यह अभी भी पहियों के लिए सही है, जो अब अधिकांश पैकेज होना चाहिए?

मुझे पता है कि मुझे कम से कम हर बार dlib के लिए पहिया बनाना होगा, जो कि भयानक है।

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

एफडब्ल्यूआईडब्ल्यू मैंने अपनी सभी परियोजनाओं से पिपेनव को हटा दिया है (यह एक मुख्य कारण है, अन्य भी हैं)।

virtualenv + pip ( requirements.txt ) अब उत्पाद परिनियोजन के लिए भी बहुत अच्छा काम करता है; और किसी भी घटना में, कोई इन दिनों पूरी तरह से तैयार कंटेनर को तैनात करता है; वास्तव में पिपेनव में आने के बाद, मुझे अब इसका मतलब नहीं दिख रहा है।

कृपया इस मुद्दे को फिर से खोलें।
अन्यथा पिपेनव कभी भी संदर्भ पैकेजिंग उपकरण नहीं होगा