Pipenv: تحديث القفل بطيء جدًا

نحن على علم ولدينا العديد من المشكلات في تتبع هذا الموضوع. انظر # 1785 # 1886 # 1891 و PR # 1896

تتمتع npm والغزل بميزة عدم الاضطرار إلى تنزيل كل حزمة محتملة وتنفيذها بالكامل لتحديد الرسم البياني للتبعية لأن التبعيات محددة في نص عادي. تتطلب تبعيات Python منا تنزيل ملفات الإعداد وتنفيذها بالكامل لكل حزمة لحلها وحسابها. هذه فقط الحقيقة ، إنها بطيئة بعض الشيء. إذا كنت لا تستطيع الانتظار لمدة دقيقتين أو كنت تشعر أن الأمر لا يستحق المقايضة ، فيمكنك دائمًا تمرير --skip-lock .

إغلاق لتعقب في القضايا الأخرى.

نفس الشيء هنا أنا أحاول تجربته الآن وتثبيت django بالفعل في 10 دقائق ويستمر

يبدو أنه إذا حاولت تثبيت زوجين في وقت واحد ، فسيكون ذلك بطيئًا ولكن إذا قمت بإجراء واحد في كل مرة ، فإنه يعمل بشكل أسرع قليلاً

إذا كان بإمكانك توفير ملف Pipfile يعيد إنتاج السلوك البطيء ، فسيكون ذلك مفيدًا - شكرًا

تتطلب تبعيات Python منا تنزيل ملفات الإعداد وتنفيذها بالكامل لكل حزمة لحلها وحسابها

هل لا يزال هذا هو الحال عندما يكون للحزمة Pipfile.lock ، أم ستستخدم pipenv ذلك عندما يكون ذلك ممكنًا لتحديد التبعيات؟

هل سيستخدم pipenv ذلك عندما يكون ذلك ممكنًا لتحديد التبعيات؟

لا. Pipenv هي أداة لحل تبعية التطبيقات. عندما يتم استخدام التبعية كحزمة Python بواسطة تطبيق آخر ، فإنها لم تعد تطبيقًا. يتم تحديد تبعياتها بواسطة setup.py (أو setup.cfg أو أيًا كان ما تستخدمه للتحميل إلى PyPI). يعد تحميل التبعيات من ملف القفل طريقًا أكيدًا إلى جحيم التبعية ، ومن المحتمل ألا نفعل ذلك أبدًا.

لا يزال بطيئًا للغاية

iddan شكرا للتذكير ، الكابتن واضح!

عذرًا ، بصفتي مشرفًا على OSS ، أعلم كيف يمكن أحيانًا تجاهل المشكلات بسبب العمر. أردت فقط أن أذكر أنه حتى القضية التي تم نقاشها لا تزال ذات صلة

ملاحظة techalchemy --skip-lock أعلاه رائعة. يجب أن يكون هذا خيارًا يسهل الوصول إليه أو يتم الإعلان عنه. هل يمكننا تعيينه كإعداد افتراضي في مكان ما؟

techalchemy ماذا لو

ملاحظة techalchemy --skip-lock أعلاه رائعة. يجب أن يكون هذا خيارًا يسهل الوصول إليه أو يتم الإعلان عنه. هل يمكننا تعيينه كإعداد افتراضي في مكان ما؟

بقدر ما أجمع ، فإن الفائدة العظيمة لـ pipenv هي أن تبعيات التأكيد ستلعب بشكل جيد معًا - ليس فقط من أجلك ، ولكن لأي شخص يتعامل لاحقًا في التعليمات البرمجية الخاصة بك. يستغرق منتج هذا الضمان ، ملف القفل ، وقتًا أطول مما يتوقعه أو يرغب فيه أي شخص ، _ بما في ذلك المطورين _ - راجع # 2200.

ومع ذلك ، أعتقد أنه يمكنك أيضًا فهم الفرصة التي يمتلكها pipenv لرعاية المطورين ذوي النوايا الحسنة في مجتمع Python عمومًا نحو سير عمل يفرض قدرًا أقل من الحيرة على المساهمين المستقبليين - الذين ربما كانوا زوارًا فقط لو استسلموا خلال " معرفة كيفية إعداد بيئة التطوير "؛ وعدد أقل من الأيدي التي تم إلقاؤها من قبل المشرفين المستقبليين - الذين ربما كانوا قد تم نقلهم من قبل مؤلفي العلاقات العامة فقط لو أنهم استسلموا أثناء مرحلة "الشد الجاد مع الأجزاء الداخلية العميقة للمشروع".

إذا أصبح --skip-lock علامة دائمة في ملف Pipfile أو إعدادًا في تكوين pipenv ، فإن تصور pipenv سينزلق ببطء نحو "نقطة أفضل" ، وستتلاشى نقطة انطلاق أخرى في الأفق حيث وصل المجتمع في النهاية خليفة روحي أقل مساومة.

من الأفضل تركه متاحًا فقط باعتباره var var ، أو طريقة أخرى يقع تطبيقها بشكل مباشر في منطقة _ "التهيئة المحلية الخاصة بالمستخدم ، خطأك" _ ، مما يسمح لـ pipenv بالتغلب على المرحلة التي يمر بها بطء إنشاء ملف القفل دون الاستسلام التحول الثقافي المفيد حقًا نحو _التوضيح أكثر من التضمين_ في إدارة الحزم.

تعد مكتبة Python القياسية الضخمة بشكل لا يصدق أحد الأصول الهائلة ، والتي مر تاريخها بالعديد من العصور من فرض الاتساق. لعب معظم الحزم القياسية بشكل جيد معًا يعد إنجازًا هائلاً ينطوي على مراعاة العديد من الأشخاص على مدار سنوات عديدة. في يوم من الأيام ، ستمتد هذه القدرة على اللعب اللطيف إلى معظم مشاريع Python التي تمت مواجهتها على الويب - بعيدًا عن stdlib ، ومع عدد أقل بكثير من PEPs المطلوبين (_ وبعيدًا ، عدد أقل بكثير من BDFLs الذين يتم إخلاءهم بسبب الإحباط_). تأثير مثل هذا من جانب واحد زبداني خبرة من الصعب قياس، ولكن بعض اللغات الحالية _did_ النفايات بخرق سلامة المفاهيمية للراحة فورية ... وأوه، والأماكن التي سوف الذهاب .

لذا _نعم_ ، إنشاء ملف القفل بطيء ، و _ نعم_ ، يكون محبطًا عندما تريد فقط pip install --save . ولكن هذا فقط لأننا كنا نكتسح فيلًا في الخزانة لسنوات - معتقدين أنه ليس لدينا فوضى متشابكة من التوقعات والنوايا من التبعيات الخارجية ، لأنه _ "تم تثبيته جيدًا على جهازي" _.

إنشاء ملف القفل بطيء _ فقط_ لأنه يوضح ما أخذناه جميعًا كأمر مسلم به. لكن _ لأنه مؤلم ، سنقوم بتعديل الأمور حتى لا يحدث ذلك. كسرنا ذراعنا لأننا دفعنا أنفسنا للقيام بأشياء نؤمن بها. بالتأكيد ، يمكننا تجنب الألم بعدم استخدام تلك الذراع مرة أخرى مطلقًا - أو يمكننا وضعها في جبيرة أثناء التعافي.

سأكون آخر شخص يخبرك بعدم جعل pipenv مناسبًا لنفسك اليوم (وإلا سأكون مطورًا سيئًا - على الرغم من أن هيئة المحلفين ما زالت خارج الخدمة) ، لكنني أتوسل إليك أن ترى الإحباط الناتج عن إنشاء ملفات lockfile باعتباره تطورًا متزايدًا يتألم بينما يتطور مجتمع Python إلى جسم قوي وصحي بأطراف تعمل بكامل طاقتها أكثر مما كان متوقعًا حقًا عند إزالة جبيرة. لقد وصلنا إلى Python 3. لنجعلها تدير التبعية في stdlib.

استغرق هذا 38 دقيقة على جهازي لإنشاء ملف القفل. تشغيل Windows 10 واستخدام Python 3.7

تم بالفعل تثبيت numpy والوسادة فقط واستغرق الأمر أقل من ثانية واحدة لتثبيت numba و 25 دقيقة لقفله. هل يقوم pipenv بتجميع كل lib على القفل بالقوة أو كيف يعمل هذا؟

قفل التخطي المستمر لمعلوماتك هو فقط انتظار شخص ما لقلب المفتاح مقابل auto_envvar_prefix وهو إعداد نقرة. لقد ركزت بنسبة 100 ٪ على الوظائف الأساسية ، لذا لم تتح لي الفرصة للنظر في هذا الأمر حتى الآن ، لكنني أظن أنه ليس بهذه الصعوبة

TLDR ؛ الاستدعاء النموذجي pipenv install : الوقت : 144.82 مستخدمًا حقيقيًا 33.68 5.77 نظامًا. مع --skip-lock : الوقت : 4.54 حقيقي 5.33 مستخدم 0.87 sys.

فشل تثبيت Pandas-datareader في المحاولة الأولى ، وربما يتسبب في تعليق lock . هل هذه مشكلة يراها أي شخص آخر مع الحزم الأخرى؟

باستخدام الإصدار 2018.11.26

$ pipenv --version
pipenv, version 2018.11.26

محتويات requirements.txt

sklearn
pandas
numpy
matplotlib
statsmodels

طلب نموذجي pipenv install . التنفيذ المحدد بوقت باستخدام time (BSD).

النتائج : 144.82 مستخدم حقيقي 33.68 مستخدم 5.77 نظام

$ 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 real 5.33 user 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')

@ black-snow أوصي بتجربته في قشرة مختلفة. بدون التعمق في الأشياء ، يبدو أن pexpect (مكتبة للتفاعل برمجيًا مع برامج CLI التفاعلية) تُستخدم للكشف عن shell pipenv الذي يتم تنفيذه من ، وقد يكون ذلك معطلاً. يبدو أن pexpect kinda مبالغ فيه لمثل هذا الشيء ، لكنني لست على دراية بالسياق بأكمله.

@ theY4Kman شكرا على النصيحة. تعمل pipenv بشكل جيد على جهاز كمبيوتر آخر بنفس إصدار ubuntu و bash ...

اقرأ هذا أثناء انتظار قفل ملف الأنابيب ... :) سيكون رائعًا إذا كان هناك حل.

يبدو أننا بحاجة إلى نوع من واجهة برمجة التطبيقات لتحليل وتخزين حزم بايثون مؤقتًا وتوزيعها بتنسيق مناسب للآلات. لذلك لن نحتاج بعد الآن إلى تنزيل حزم كاملة وتحليلها.

أعتقد أن الأحجار الكريمة المجمعة والياقوتية تحافظ وتستخدم شيئًا من هذا القبيل.

تحتوي Java أيضًا على ملفات POM (XML) التي تحتوي على تبعيات الحزمة ومعلومات أخرى حول الحزمة. يتم تحميلها بشكل منفصل عن JARs المجمعة.

يحتوي كل مدير حزم جديد على بعض ملفات التعريف المنفصلة (npm / yarn ، composer ، gradle / maven ، cargo ، روبي gems / bundler ، ...).

مسألة ذات صلة:
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.

في مشروعنا 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...

الخطأ غير مقروء ، ولا توجد فكرة عما حدث. التثبيت مع نقطة في البيئة يعمل بشكل جيد! هذا حقا سدادة عرض. العودة إلى requirements.txt ...

هذا هو الحل الذي أستخدمه الآن:

export PIPENV_SKIP_LOCK=true

ثم لن يتم قفل pipenv install foo ويمكنك قفله يدويًا عندما يكون لديك الوقت عن طريق تشغيل pipenv lock .

awhillas متأكد أن السطر الأخير يقول كل ما تحتاجه:

لقد حاولت تثبيت "pytorch". الحزمة المسماة باسم PyTorch هي "torch"

قفل التبعيات مهم لذا لا أعتقد أن "تخطي القفل" هو حل دائم. في الوقت نفسه ، أنا ببساطة لا أشتري أن "تبعيات القفل" (أيًا كان ما قد يترتب على ذلك تحت غطاء المحرك) تم تحسينها إلى أقصى حد كما هي الآن وتتطلب وظيفيًا عدة دقائق أو ساعات لإكمالها. في الواقع ، تم تشغيل قفل pipenv الخاص بي لعدة دقائق على ملف Pipfile يحتوي على 5 تبعيات مثيرة للضحك قبل الفشل - المكدس المتصل في الأسفل - وخلال ذلك الوقت استخدم فقط 10-15٪ من وحدة المعالجة المركزية المتاحة ورشفة صغيرة من الذاكرة.

هل يمكننا على الأقل بذل بعض الجهد الجماعي لتحديد نقاط الاختناق وتحديدها؟ لدي شعور بأن هناك بعض الفاكهة المعلقة السخيفة هناك فقط في انتظار أخذ هذه العملية إلى وقت تشغيل معقول.

pipenv version 2018.11.26

لملف Pipfile:

[[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 لأول مرة. لذلك ربما يكون استدعاء القفل بعد التثبيت قديمًا أو خاطئًا. :)

لمعلوماتك وجدت أن Tensorflow هو السبب في القفل البطيء / توقيت الخروج ، إذا كان ذلك يساعد ملف تعريف pipenv! (لا تزال تعتبر هذه مشكلة بيبينف ...)

Tensorflow هي واحدة من العديد من الحزم التي يمكن أن تجعل pipenv أساسًا أداة غير مفيدة. لكني أحب اقتراح التنميط الجماعي. أعتقد أن هذه فكرة ممتازة للبدء في معالجة هذه المشكلة. فقط لإعادة التكرار ، قام PEP 566 بتمكين تعداد التبعية (عبر pypi) دون تحميل المصدر بالكامل ، والذي قد يكون مفيدًا: https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038

brandonrobertz مما أراه ، تنزيل جميع حزم التبعيات هو المكان الذي يقضي فيه معظم الوقت. هذا أيضا تم تأكيده من قبل.

كيفية التحقق من ذلك:

• حاول إنشاء Pipfile وتثبيت scipy (على سبيل المثال) فيه مع تمكين القفل
• انتظر حتى يكتمل القفل. (يستغرق الأمر حوالي 5 دقائق على جهازي)
• إزالة Pipfile.lock
• تشغيل pipenv lock - سيستغرق القفل الآن القليل من الوقت (6 ثوانٍ على جهازي) ، لأن جميع الحزم تم تنزيلها بالفعل والاحتفاظ بها في ذاكرة التخزين المؤقت Pipenv والتي تكون عادةً في ~/.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 نعم ، هذا منطقي واقترح آخرون ذلك في هذا الموضوع. يعد تنزيل التبعيات وتحليلها أمرًا مكلفًا. يبدو أن بعض هذه الخطوات يمكن إزالتها عن طريق السحب من واجهة برمجة تطبيقات تبعية pypi.

قد لا يعمل هذا في بعض المكتبات ، بسبب الجودة الرديئة والممارسات السيئة (عدم استخدام setup.py أو requirements.txt). ولكن نظرًا لأن بعض المخالفين الرئيسيين يبدو أنهم مكتبات شائعة جدًا (Tensorflow ، numpy) ، فإن تنفيذ ذلك مع الرجوع إلى العملية البطيئة للغاية قد يكون طريقًا جيدًا للمضي قدمًا.

هل يمكنك توجيهي في اتجاه مكان العثور على هذا الرمز؟ يمكنني أخذ طعنة في موازاة ذلك في شوكة.

أعتقد أن https://github.com/pandas-dev/pandas/ قد يكون مشكلة؟ إنها نقطة مشتركة مع الوقت بالنسبة لي أيضًا.

على الرغم من أن pytest قد يكون مشكلة أيضًا: \

لا أعتقد ذلك ، إنه يعمل بشكل جيد على جهازي ، ويبدو أن المشكلة أكثر عمومية من ذلك

في حالتي ، يبدو أن المشكلة هي pylint. يتم تعليقه دائمًا عند القفل عند تشغيل pipenv install pylint راجع https://github.com/pypa/pipenv/issues/2284#issuecomment -569457752

لدي نفس المشكلة في جميع مشاريعي.
يبدو أن السبب هو pylint.
يمكن لـ Pipenv (pip) تثبيته بنجاح ، لكن القفل يستغرق وقتًا طويلاً!
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 و PR # 1896

تتمتع npm والغزل بميزة عدم الاضطرار إلى تنزيل كل حزمة محتملة وتنفيذها بالكامل لتحديد الرسم البياني للتبعية لأن التبعيات محددة في نص عادي. تتطلب تبعيات Python منا تنزيل ملفات الإعداد وتنفيذها بالكامل لكل حزمة لحلها وحسابها. هذه فقط الحقيقة ، إنها بطيئة بعض الشيء. إذا كنت لا تستطيع الانتظار لمدة دقيقتين أو كنت تشعر أن الأمر لا يستحق المقايضة ، فيمكنك دائمًا تمرير --skip-lock .

إغلاق لتعقب في القضايا الأخرى.

تم الآن إغلاق 3 من أصل 4 مشكلات أخرى ولم يشهد العدد المتبقي أي نشاط منذ عام 2018. ما زالت هذه المشكلة قائمة ، لذا ربما تكون إعادة فتحها فكرة جيدة؟

تتطلب تبعيات Python منا تنزيل ملفات الإعداد وتنفيذها بالكامل لكل حزمة لحلها وحسابها

لا أعتقد أن هذا لا يزال صحيحًا بالنسبة للعجلات ، والتي يجب أن تكون غالبية الحزم الآن؟

أعلم أنه يتعين علي على الأقل بناء العجلة لـ dlib في كل مرة ، وهو أمر مروع.

يجب تخزين عملية حل التبعيات مؤقتًا في مكان ما على أساس إصدار كل حزمة ، حتى إذا تطلب الأمر بحثًا عن بُعد آخر على العميل في كل مرة للحصول على الشجرة (لا ينبغي ذلك ، يمكنك تخزينها مؤقتًا محليًا أيضًا بعد الحقيقة ). على سبيل المثال ، يمكن أن تخزن حزم المستودعات بسهولة أشجار التوزيع التي تم حلها. ستكون الشبكة الإضافية التي يتم ضربها لشجرة التوزيع التي تم حلها مؤقتًا أسرع دائمًا من تنزيل حزمة كاملة والحوسبة.

FWIW لقد قمت بإزالة pipenv من جميع مشاريعي (هذا هو السبب الرئيسي ، وهناك أسباب أخرى).

virtualenv + pip (مع requirements.txt ) تعمل الآن بشكل جيد ، حتى مع عمليات نشر Prod ؛ وعلى أي حال ، ينشر المرء حاوية كاملة التكوين هذه الأيام ؛ بعد الدخول في pipenv حقًا ، لم أعد أرى الهدف منه.

يرجى إعادة فتح هذه المشكلة.
وإلا فإن pipenv لن تكون أبدًا أداة التعبئة والتغليف المرجعية