Pipenv: القفل بطيء (ويقوم بتنزيلات زائدة عن الحاجة)

colllin هل راجعت ما إذا كانت أوامر النقطة التي تتصل بالخادم - مثل pip search (على ما أعتقد) - بطيئة أيضًا؟

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

تحرير: قد يكون لديك أيضًا الكثير من التبعيات الفرعية لحلها - ما حجم البيئة التي تم إنشاؤها مرة واحدة (على سبيل المثال ، عدد الحزم ذات المستوى الأعلى في ملف pipfile الخاص بك ، وعدد الحزم التي تم إرجاعها بواسطة pip list بمجرد أن يتم تمهيد البيئة)؟

شكرا لك على الرد المدروس.

pip search ليس سريعًا أو بطيئًا بشكل خاص بالنسبة لي ... ~ ثانية واحدة؟

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

أظن ... يستخدم pipenv نقطة تحت الغطاء؟ لذا فإن عملية التثبيت عبارة عن صندوق أسود ، ولا يمكنها معرفة الرسم البياني للتبعية لما تم تثبيته / سيتم تثبيته دون إجراء بحث في نقطة ~ استعلامات نقطة خاصة به؟

تحرير: هناك حزمة واحدة من المستوى الأعلى ، و ~ 65 حزمة تم إرجاعها بواسطة pip list في هذا الريبو المحدد.

أنا لست مساهماً في المشروع وفي الوقت الحالي لا أعرف كل التفاصيل ، لكن ما أفهمه هو أن مرحلة القفل هي المكان الذي يتم فيه حل جميع التبعيات وتثبيتها. لذلك ، إذا كان لديك حزمة واحدة ذات مستوى أعلى مع ~ 65 تبعيات ، فسيتم اكتشاف جميع تبعيات تلك الحزمة الأولى (بشكل متكرر) أثناء مرحلة القفل ، ثم يتم استخدام شجرة التبعية لتحديد الحزم التي يجب تثبيتها و (ربما) في أي ترتيب تقريبي يجب تثبيتها فيه. لست متأكدًا من الجزء الأخير.

إذا قمت بالتثبيت من ملف Pipfile بدون وجود ملف قفل ، فستلاحظ أنه يقوم بمرحلة القفل قبل تثبيت الحزم في venv. وبالمثل ، إذا كان لديك ملف قفل ولكنه قديم. أظن أن وجود ملف قفل والتثبيت باستخدام الخيار --deploy سيكون أسرع ، كما هو الحال مع الخيار --no-lock ؛ في الحالة الأولى ، تحصل على خطأ إذا كان ملف القفل قديمًا ، وفي الحالة الأخيرة ستفقد التقسيم المنطقي لحزم المستوى الأعلى (البيئة المُعلنة) والبيئة المثبتة (المقفلة) الفعلية لجميع الحزم. على الأقل هكذا أفهمها.

سواء كان pipenv يستخدم نقطة تحت الغطاء أم لا - أعتقد أنه كذلك - لا يزال يحتاج إلى الحصول على المعلومات من خادم (خوادم) pypi حول تبعيات الحزم وما شابه ، لذلك كان سؤالي حول بحث pip بمثابة وكيل عن مدى السرعة أو إن إبطاء المسار إلى خادم pypi هو مجرد تأثير مباشر على الآلية التي يقوم pipenv بواسطتها بأداء مهامه.

قد تكون إحدى التجارب المثيرة للاهتمام هي مقارنة الوقت المطلوب لقفل شجرة التبعية في pipenv ، وتثبيت المتطلبات في venv جديد باستخدام pip install -r requirements.txt . أعتقد أنه يجب عليهم فعل أشياء متشابهة أثناء مرحلة حل التبعية.

هل أثبتنا في مكان ما أن هناك تنزيلات زائدة عن الحاجة تحدث بالمناسبة؟ أظن أن هذا هو الحال ولكن إثبات ذلك سيكون مفيدًا حقًا

لمعلوماتك ، فإن مقارنة pip install -r requirements.txt بالوقت الذي يستغرقه قفل الرسم البياني للتبعية لن تكون مفيدة كنقطة مقارنة. لا تمتلك Pip في الواقع محللًا ، وليس بأي معنى حقيقي. أعتقد أنني أستطيع وصف الاختلاف. عندما تقوم النقطة بتثبيت requirements.txt الخاص بك ، فإنها تتبع هذه العملية الأساسية:

• ابحث عن أول متطلب مدرج
  
  
  
  • ابحث عن كل تبعياتها
  
  
  • قم بتثبيتها جميعًا
  
  
• ابحث عن المتطلب الثاني مدرجًا
  
  
  
  • ابحث عن كل تبعياتها
  
  
  • قم بتثبيتها جميعًا
  
  
• ابحث عن المتطلب الثالث مدرجًا
  
  
  
  • ابحث عن كل تبعياتها
  
  
  • قم بتثبيتها جميعًا
  
  

اتضح أن هذا سريع جدًا لأن النقطة لا تهتم حقًا إذا كانت تبعيات _package 1_ تتعارض مع تبعيات _package 3_ ، فقد قامت فقط بتثبيت العناصر الموجودة في _package 3_ أخيرًا وهذا ما تحصل عليه.

يتبع Pipenv عملية مختلفة - نحسب رسمًا بيانيًا للدقة يحاول تلبية _ جميع التبعيات التي تحددها ، قبل أن نبني بيئتك. هذا يعني أنه يتعين علينا البدء في تنزيل ، ومقارنة ، وأحيانًا حتى حزم _building_ لتحديد الشكل الذي يجب أن تبدو عليه بيئتك في نهاية المطاف ، كل ذلك قبل أن نبدأ حتى العملية الفعلية لتثبيتها (هناك الكثير من منشورات المدونة حول سبب ذلك هذا هو الحال في Python ، لذا لن أخوض في الأمر أكثر هنا).

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

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

نقطة واحدة للتوضيح - بمجرد حل الرسم البياني الكامل للتبعية ، لن يكون ترتيب التثبيت مهمًا بعد الآن. تحت غطاء المحرك نقوم بتمرير --no-deps لكل تثبيت على أي حال.

كملاحظة جانبية صغيرة ، يعد البحث عن النقطة حاليًا القطعة الوحيدة من أدوات النقطة التي تعتمد على واجهة XMLRPC التي تم إيقافها حاليًا ، وهي غير قابلة للتخزين وبطيئة جدًا. ستكون دائمًا أبطأ من أي عملية أخرى.

يستغرق قفل numpy (ولا شيء آخر) 220 ثانية على جهازي (انظر أدناه). يبدو أنه يتم قضاء معظم الوقت في تنزيل أكثر من 200 ميغا بايت من البيانات ، وهو أمر محير للغاية نظرًا لأن المصدر الخالي بالكامل يحتوي على 4 ميغا بايت. على الرغم من أنه من الواضح أنه حتى لو كان ذلك فوريًا ، فلا يزال هناك 25 ثانية من المعالجة الفعلية ، وحتى هذا يبدو مفرطًا في حساب عدد قليل من التجزئة. يستغرق القفل اللاحق ، حتى بعد حذف Pipenv.lock ، 5 ثوانٍ.

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 والآن يتم تجميد نشر ذلك على جهاز مختلف. أي إصلاح خاص لهذا؟

لا يوصى بتحرير ملف القفل يدويًا. بدون مزيد من المعلومات ، لا يمكن المساعدة. الرجاء فتح قضية منفصلة.

إذا كنت ترغب في قياس أداء قفل pipenv ، فيجب أن تحاول إضافة pytmx إلى تبعياتك ...
اعتاد قفل pipenv أن يستغرق ساعة واحدة أو أكثر بالنسبة لنا (لدينا إنترنت بطيء جدًا) ، وبعد إزالة pytmx ، وصلنا إلى حوالي 5 دقائق وأخيراً أصبح pipenv أكثر قابلية للاستخدام.
أعلم أن pytmx عبارة عن حزمة كبيرة لأنها حزمة كبيرة متجانسة وتعتمد على opengl / pygame والأشياء الأخرى ذات الصلة ، ولكن لا ينبغي أن يستغرق قفل pipenv ساعة واحدة بغض النظر عن حجم الحزمة

لا يستغرق الأمر ساعة واحدة بالنسبة لي

$ 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 أقل من 20 كيلو بايت على PyPI ، وله تبعية واحدة فقط إلى ستة (وهي صغيرة جدًا) ، لذلك لا ينبغي أن تكون الشبكات مشكلة. من المحتمل أن يكون هناك شيء آخر يحدث في بيئتك.

أنت محق ، إنه أصغر مما اعتقدت أنه لا يعتمد بشكل صريح على pygame وما إلى ذلك ، لست متأكدًا من سبب استغراقه وقتًا طويلاً!
سأحاول العثور على مزيد من المعلومات ولكن لدي أفضل وحدة المعالجة المركزية و SSD لذلك ما زلت أعتقد أن المشكلة تتعلق بإنترنتنا البطيء

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 إلخ.

لذلك استنشقت الطلبات المقدمة إلى files.pythonhosted.org ، واتضح أن pip أو pipenv كانا يقومان بتنزيلات غير ضرورية تمامًا ، مما يجعل lock بطيئًا بشكل مؤلم.

على سبيل المثال ، تم تنزيل الإصدار نفسه من numpy عدة مرات بالكامل. وقام بتنزيل العجلات لنظام التشغيل windows / linux ، على الرغم من أنني كنت أستخدم جهاز Mac.

الإعداد الخاص بي:

$ 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 ، وأي معلومات حول تشغيل العمليات / الأقفال / io قد تساعدك

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

انتهى أخيرًا بعد حوالي 6-7 دقائق. جديد تمامًا في Python و Pipenv ، لذا فإن القليل من المساعدة حول مكان العثور على الملفات الضرورية لتصحيح الأخطاء سيكون أمرًا رائعًا! :)

هذا أمر سيء للغاية لدرجة أنني أخشى تثبيت حزم بيثون جديدة أو ترقية العناصر الموجودة.

بعد مشاهدة إحدى المحادثات من المنشئ ، قررت استخدام pipenv . لكنها بطيئة للغاية.

شكرا لملاحظاتك الثاقبة.

techalchemy إذا كان هناك شيء يمكنني القيام به للمساعدة وإصلاح هذا. أنا سعيد جدا للمساهمة.

لقد لاحظت أن lock كان بطيئًا حقًا وقمت بتنزيل كمية هائلة من البيانات من files.pythonhosted.org ، أكثر من صغير يعتمد على scipy flask إلخ.

لدي شك ، على الرغم من عدم وجود دليل قاطع ، أن scipy مرتبط بأوقات قفل طويلة جدًا pipenv .

مؤلم حقًا في بعض الأحيان ، أقوم بتثبيت PyPDF2 و textract ؛ استغرق pipenv حوالي 10 دقائق للقفل.

إن بطء استخدام pipenv يعيق حقًا عملية التطوير بالنسبة لنا. أنصح الجميع الآن بالالتزام بـ pip + virtualenv حتى يتم حل هذه المشكلة.

أي أخبار عن هذا؟ اي طريقة للمساعدة؟
خداع https://github.com/pypa/pipenv/issues/1914

/ edit: راجع للشغل ، لماذا يقوم 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 .

أيضًا ، ماذا عن تثبيت هذه المشكلة؟

Pipenv هي أداة رائعة حقًا وكنت أوصي بها ، لكن لا يمكن قفل المشروع الذي يحتوي على 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

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

دون معرفة الكثير عما يحدث تحت غطاء محرك السيارة ، كنت أفكر في أنه يمكن حل هذا بشكل جيد باستخدام ذاكرة تخزين مؤقت محلية لمخطط التبعية.

فكر في الأمر: إذا قمنا بتخزين هذه الحزمة x-1.2.3 مؤقتًا تعتمد على y>=3.4 ، فيمكننا محليًا القيام بالكثير من العمل الذي يتم إجراؤه حاليًا في تنزيل الحزم واحدة تلو الأخرى ، وتوسيعها ، والتحقق من التبعيات . ستكون مرحلة lock بسيطة مثل:

• قارن ملف Pipfile بالذاكرة المؤقتة وتأكد من أن لدينا كل ما نحتاجه.
• إذا لم يكن كذلك ، فقم بتنزيل أي شيء جديد واحسب التبعيات هناك
  
  
  
  • تخزين التغييرات مؤقتًا
  
  
• تثبيت.

في كل حالة ، في حين أن المرة الأولى قد تكون بطيئة ، فإن الأقفال اللاحقة ستكون غير مؤلمة ، أليس كذلك؟

لقد قررت للتو استخدام pipenv بدلاً من pip لمشروع صغير. أول شيء فعلته كان pipenv install -r requirements.txt . لقد كان يقفل التبعيات لمدة 10 دقائق الآن. لذلك ، سأعود إلى النقطة.

يا رفاق ، هذه المشكلة تكلفك الكثير من المستخدمين. أقترح معالجته بسرعة.

في حالتي تثبيت التبعيات على الخادم توقف الخادم لساعات. أنا أستخدم مثيل AWS EC2 t2.micro مع 1 غيغابايت من ذاكرة الوصول العشوائي. هذا الحجم الكبير من ذاكرة الوصول العشوائي (RAM) كافٍ لتطبيق واحد مع بعض التبعيات ، لكن التثبيت يأخذ كل الذاكرة وهناك طريقة واحدة فقط لجعله يعمل عن طريق إعادة تشغيل الخادم.

هذه المشكلة معلقة لسنوات طويلة ولم يتم إصلاحها. أرى العديد من القضايا يتم إغلاقها دون أي حل.

هذه أداة جميلة يتم إهمالها. لن أقوم بإلغاء اشتراكي في هذه المشكلة لأنني أرى أنه لن يتم حلها أبدًا. سوف تلتزم بشيء مثل conda أو تفعل ذلك يدويًا باستخدام virtualenv.

أعتقد أنني سأعطي https://github.com/sdispater/poetry لقطة: |

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

يسعدني الاشتراك في تذكرة لتتبع العمل نحو حل المشكلة.

شكرا!

أظن أن 99 ٪ من الأشخاص الذين يستخدمون هذه الأداة ويشكون من هذا الموضوع هم من المبرمجين. بدلاً من التذمر ، ضع وقتك حيث يكون فمك وأرسل بيانًا عامًا.

مرحبا idvorkin ،

لقد حاولت مرة .
استغرق الأمر أسابيع لتحقيق دمج الإصلاح التافه .
ما عليك سوى مقارنة كمية المناقشات مع حجم الإصلاح الفعلي.

أنا بالتأكيد لا أريد تقديم أي إصلاحات أخرى لهذا المشروع.

لذا فإن نصيحتك ليست قابلة للتطبيق كما يمكنك أن تفترض.

Jamim نيابة عن العديد من المستخدمين (وأظن المشرفين أيضًا) ، شكرًا لك على مساهماتك. قرأت العلاقات العامة الخاصة بك ، ويمكنني أن أتعاطف مع الإحباط. ومع ذلك ، يجب أن أوافق مع techalchemy على هذا:

بالطبع نحن نهتم بالمكتبة التي نحافظ عليها ، لكنني أقترح أن الصياغة ربما ليست الطريقة الأكثر فاعلية للحصول على تفاعل إيجابي.

لم أقابل المديرين مطلقًا ، ولكن إذا كانوا مثلي (وربما أنت) فهم بشر بحياة مزدحمة وحياتهم مليئة بالالتزامات حتى قبل أن يكون لديهم الطاقة لإنفاقها على هذا المشروع.

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

أنا ممتن للوقت الذي يقضيه مطورو هذا المشروع على هذا ، لكنني أقترح أن يتم تحذيره بالخط العريض من أن هذا المشروع ليس جاهزًا بعد للإنتاج مباشرةً أعلى شهادات المستخدمين في README.md ، حاليًا هو تضليل الأشخاص لقضاء وقت ثمين لاستبدال مكدس pip / virtualenv الحالي بـ pipenv حتى يتعرفوا على هذا القفل البطيء ويفهمون أنهم لا يستطيعون استخدامه.

حتى يكتشفوا هذا القفل البطيء ويفهمون أنهم لا يستطيعون استخدامه.

بينما يسعدني جدًا الحصول على تسريع سريع نظرًا لأنه بطيء جدًا حقًا ، فلا داعي لمثل هذا المبالغة.

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

كم مرة تقفل أنها تتحول في الواقع إلى مشكلة تشعر أنك لا تستطيع استخدامها؟ :فتح الفم:

bochecha قد يكون بياني pipenv install <something> ، كان علي الانتظار لفترة طويلة يبعث على السخرية ، أولاً اعتقدت أنها تقوم بالحساب شيء ما وسيخزنه مؤقتًا للمستقبل حيث لم أصدق أنه مشكلة في الادعاء بأنك مدير حزم جاهز للإنتاج. بعد تثبيت الحزمة العاشرة تقريبًا ، بدأت في البحث عنها ووجدت هذا الموضوع ، قمت بإزالة Pipfile و Pipfile.lock وعدت إلى سير عمل pip / virtualenv الخاص بي. شعرت برغبة في تجربة الشعر لكنني لم أستطع المخاطرة بساعة أخرى.

تحدث هذه الأشياء في مجتمع JS على سبيل المثال ، لكنني لا أتوقع حدوث ذلك في مجتمع Python ، وليس لدينا هذا النوع من المشكلات في مجتمعنا ويجب أن نحاول تجنبه ، ويمكن تجنب إخلاء المسؤولية في README.md هذا الإزعاج لذلك اقترحته في تعليقي. يمكن أن يوفر وقتي اليوم وأعتقد أنه سيوفر الوقت للوافدين الجدد الآخرين ولن يكون لديهم تجربة سيئة مع هذا المشروع حتى يظلوا كمستخدمين محتملين في المستقبل.

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

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

في كل مرة قمت بتشغيل تثبيت pipenv

هل تعلم عن pipenv install -r requirements.txt للقفل / تثبيت مرة واحدة فقط من المشروع الموجودة عند محاولة نقله إلى pipenv؟ إذا لم تقم بذلك ، فقد تكون المشكلة تتعلق بالوثائق؟

قبل أي شيء أنا متأكد من أن pipenv سيكون بديلاً جيدًا لسير عمل pip / virtualenv ، أعتقد أننا جميعًا نعلم أننا بحاجة إليه وأعتقد أنه في اليوم الذي يكون فيه pipenv جاهزًا للإنتاج ، سيكون مفيدًا للعديد من الأشخاص / المشاريع.

bochecha كما أوضحت أنه كان علي تثبيت إصدار أحدث من الحزمة ، والقيام ببعض الأشياء ثم الانتقال إلى الحزمة التالية ، ربما إذا قمت بهذه العملية باستخدام pip ثم انتقلت إلى pipenv ، فلن ألاحظ المشكلة على الإطلاق ، لكنني انتقلت أولاً إلى pipenv ثم قمت بتحديث الحزمة واحدة تلو الأخرى وكان الأمر مزعجًا حقًا. أنا سعيد لأنه يعمل مع حالة استخدامك ، لكنني متأكد من أنه لا يعمل مع العديد من الأشخاص مثلي (ألق نظرة على التعليقات أعلاه). يجب ذكره في README.md ، على الأقل يجب الإشارة إلى أن "كل قفل قد يستغرق وقتًا طويلاً ، لذلك إذا كانت حالة الاستخدام الخاصة بك تتضمن تثبيت / إزالة الكثير من الحزم بسرعة ، يجب أن تتجنب استخدام pipenv حتى تنتهي هذه المشكلة تم حلها "(مرة أخرى بخط عريض ، وفوق الشهادات) إذا أعلنت عن المشاكل قبل أن يتأثر أي شخص بها ، فسيكون الجميع شاكرين ، إذا كانت المشاكل تؤثر على الآخرين ولم تحذرهم ، فسيغضب الجميع.

متفق. بدأت أبحث في الشعر وعلى الرغم من إضافة مستخدم آخر إلى نظام التشغيل الخاص بي لكل مشروع بدلاً من استخدام pipenv مرة أخرى. إذا لم يكن يعمل بشكل جيد في حالات الاستخدام غير الرسمية مع الإعدادات الافتراضية ، فسيتم كسره في
إنها أداة مفيدة للغاية! هناك فقط هذا الشيء الوحيد الذي يجعله عديم الفائدة بالنسبة لي. وللأسف لدي القليل من الوقت للمساهمة: |

بالتأكيد ، من المزعج انتظار القفل عند الاضطرار إلى إجراء عدة عمليات تثبيت في منتصف جلسة التطوير ، ولكن يمكن إدارة ذلك.

الشيء المهم هو أن يتم إنشاء ملف قفل قبل دفع التغييرات المحلية إلى الريبو. لقد استخدمتُ بحكمة علامة —skip-lock أثناء جلسات التطوير ، و pipenv lock مرة واحدة في النهاية قبل الالتزام.

شكرا على المشروع. ولكن،
القفل هو verrrrrrrrrrrrrrrrrrrrrrrrrrrrrrry بطيء www.wwwwwwwwwwwwwwwwwwwwwwwwwwww.

PIP_NO_CACHE_DIR=off
هذا المركب يجعل القفل أسرع ، إذا كان لديه ذاكرة تخزين مؤقت لحزمة النقطة مثبتة بالفعل.

مرحبًا yssource والجميع ،

شكرا على المشروع. ولكن،
القفل هو verrrrrrrrrrrrrrrrrrrrrrrrrrrrrrry بطيء www.wwwwwwwwwwwwwwwwwwwwwwwwwwww.

يبدو أن هذا المشروع قد انتهى ، لذا إذا كنت ترغب في التخلص من مشكلة السرعة ، فيرجى التفكير في الانتقال إلى Poetry وهو أسرع بكثير.

Jamim شكرا لاقتراح الشعر. أنا شخصياً ، لسبب ما لم أواجهها. بعد قراءة الملف التمهيدي الخاص به يبدو أنه يستحق المحاولة. كما يسرد بعض الفوائد على Pipenv أيضًا (https://github.com/sdispater/poetry/#what-about-pipenv).

بعد قولي هذا ، فإن المشروع ميت هو مبالغة فادحة ، وإذا كنت في مكان مؤلفي pipenv ، فسوف أجده غير محترم. أجاب المؤلف في قسم القضايا بالأمس فقط. إنها مجرد مشكلة قفل يتم التغاضي عنها ، ربما لأنه من الصعب إصلاحها.

وللتسجيل ، يعاني الشعر من مشاكل في الأداء أيضًا:
https://github.com/sdispater/poetry/issues/338

لدي نفس المشكلة في جميع مشاريعي.
يبدو أن السبب هو 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...

سمعت عن pipenv الكثير وجربته اليوم ،
القفل بطيء جدًا أيضًا بالنسبة لي. لقد مر بالفعل حوالي دقيقتين ، ولا يزال عالقًا في القفل.
التنزيل سريع جدًا ، لكن المشكلة تتعلق بالقفل.
هل تم حل هذه المشكلة؟
أنا أستخدم Pop os 19.10 ، pipenv ، الإصدار 11.9.0 من apt ، python 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 شكرا على الاقتراح ، سأحاول بالتأكيد