<p>تثبيت pipenv بطيء جدًا</p>

مرحبًا مرة أخرى Diggsey ، هذا بسبب الطريقة التي نكتب بها التغييرات الآن. لديّ هذه التغييرات جاهزة للدمج ، لكنها تتعطل لـ projects.py API ، لذا سننتظر حتى الإصدار الرئيسي التالي. نأمل أن يكون لدينا هذا وجاهز في الأسابيع القليلة المقبلة. سأترك هذا مفتوحًا لتتبع المشكلة في الوقت الحالي.

انطلقنا في هذا معًا في PyCon. سيكون أسرع قريبا.

الآن بالنسبة لي ليس بطيئًا ، إنه يتجمد ...

A pipenv install my_package أو بسيط pipenv install لا يعطيني أي ناتج بعد 20 دقيقة.

تحرير: تأكيد ، لا شيء بعد بضع ساعات. هل هي نفس المشكلة؟ عادة ما كانت بطيئة ، لكنها تنتهي بعد 5 إلى 10 دقائق.

مرحبًا NicolasWebDev ، ما هو إصدار pipenv الذي تستخدمه؟ هل لديك أيضًا delegator.py مثبتًا على نظامك بشكل منفصل؟ إذا كان الأمر كذلك ، فما هو الإصدار الموجود؟ كانت هذه مشكلة يجب حلها في الإصدار 3.6.0.

إذا كان كل ما ورد أعلاه محدثًا ، فهل يمكنك تقديم محتويات ملف Pipfile؟ شكرا!

مرحبًا nateprewitt ، كنت على حق ، كنت على v3.5.x. أدى التحديث إلى 4.1.1 إلى حل مشكلة التجميد. الآن لا يزال الأمر يستغرق 5 دقائق ، لكنه على الأقل قابل للاستخدام!

آسف للضوضاء ، أنسى دائمًا أن الحزم المثبتة عبر النقطة لا يتم تحديثها تلقائيًا.
شكرا!

سعيد لأنك حصلت على حل للأشياءNicolasWebDev! نحن نعمل على تسريع هذا الأمر أكثر ، ونأمل أن يكون # 373 أقرب خطوة في الإصدار التالي.

DiggseyNicolasWebDev، لقد صدر للتو 4.1.2 الذي ينبغي أن يكون هذه التحسينات سرعة إضافية. لا يزال هناك بعض العمل الذي يتعين القيام به هنا ، ولكن هذا على الأقل سيعجل وقت التمهيد الأولي لـ pipenv.

nateprewitt نشكرك على التحديث ، يبدو أن pipenv أسرع بالنسبة لي الآن ، ولكن لا يزال الأمر يستغرق عدة دقائق لتشغيل pipenv lock ، حتى عندما لا يتغير شيء - لا يزال ينتظر في Locking [packages] dependencies... للثروة الكبيرة غالبية ذلك الوقت.

Diggsey ،

nateprewitt يمكننا إزالة بعضها ، لكن الغالبية منها تبعيات مباشرة - لماذا تحتاج إلى تنزيل جميع التبعيات في كل مرة تنشئ فيها ملف القفل؟

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

بالنظر إلى أن معظم الحزم ستبقى كما هي بمرور الوقت ، فهل من الممكن تخزين الحزم التي تم تنزيلها مؤقتًا؟

Diggsey تريد أن ننظر في ذلك بالنسبة لنا؟

قد يكون هذا سؤالًا سخيفًا ، لكن ألا يقوم Pip بالفعل بالتخزين المؤقت للحزم ؟

لدي انطباع بأنه يفعل ذلك.

هل يمكن لـ pipenv استخدام نظام التخزين المؤقت لـ pip أم يجب تنفيذه من البداية؟

يقوم Pipenv بتشغيل النقطة فقط ، لذلك يجب استخدام ذاكرة التخزين المؤقت تلقائيًا.

مثبت! قفل شرير سريع الآن.

اوه شكرا لك. أعتقد أن هذا كان الشيء الوحيد الذي يمنع ظهري من دفع الجميع إلى pipenv في العمل.

رائع ، رائع ، لقد كان ذلك حرفياً أكثر من تسريع 100 مرة بالنسبة لي ، كما أنه اكتشف تعارضًا في التبعية لم يكتشفه الإصدار السابق!

ما قد يكون مفيدًا هو علامة verbose لـ pipenv lock - لقد كنت قادرًا فقط على تشخيص تعارض التبعية عن طريق تحرير piptools/logging.py لتمكين التسجيل المطول ، ولكن بمجرد أن فعلت ذلك ، أعطت دلالة واضحة جدا على ما كان يجري.

ربما أفتقد شيئًا ما :) أين يتم إصلاحه؟ أحدث إصدار منذ 4 أيام ، لذلك قمت بتثبيت أحدث إصدار من master . ومع ذلك ، لا يزال pipenv install بطيئًا.

حاولت:

• تثبيت pipenv بالطريقة الفاخرة ⚡️ 🍰 ⚡️
• استخدم كلاً من الإصدار الأخير المنشور من pipenv وأحدث إصدار من master
• تثبيت حزمة واحدة

باستخدام أحدث إصدار مستقر (5.3.5.) ، يستغرق تثبيت حزمة واحدة 3:40:

∙ time pipenv install --dev raven
Installing raven...
Collecting raven
  Using cached raven-6.1.0-py2.py3-none-any.whl
Collecting contextlib2 (from raven)
  Using cached contextlib2-0.5.5-py2.py3-none-any.whl
Installing collected packages: contextlib2, raven
Successfully installed contextlib2-0.5.5 raven-6.1.0

Adding raven to Pipfile's [dev-packages]...
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock!
pipenv install --dev raven  10,11s user 2,77s system 5% cpu 3:40,04 total

باستخدام إصدار من master ، لا يزال معلقًا (حزمة واحدة ، +10 دقائق)

تحرير: لقد انتهى للتو:

pipenv install graphene_django  8,03s user 1,28s system 1% cpu 11:23,11 total

أيه أفكار؟ شكرا جزيلا!

في بعض الأحيان يستغرق تثبيت التبعيات بعض الوقت ، خاصةً إذا كان لديهم تجميعات c. هل تريد مشاركة Pipfile ؟

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

هذا هو ملفي Pipfile:

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

[dev-packages]
pytest = "*"
pytest-django = "*"
pytest-testmon = "*"
pytest-watch = "*"
django-debug-toolbar = "*"
raven = "*"

[packages]
dj-database-url = "*"
Django = "*"
djangorestframework = "*"
gunicorn = "*"
newrelic = "*"
psycopg2 = "*"
requests = "*"
whitenoise = "*"
graphene-django = "*"

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

استغرق $ pipenv install raven مثل 1 ثانية بالنسبة لي.

استغرق تثبيت الغراب $ pipenv فقط مثل 1s بالنسبة لي.

هذا ما كنت أتوقعه! هل يمكنني تشغيل الإخراج المطول بطريقة ما؟

حاولت إزالة psycopg2 ، لكن ذلك لا يؤثر كثيرًا. يتوقف تشغيل pipenv install raven لبعض الوقت.

عندي:

• بايثون 3.6.2
• macOS 10.12.6

لا أرى أي سبب يمنع الغراب من أن يكون لحظيًا.

افعل $ pip install raven داخل $ pipenv shell وأخبرني إذا كان بطيئًا هناك أيضًا.

كل ما يفعله pipenv هو تشغيل النقطة ، لذلك هذا هو "الوضع المطول" بشكل فعال

هذه لحظة:

∙ time pip install raven                                                                                                                                 19:38  tricoder<strong i="6">@issac</strong>
Requirement already satisfied: raven in /Users/tricoder/.envs/lingui-api-VE1OToiy/lib/python3.6/site-packages
Requirement already satisfied: contextlib2 in /Users/tricoder/.envs/lingui-api-VE1OToiy/lib/python3.6/site-packages (from raven)
noglob pip install raven  0,54s user 0,15s system 76% cpu 0,900 total

يتوقف تشغيل pipenv حوالي 2-3 دقائق (داخل / خارج pipenv shell ).

∙ time pipenv install raven                                                                                                                              19:39  tricoder<strong i="12">@issac</strong>
Installing raven...
Requirement already satisfied: raven in /Users/tricoder/.envs/lingui-api-VE1OToiy/lib/python3.6/site-packages
Requirement already satisfied: contextlib2 in /Users/tricoder/.envs/lingui-api-VE1OToiy/lib/python3.6/site-packages (from raven)

Adding raven to Pipfile's [packages]...
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock!
pipenv install raven  4,49s user 0,46s system 2% cpu 3:21,17 total

Diggsey ، هل يمكنك فتح إصدار جديد حول --verbose وتقديم مثال على الشكل الذي تريده؟

@ tricoder42 هل الجزء البطيء هو خطوة القفل أم خطوة التثبيت؟ تم تحسين القفل بشكل كبير في أحدث الإصدارات.

"قذيفة
$ time pipenv تثبيت الغراب
جارٍ تثبيت الغراب ...
جمع الغراب
باستخدام ذاكرة التخزين المؤقت raven-6.1.0-py2.py3-none-any.whl
تم تلبية المتطلبات بالفعل: Contextlib2 في /Users/kennethreitz/.local/share/virtualenvs/pipenv-u9yqWeFK/lib/python3.6/site-packages (من الغراب)
تركيب الحزم المجمعة: الغراب
تم تثبيت raven-6.1.0 بنجاح

جارٍ إضافة الغراب إلى [حزم] Pipfile ...
جاري قفل تبعيات [حزم التطوير] ...
تأمين تبعيات [الحزم] ...
تم تحديث Pipfile.lock!
9.30 ريال 5.49 مستخدم 0.42 نظام

إنه مثل 50:50 أنا n installing: locking

@ tricoder42 وأنت تستخدم الأحدث؟

اسمحوا لي أن أكرر مع ملف الأنابيب الخاص بك بالضبط.

أظن ذلك:

∙ pipenv --version                                                                                                                                       19:42  tricoder<strong i="6">@issac</strong>
pipenv, version 5.3.5

∙ pipsi upgrade git+https://github.com/kennethreitz/pipenv.git#egg=pipenv                                                                                19:45  tricoder<strong i="9">@issac</strong>
Collecting pipenv from git+https://github.com/kennethreitz/pipenv.git#egg=pipenv
  Cloning https://github.com/kennethreitz/pipenv.git to /private/var/folders/g9/1wbckv154mbby3tm411z_m340000gn/T/pip-build-se4ao5/pipenv
...
Installing collected packages: pipenv
  Found existing installation: pipenv 5.3.5
    Uninstalling pipenv-5.3.5:
      Successfully uninstalled pipenv-5.3.5
  Running setup.py install for pipenv ... done
Successfully installed pipenv-5.3.5

"قذيفة
$ time pipenv التثبيت
لم يتم توفير حزمة ، تثبيت جميع التبعيات.
تم العثور على Pipfile في / Users / kennethreitz / pipenv / testapp / Pipfile. معتبرة أن هذا هو منزل المشروع.
لم يتم العثور على Pipfile.lock ، جاري إنشاء ...
جاري قفل تبعيات [حزم التطوير] ...
تأمين تبعيات [الحزم] ...
تم تحديث Pipfile.lock!
تثبيت التبعيات من Pipfile.lock ...
[=================================] 22/22 - 00:00:37
58.94 مستخدم حقيقي 40.51 8.62 نظام

إنه يفعل حتى عندما أقوم بتثبيت الحزمة الأولى في pipenv جديدة جديدة. سأحاول إنشاء pipenv --three بدلاً من pipenv --python python3.6

@ tricoder42 تريد القفز على جوجل Hangouts في مثل ساعة؟

أو يمكننا استخدام مشاركة شاشة Apple إذا كنت تستخدم تطبيق Messages.

أضفني! أنا [email protected].

أنا على وشك الانضمام إلى اجتماع ، لكنني سأكون متاحًا بعد ذلك.

رائع! سأحاول تنظيف وإعادة تثبيت كل شيء من البداية وسنرى. أنا متواجد في ساعة واحدة

رائع - سنكتشف ذلك بعد ذلك. أضفني على تطبيق messages.app :)

إذا كان أي شخص يعاني من سلوك بطيء للغاية مع Locking مع v11.9.0 ، فقد وجدت أن الرجوع إلى v9.0.0 يتطلب تثبيتًا لمدة 5 دقائق و 30 ثانية حتى 1 دقيقة و 36 ثانية.

ryantuck أوصي إذا كنت 9.0.3 لكنك تفقد قدرًا كبيرًا من الأمان الإضافي للسرعة ، يمكنك أيضًا استخدام --skip-lock في هذه النقطة

--skip-lock يسرع الأمور بالتأكيد. ذهبت في هذا المسار لأن pipenv install --system --python=3.6 لم يكن مثبتًا بالفعل على نظام Python الصحيح ، وكنت على افتراض أنني بحاجة إلى إنشاء Pipfile.lock قبل محاولة تثبيت النظام. ما زال لا يعمل ، لذلك عدت إلى استخدام pip القديم العادي ، لكنني سأعود للتعليق على هذا الموضوع إذا أحرزت أي تقدم على هذا المنوال.

—system و —python متنافيان - يحتاج الخيار الأخير دائمًا إلى Virtualenv

نعم ، القفل يستغرق بعض الوقت بالنسبة لي أيضًا. الإصدار 11.10.0. Ubuntu على WSL.

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

[packages]
babel = "==2.5.3"
"boto3" = "==1.7.3"
colorama = "==0.3.9"
coreapi = "==2.3.3"
dj-database-url = "==0.5.0"
djangorestframework = "==3.7.7"
django-axes = "==4.0.2"
django-clever-selects = "==0.8.2"
django-crispy-forms = "==1.7.2"
django-choices = "==1.6.0"
django-extra-views = "==0.10.0"
django-filter = "==1.1.0"
django-hijack = "==2.1.7"
django-hijack-admin = "==2.1.7"
django-js-reverse = "==0.8.1"
django-model-utils = "==3.1.1"
django-phonenumber-field = "==2.0.0"
django-polymorphic = "==2.0.2"
django-redis-cache = "==1.7.1"
django-role-permissions = "==2.2.0"
"django-s3direct" = "==1.0.4"
django-static-precompiler = {extras = ["libsass"], version = "==1.8.2"}
django-storages = "==1.6.6"
"django-tables2" = "==1.21.2"
django-webpack-loader = "==0.6.0"
django-widget-tweaks = "==1.4.2"
facebookads = "==2.11.4"
googleads = "==11.0.1"
markdown = "==2.6.11"
phonenumbers = "==8.9.3"
pillow = "==5.1.0"
"psycopg2-binary" = "==2.7.4"
pygments = "==2.2.0"
pyssim = "==0.4"
python-dotenv = "==0.8.2"
pytz = "==2018.4"
raven = "==6.6.0"
sendgrid-django = "==4.2.0"
slacker = "==0.9.65"
termcolor = "==1.1.0"
tqdm = "==4.21.0"
twitter-ads = "==3.0.0"
brotlipy = "==0.7.0"
waitress = "==1.1.0"
whitenoise = "==3.3.1"
Django = "==2.0.4"

[dev-packages]
coverage = "==4.5.1"
selenium = "==3.11.0"
tblib = "==1.3.2"
"flake8" = "==3.5.0"
django-debug-toolbar = "==1.9.1"
django-extensions = "==2.0.6"

[requires]
python_version = "3.6"

Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (7a535c)!
Installing dependencies from Pipfile.lock (7a535c)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:01:01

real    8m1.993s
user    5m32.406s
sys     7m15.203s

يجب أن يكون أسرع قليلاً في المرة الثانية أو الثالثة بسبب
التخزين المؤقت مع ذلك. هل ترى تحسنا؟
يوم الخميس 12 أبريل 2018 الساعة 10:23 صباحًا ألكسندر كافانو <
[email protected]> كتب:

نعم ، القفل يستغرق بعض الوقت بالنسبة لي أيضًا. الإصدار 11.10.0. Ubuntu على WSL.

[[المصدر]] url = " https://pypi.python.org/simple " verification_ssl = truename = "pypi"
[الحزم] babel = "== 2.5.3" "boto3" = "== 1.7.3" colorama = "== 0.3.9" coreapi = "== 2.3.3" dj-database-url = "== 0.5.0 "djangorestframework =" == 3.7.7 "django-axes =" == 4.0.2 "django-clever-selects =" == 0.8.2 "django-crispy-Forms =" == 1.7.2 " django-options = "== 1.6.0" django-extra-views = "== 0.10.0" django-filter = "== 1.1.0" django-hijack = "== 2.1.7" django-hijack- admin = "== 2.1.7" django-js-reverse = "== 0.8.1" django-model-utils = "== 3.1.1" django-phonenumber-field = "== 2.0.0" django- polymorphic = "== 2.0.2" django-redis-cache = "== 1.7.1" django-role-الأذونات = "== 2.2.0" "django-s3direct" = "== 1.0.4" django- static-precompiler = {extras = ["libsass"] ، الإصدار = "== 1.8.2"} django-storages = "== 1.6.6" "django-table2" = "== 1.21.2" django-webpack -loader = "== 0.6.0" django-widget-tweaks = "== 1.4.2" facebookads = "== 2.11.4" googleads = "== 11.0.1" markdown = "== 2.6.11" أرقام الهاتف = "== 8.9.3" وسادة = "== 5.1.0" "psycopg2-binary" = "== 2.7.4" pygments = "== 2.2.0" pyssim = "== 0.4" python-dotenv = "== 0.8.2" pytz = "== 2018.4" غراب = "== 6.6.0" sendgrid-django = "== 4.2.0" slacker = "== 0.9.65" termcolor = "== 1.1.0" tqdm = "== 4.21.0" twitter-ads = "== 3.0.0" brotlipy = "== 0.7.0" نادلة = "== 1.1.0" whitenoise = "== 3.3.1" Django = "== 2.0.4"
تغطية [حزم التطوير] = "== 4.5.1" سيلينيوم = "== 3.11.0" tblib = "== 1.3.2" "flake8" = "== 3.5.0" django-debug-toolbar = " == 1.9.1 "ملحقات django =" == 2.0.6 "
[يتطلب] python_version = "3.6"

لم يتم العثور على Pipfile.lock ، جارٍ إنشاء…
قفل تبعيات [حزم التطوير] ...
تأمين تبعيات [الحزم] ...
تحديث Pipfile.lock (7a535c)!
تثبيت التبعيات من Pipfile.lock (7a535c) ...
🐍 ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 - 00:01:01

8 م 1.993 ثانية
المستخدم 5m32.406s
7 د 15.203 ث

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/pypa/pipenv/issues/356#issuecomment-380882203 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/ABhjqwIPyHtX0NTVoV1UPYR7HcwYm-2kks5tn42SgaJpZM4NbeoN
.

لقد قمت بالفعل بتثبيت الحزم قبل ذلك ؛ لقد قمت للتو بإزالة ملف القفل وتشغيل التثبيت مرة أخرى. سأفعل ذلك مرة أخرى للحصول على نقطة بيانات أخرى

تضمين التغريدة مثير جدًا للاهتمام ... ما الذي يجعل التخزين المؤقت يبدأ بعد المرة الثالثة + فقط؟

Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (7a535c)!
Installing dependencies from Pipfile.lock (7a535c)…
An error occurred while installing coreapi==2.3.3! Will try again.
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:00:58
Installing initially–failed dependencies…
Success installing coreapi==2.3.3!▉▉▉ 0/1 — 00:00:00
  ☤  ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 1/1 — 00:00:01

real    2m50.218s
user    2m19.438s
sys     5m44.797s

Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (7a535c)!
Installing dependencies from Pipfile.lock (7a535c)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 92/92 — 00:00:55

real    2m32.042s
user    2m6.516s
sys     5m10.219s

kavdevjtratner أدخلت ميزة لذاكرة التخزين المؤقت التجزئة فضلا بحيث ينبغي أن تحسن كبير

أنا هنا ... بعد 15 دقيقة

giantas غير مفيد. يرجى تقديم ملف الأنابيب والإخراج والمدة مع تثبيت النقطة. أيضا ما إذا كان يمكنك عمل حزم غير مفهومة.

يستغرق الأمر الكثير للتشغيل على جهازي. macOS 10.13.4 ، pipenv ، الإصدار 11.10.0

يتم تشغيل التنزيل على الفور تقريبًا ، ولكن بعد ذلك يتعطل عند Locking [packages] dependencies… . هنا يستغرق نصف دقيقة لاثنين من التبعيات ، ثم 6 دقائق لثلاث تبعيات أخرى ، إذا ألقيت كل تبعيات مشروعي عليه ، فإنه يتوقف إلى أجل غير مسمى عند خطوة القفل

pablo<strong i="8">@batman</strong> scanr (develop) $ time pipenv install flask flask_pymongo
Installing flask…
Looking in indexes: https://pypi.python.org/simple
Collecting flask
  Using cached https://files.pythonhosted.org/packages/77/32/e3597cb19ffffe724ad4bf0beca4153419918e7fa4ba6a34b04ee4da3371/Flask-0.12.2-py2.py3-none-any.whl
Collecting Werkzeug>=0.7 (from flask)
  Using cached https://files.pythonhosted.org/packages/20/c4/12e3e56473e52375aa29c4764e70d1b8f3efa6682bef8d0aae04fe335243/Werkzeug-0.14.1-py2.py3-none-any.whl
Collecting itsdangerous>=0.21 (from flask)
Collecting Jinja2>=2.4 (from flask)
  Using cached https://files.pythonhosted.org/packages/7f/ff/ae64bacdfc95f27a016a7bed8e8686763ba4d277a78ca76f32659220a731/Jinja2-2.10-py2.py3-none-any.whl
Collecting click>=2.0 (from flask)
  Using cached https://files.pythonhosted.org/packages/34/c1/8806f99713ddb993c5366c362b2f908f18269f8d792aff1abfd700775a77/click-6.7-py2.py3-none-any.whl
Collecting MarkupSafe>=0.23 (from Jinja2>=2.4->flask)
Installing collected packages: Werkzeug, itsdangerous, MarkupSafe, Jinja2, click, flask
Successfully installed Jinja2-2.10 MarkupSafe-1.0 Werkzeug-0.14.1 click-6.7 flask-0.12.2 itsdangerous-0.24

Adding flask to Pipfile's [packages]…
Installing flask_pymongo…
Looking in indexes: https://pypi.python.org/simple
Collecting flask_pymongo
  Using cached https://files.pythonhosted.org/packages/fa/71/ab920741dedd605ef4adbd57d0c7d9f43a6b6fe4068604fffbc6f64b2c9c/Flask_PyMongo-0.5.1-py3-none-any.whl
Requirement already satisfied: Flask>=0.8 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from flask_pymongo) (0.12.2)
Collecting PyMongo>=2.5 (from flask_pymongo)
  Using cached https://files.pythonhosted.org/packages/5c/7f/1f7240883ec3fa768d7e066c9cbd42ceb42d699ba1a0fb9d231c098a542d/pymongo-3.6.1-cp36-cp36m-macosx_10_6_intel.whl
Requirement already satisfied: click>=2.0 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Flask>=0.8->flask_pymongo) (6.7)
Requirement already satisfied: itsdangerous>=0.21 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Flask>=0.8->flask_pymongo) (0.24)
Requirement already satisfied: Werkzeug>=0.7 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Flask>=0.8->flask_pymongo) (0.14.1)
Requirement already satisfied: Jinja2>=2.4 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Flask>=0.8->flask_pymongo) (2.10)
Requirement already satisfied: MarkupSafe>=0.23 in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from Jinja2>=2.4->Flask>=0.8->flask_pymongo) (1.0)
Installing collected packages: PyMongo, flask-pymongo
Successfully installed PyMongo-3.6.1 flask-pymongo-0.5.1

Adding flask_pymongo to Pipfile's [packages]…
Pipfile.lock (c202d3) out of date, updating to (3068be)…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (3068be)!
Installing dependencies from Pipfile.lock (3068be)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 32/32 — 00:00:03
To activate this project's virtualenv, run the following:
 $ pipenv shell

real    0m37.816s
user    0m34.556s
sys 0m4.517s

pablo<strong i="5">@batman</strong> scanr (develop) $ time pipenv install gunicorn h5py joblib
Installing gunicorn…
Looking in indexes: https://pypi.python.org/simple
Collecting gunicorn
  Using cached https://files.pythonhosted.org/packages/64/32/becbd4089a4c06f0f9f538a76e9fe0b19a08f010bcb47dcdbfbc640cdf7d/gunicorn-19.7.1-py2.py3-none-any.whl
Installing collected packages: gunicorn
Successfully installed gunicorn-19.7.1

Adding gunicorn to Pipfile's [packages]…
Installing h5py…
Looking in indexes: https://pypi.python.org/simple
Collecting h5py
  Using cached https://files.pythonhosted.org/packages/69/d5/dff2a8f7658fd87ab3330a0ab47e4363681d8bdf734a495add65a347f5e3/h5py-2.7.1-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
Requirement already satisfied: six in /Users/pablo/.local/share/virtualenvs/scanr-2m6AW0PB/lib/python3.6/site-packages (from h5py) (1.11.0)
Collecting numpy>=1.7 (from h5py)
  Using cached https://files.pythonhosted.org/packages/a0/df/fa637677800e6702a57ef09e1d62e42aec3f598fb235f897155d146f2f59/numpy-1.14.2-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, h5py
Successfully installed h5py-2.7.1 numpy-1.14.2

Adding h5py to Pipfile's [packages]…
Installing joblib…
Looking in indexes: https://pypi.python.org/simple
Collecting joblib
  Using cached https://files.pythonhosted.org/packages/4f/51/870b2ec270fc29c5d89f85353da420606a9cb39fba4747127e7c7d7eb25d/joblib-0.11-py2.py3-none-any.whl
Installing collected packages: joblib
Successfully installed joblib-0.11

Adding joblib to Pipfile's [packages]…
Pipfile.lock (0d514f) out of date, updating to (a4d15f)…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (a4d15f)!
Installing dependencies from Pipfile.lock (a4d15f)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 36/36 — 00:00:03
To activate this project's virtualenv, run the following:
 $ pipenv shell

real    6m31.572s
user    1m1.986s
sys 0m11.047s

@ بابلوتي حماقة المقدسة التي هي بطيئة! هل لاحظ أن هذا يرجع جزئيًا إلى تثبيت numpy ، وأنا متأكد من أننا نقوم بالتجميع من المصدر إلى القفل أو شيء غبي. سيساعدنا إذا قدمنا ​​ناتجًا مفيدًا هنا

هل هناك أي شيء يمكنني القيام به حيال ذلك؟ أو لم يحالفني الحظ في استخدام pipenv ووجود ملفات القفل البطيئة هذه؟ أعتقد أنني أستطيع - تخطي القفل لكنني أردت نوعًا ما هذه الميزة

pablote هل يمكنك التحقق مما إذا كنت تعيد تشغيل عملية القفل نفسها ، هل ما زالت بطيئة؟

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

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

يُرجى إعلامي إذا كانت هناك أي معلومات يمكنني تقديمها للمساعدة في التشخيص. في الوقت الحالي ، سأعود إلى أدوات pip + virtualenv + pip: /

pablote بمجرد حصولك على التجزئات مرة واحدة ، لن يكون القفل مرة أخرى بهذه البطء

من فضلك ، يرجى تقديم مخرجات مفيدة. لقد قمت للتو بترقية pipenv من 9.1.0 إلى 11.10.0 من أجل حل فشل Marker غير صالح في خطوة قفل الحزمة وفقًا ، على سبيل المثال ، # 1622 - الآن ، لدي ملف pipfile مع ipykernel ، pandas ، jupyter ، numpy ، و matplotlib هناك ومع محاولتي الأخيرة لاستخدام pipenv install لبدء تشغيل ملف القفل ، كنت جالسًا في locking [packages] dependencies… لما يزيد عن 10 دقائق.

نظرًا لعدم وجود ناتج ، لا يمكنني معرفة ما إذا كان هناك شيء ما يحدث بالفعل (مثل البناء الخرساني من المصدر) أو ما إذا كان معلقًا فقط. أفضل ما يمكنني فعله هو نوع من التحديق عند top واستنتج أنه ربما يفعل شيئًا ما لأن عملية Python تبدو معلقة ... ولكن سأضطر إلى التخلص من هذا virtualenv والبدء من جديد إذا شيء لا يتحرك قريبا.

يسعدني المساهمة في بعض الأعمال المتعلقة بهذا الأمر إذا لزم الأمر.

من فضلك ، يرجى تقديم مخرجات مفيدة. لقد قمت للتو بترقية pipenv الخاص بي من 9.1.0 إلى 11.10.0 من أجل حل فشل Marker غير صالح في خطوة قفل الحزمة وفقًا ، على سبيل المثال ، # 1622 - الآن ، لدي ملف pipfile مع ipykernel ، pandas ، jupyter ، numpy ، و matplotlib هناك ومع محاولتي الأخيرة لاستخدام تثبيت pipenv لبدء تشغيل ملف القفل ، كنت جالسًا في قفل تبعيات [الحزم] ... لما يزيد عن 10 دقائق.

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

سؤال واحد: هل تستخدم PyPI العامة؟

jtratner نعم ، باستخدام PyPi العام --- وفي النهاية انتهيت من الاستسلام ، وحطمت Virtualenv وبناء واحدة جديدة ؛ لقد تمكنت من الحصول على ملف قفل تم إنشاؤه عن طريق تثبيت التبعيات الخاصة بي واحدة تلو الأخرى. (من المثير للاهتمام أن matplotlib كان الأبطأ - بل أسوأ من العدم!)

ربما تساعد رسالة مثل This may take a long time في طمأنة الناس حتى يتم تحديد حل أكثر وضوحًا.

15 دقيقة لا تزال طويلة بجنون وأشك في أنني سأجلس وأنتظر ذلك. paultopia يمكنك تشغيل pipenv lock —verbose لمزيد من الإنتاج

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

نحن بحاجة لمعرفة ما يفعله ...

لقد قمت بإنشاء مشروع جيثب يظهر البطء عند استخدام القفل. يرجى إلقاء نظرة على https://github.com/AndreasPresthammer/slow-pipenv . أنا لست متأكدًا بنسبة 100٪ أن هذه هي نفس المشكلة بالرغم من ذلك. اسحب الريبو لأسفل وقم بتشغيل البرنامج النصي slow.sh ، ولاحظ الفرق في وقت التنفيذ.

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

لا تزال هذه مشكلة بالتأكيد (أكثر من 5 دقائق) ، مع أحدث إصدارات python3.6 و pip و pipenv وتثبيت حزمة بسيطة مثل torch . لا أعتقد أنه يجب وضع علامة على هذه المشكلة على أنها مغلقة.

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

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

هنا سجل pipenv lock --verbose ، بما في ذلك Pipfile و Pipfile.lock :

https://gist.github.com/mimischi/6270b7ece566cc571b427baaf1c331d4

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

FWIW ، يستغرق تأمين صندوق التطوير الآن أقل من 30 ثانية. أفضل بكثير من ذي قبل - نقدر ذلك.

مرحبًا ، لدي نفس المشكلة.
هنا هو مطول

pipenv lock --verbose
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.org/simple

                          ROUND 1                           
Current constraints:
  pylint

Finding the best candidates:
  found candidate pylint==1.9.1 (constraint was <any>)

Finding secondary dependencies:
  pylint==1.9.1             requires astroid<2.0,>=1.6, isort>=4.2.5, mccabe, six

New dependencies found in this round:
  adding ['astroid', '<2.0,>=1.6', '[]']
  adding ['isort', '>=4.2.5', '[]']
  adding ['mccabe', '', '[]']
  adding ['six', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2                           
Current constraints:
  astroid<2.0,>=1.6
  isort>=4.2.5
  mccabe
  pylint
  six

Finding the best candidates:
  found candidate astroid==1.6.4 (constraint was >=1.6,<2.0)
  found candidate isort==4.3.4 (constraint was >=4.2.5)
  found candidate mccabe==0.6.1 (constraint was <any>)
  found candidate pylint==1.9.1 (constraint was <any>)
  found candidate six==1.11.0 (constraint was <any>)

Finding secondary dependencies:
  pylint==1.9.1             requires astroid<2.0,>=1.6, isort>=4.2.5, mccabe, six
  astroid==1.6.4            requires lazy-object-proxy, six, wrapt
  isort==4.3.4              requires -
  mccabe==0.6.1             requires -
  six==1.11.0               requires -

New dependencies found in this round:
  adding ['lazy-object-proxy', '', '[]']
  adding ['wrapt', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 2: not stable

                          ROUND 3                           
Current constraints:
  astroid<2.0,>=1.6
  isort>=4.2.5
  lazy-object-proxy
  mccabe
  pylint
  six
  wrapt

Finding the best candidates:
  found candidate astroid==1.6.4 (constraint was >=1.6,<2.0)
  found candidate isort==4.3.4 (constraint was >=4.2.5)
  found candidate lazy-object-proxy==1.3.1 (constraint was <any>)
  found candidate mccabe==0.6.1 (constraint was <any>)
  found candidate pylint==1.9.1 (constraint was <any>)
  found candidate six==1.11.0 (constraint was <any>)
  found candidate wrapt==1.10.11 (constraint was <any>)

Finding secondary dependencies:
  astroid==1.6.4            requires lazy-object-proxy, six, wrapt
  wrapt==1.10.11            requires -
  lazy-object-proxy==1.3.1  requires -
  six==1.11.0               requires -
  pylint==1.9.1             requires astroid<2.0,>=1.6, isort>=4.2.5, mccabe, six
  mccabe==0.6.1             requires -
  isort==4.3.4              requires -
------------------------------------------------------------
Result of round 3: stable, done

Locking [packages] dependencies…

هذا هو pipenv --version : pipenv ، الإصدار 2018.05.18

كما أنني لا أعرف سبب حدوث ذلك ، ولا يوجد سبب / خطأ محدد.
في حالتي عندما أفعل pipenv lock يبدأ الأمر لكنه لا ينتهي أبدًا على حد علمي. لقد كنت أنتظر لمدة ساعتين حتى الآن ما زلت لا توجد علامة على الانتهاء. وقد أعطاني ReadTimeoutError مرتين هذه هي المرة الثالثة التي أفعل فيها هذا.
باستخدام Python 3.6.4

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

أيضا التصويت لهذه القضية ليتم إعادة فتحها. إنه بعيد عن الحل .... يستغرق ما بين 10 إلى 20 دقيقة لقفل مشروعي داخل حاوية Docker. كما أنه يستخدم قدرًا مجنونًا من الذاكرة - لدرجة أنني اضطررت إلى زيادة التخصيص لـ Docker لمنعه من قتل العملية.

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

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

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

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

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

لقد أجريت بعض التصحيح عن طريق تثبيت mitmproxy بين pipenv والشبكة لتتبع الطلبات التي يتم إجراؤها. لقد وجدت بعض الأشياء المثيرة للاهتمام.

1. نحن نستخدم فهرسًا خاصًا pypi لا يدعم json-api حتى الآن. يؤدي هذا إلى إبطاء الأمور بشكل كبير نظرًا لأنه يبدو أن الإجراء الاحتياطي يتمثل في القوة الوحشية وتنزيل كل شيء مدرج في فهرس http من أجل استخراج البيانات الوصفية وما إلى ذلك. قد يكون أحد الاقتراحات هنا مجرد إضافة بعض التسجيلات البسيطة للتحذير من استخدام هذه الطريقة الاحتياطية - إنها قد ينقذ شخصًا آخر من الاضطرار إلى البحث بشكل أعمق لمعرفة ذلك.

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

سأستمر في تصحيح الأخطاء والإبلاغ عن أي معلومات مفيدة كما أجدها.

يبدو أنه حتى مع استخدام واجهة json pipenv تقدم طلبات غير ضرورية لملفات العجلة التي تتعلق ببنيات مختلفة. يعد التنفيذ حاليًا ساذجًا جدًا لأنه يتحقق من جميع الملفات المدرجة مقابل إصدار معين ، بغض النظر عن النظام الأساسي / القوس الهدف.

الحد الأدنى من حالة الاختبار:

على مضيف Linux: pipenv install grpcio

تم إنتاج الطلبات التالية (التي تم التقاطها باستخدام mitmproxy ):

$ mitmdump -w dump.out
Proxy server listening at http://*:8080
127.0.0.1:62303: clientconnect
127.0.0.1:62303: GET https://pypi.org/simple/setuptools/
              << 200 OK 79.82k
127.0.0.1:62305: clientconnect
127.0.0.1:62305: GET https://files.pythonhosted.org/packages/7f/e1/820d941153923aac1d49d7fc37e17b6e73bfbd2904959fffbad77900cf92/setuptools-39.2.0-py2.py3-none-any.whl
              << 200 OK 554.25k
127.0.0.1:62303: GET https://pypi.org/simple/pip/
              << 200 OK 9.56k
127.0.0.1:62303: GET https://pypi.org/simple/wheel/
              << 200 OK 6.91k
127.0.0.1:62303: clientdisconnect
127.0.0.1:62305: clientdisconnect
127.0.0.1:62307: clientconnect
127.0.0.1:62307: GET https://pypi.org/simple/grpcio/
              << 200 OK 112.03k
127.0.0.1:62309: clientconnect
127.0.0.1:62309: GET https://files.pythonhosted.org/packages/1f/ea/664c589ec41b9e9ac6e20cc1fe9016f3913332d0dc5498a5d7771e2835af/grpcio-1.12.1-cp36-cp36m-manylinux1_x86_64.whl
              << 200 OK 8.57m
127.0.0.1:62307: GET https://pypi.org/simple/six/
              << 200 OK 3.34k
127.0.0.1:62309: GET https://files.pythonhosted.org/packages/67/4b/141a581104b1f6397bfa78ac9d43d8ad29a7ca43ea90a2d863fe3056e86a/six-1.11.0-py2.py3-none-any.whl
              << 200 OK 10.45k
127.0.0.1:62309: clientdisconnect
127.0.0.1:62307: clientdisconnect
127.0.0.1:62311: clientconnect
127.0.0.1:62311: GET https://pypi.org/simple/grpcio/
              << 200 OK 112.03k
127.0.0.1:62313: clientconnect
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/1f/ea/664c589ec41b9e9ac6e20cc1fe9016f3913332d0dc5498a5d7771e2835af/grpcio-1.12.1-cp36-cp36m-manylinux1_x86_64.whl
              << 200 OK 8.57m
127.0.0.1:62311: GET https://pypi.org/simple/six/
              << 200 OK 3.34k
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/67/4b/141a581104b1f6397bfa78ac9d43d8ad29a7ca43ea90a2d863fe3056e86a/six-1.11.0-py2.py3-none-any.whl
              << 200 OK 10.45k
127.0.0.1:62315: clientconnect
127.0.0.1:62315: GET https://pypi.org/pypi/six/json
              << 200 OK 5.94k
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/16/d8/bc6316cf98419719bd59c91742194c111b6f2e85abac88e496adefaf7afe/six-1.11.0.tar.gz
              << 200 OK 29.16k
127.0.0.1:62315: GET https://pypi.org/pypi/grpcio/json
              << 200 OK 164.26k
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/5c/73/5e65b81301956bdd32c5e8da691fde3fbd6e61283b65d2bac590b8f43765/grpcio-1.12.1-cp27-cp27m-win32.whl
              << 200 OK 1.35m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/e1/c3/bcce8247da4e6f95a900489b6f7ff3d14d93df40d69875fe4164c1b9544a/grpcio-1.12.1-cp27-cp27mu-manylinux1_i686.whl
              << 200 OK 8.01m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/ed/89/03924c56e9044b0842a014fcc0a81f55975028d1caa9cdd14234a230bc70/grpcio-1.12.1-cp27-cp27m-win_amd64.whl
              << 200 OK 1.35m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/d7/f6/ddeab13c25b8451f05875587801ad87e4e0fc23c4e3eb328c4bd1a80a415/grpcio-1.12.1-cp36-cp36m-linux_armv7l.whl
              << 200 OK 7.77m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/2d/a4/4d1d73c0339e987ea173f44cf62ec6b40fb91e0336c09c960c4a44137552/grpcio-1.12.1-cp35-cp35m-linux_armv7l.whl
              << 200 OK 7.76m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/76/27/b03ec8fc96745cde68d6ec29115f9a444945a6acc45209c5772378cc4d66/grpcio-1.12.1-cp35-cp35m-macosx_10_7_intel.whl
              << 200 OK 1.83m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/30/24/8e247548321e52c266a639b51a838ec19b41fb6bfd27e3bbef018496752e/grpcio-1.12.1-cp27-cp27m-manylinux1_x86_64.whl
              << 200 OK 8.47m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/80/c9/e582b962a4a3aa2684666ff67fc994a042b1b0e444eb6672eb9740f7b59a/grpcio-1.12.1-cp34-cp34m-macosx_10_7_intel.whl
              << 200 OK 1.84m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/a2/25/6d910070a4a07c32633c2376075d5dc03e90f69f855d700e3f73c1affebb/grpcio-1.12.1-cp27-cp27m-macosx_10_12_x86_64.whl
              << 200 OK 1.57m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/33/38/58f3e8d133de1f2e911206ead03799621205079c303ae5b27e7350051f4a/grpcio-1.12.1.tar.gz
              << 200 OK 13.56m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/68/57/da122cbfc1b7815381480b23044fff06b90f58c1be9310e68c2d6b1d623c/grpcio-1.12.1-cp36-cp36m-macosx_10_7_intel.whl
              << 200 OK 1.82m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/c6/b8/47468178ba19143e89b2da778eed660b84136c0a877224e79cc3c1c3fd32/grpcio-1.12.1-cp35-cp35m-manylinux1_x86_64.whl
              << 200 OK 8.55m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/5d/8b/104918993129d6c919a16826e6adcfa4a106c791da79fb9655c5b22ad9ff/grpcio-1.12.1-cp36-cp36m-win_amd64.whl
              << 200 OK 1.37m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/94/6c/02e9cb803cd7b9608c9c1768d86d31c61b088f5b9513a203c10fa7e905d8/grpcio-1.12.1-cp36-cp36m-win32.whl
              << 200 OK 1.12m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/2a/ed/71169dccb7f9250d17031068579832371a72891d8e64891265370ca6e264/grpcio-1.12.1-cp27-cp27mu-linux_armv7l.whl
              << 200 OK 7.68m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/63/38/d73bf5b1ef950dbab8203122b9681137b35012492ecfec56719be109e343/grpcio-1.12.1-cp27-cp27m-manylinux1_i686.whl
              << 200 OK 8.01m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/13/71/87628a8edec5bffc86c5443d2cb9a569c3b65c7ff0ad05d5e6ee68042297/grpcio-1.12.1-cp36-cp36m-manylinux1_i686.whl
              << 200 OK 8.11m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/1d/0d/146582f71161a0074dda2378617ae5f7e2c3d6cf62d4588eb586c1d6b675/grpcio-1.12.1-cp27-cp27mu-manylinux1_x86_64.whl
              << 200 OK 8.47m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/9e/3a/6aceb4fccacf6d2d7d087190c221a90f14b2bdcb56cbee5af24b7050278b/grpcio-1.12.1-cp34-cp34m-win_amd64.whl
              << 200 OK 1.35m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/f9/fa/a0187d220544b744dd3bb0d8b8ec716d130159160bf627415b2880ae599a/grpcio-1.12.1-cp34-cp34m-win32.whl
              << 200 OK 1.35m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/dd/aa/ac8e3c6badf1744f04be7d35fa95dae56df12b956f861285c8cced2a22cb/grpcio-1.12.1-cp34-cp34m-linux_armv7l.whl
              << 200 OK 7.76m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/38/2a/94665daafbcf0214adcf77ad8f5aed8b9dfcbfa871115c7890d88b1b8f3c/grpcio-1.12.1-cp34-cp34m-manylinux1_x86_64.whl
              << 200 OK 8.58m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/0d/33/22ad4a9dcefe330180cdb2d24fdd980af2a7a2dc03af208a408fd48195e0/grpcio-1.12.1-cp35-cp35m-win_amd64.whl
              << 200 OK 1.36m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/b5/13/9e8e5d68a15c51b251e512955a971214fd8425b237e6d6a04f0257c5d090/grpcio-1.12.1-cp34-cp34m-manylinux1_i686.whl
              << 200 OK 8.11m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/21/41/66ab386c65be68b4e907f2cd35223965aea2a086bcd0bd6825999e0bda7c/grpcio-1.12.1-cp35-cp35m-win32.whl
              << 200 OK 1.12m
127.0.0.1:62313: GET https://files.pythonhosted.org/packages/f7/db/fc084f59804a32a8d6efb467896a505f4dc93ea89ec44da856b91f05a5cb/grpcio-1.12.1-cp35-cp35m-manylinux1_i686.whl
              << 200 OK 8.09m
127.0.0.1:62313: clientdisconnect
127.0.0.1:62311: clientdisconnect
127.0.0.1:62315: clientdisconnect

تعداد بعض الطلبات غير الضرورية:

• 4 × win32
• 4 × ذراع
• 4 × ماكوس

إلخ. يبدو أنه فوز سريع للقيام ببعض التصفية البسيطة بناءً على نظام التشغيل المضيف والقوس؟

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

فيما يتعلق بـ JSON api ، لم يتم تمكينه فعليًا للوصول مباشرة في الإصدار الحالي ، وأنا أخطط لتعطيله في قاعدة التعليمات البرمجية مرة أخرى قبل إصداره. لقد قمت بعمل تنميط مكثف وأنا أعلم أن المكالمات الفاشلة لحساب packaging.version.parse() لشيء مثل 20-50٪ من وقت تشغيل pipenv.

تستخدم Pip 10 واجهة برمجة تطبيقات JSON افتراضيًا كمحلل رئيسي لها ، ومع ذلك ، ما لم ترغب في التوقف عن استخدام النقطة ، فليس هناك الكثير لتفعله على هذا الصعيد.

أشعر أنه يجب علينا تنزيل نفس الأشياء عدة مرات ، أليس كذلك؟

ربما ينبغي علينا نقل المناقشة إلى # 2284. إنه في الواقع جزء القفل البطيء ( install هو في الأساس معالجة TOML + lock + sync ) ، غير مثبت.

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

techalchemy شكرا لاستجابتك. يبدو العثور على packaging.version.parse() بمثابة مقدمة جيدة. هل يمكنك إضافة المزيد من الألوان على هذا البيان:

فيما يتعلق بـ JSON api ، لم يتم تمكينه فعليًا للوصول مباشرة في الإصدار الحالي ، وأنا أخطط لتعطيله في قاعدة التعليمات البرمجية مرة أخرى قبل إصداره.

لم أفهم لماذا تخطط لتعطيله؟

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

يستغرق تثبيت Pyspark وقتًا طويلاً.
ملفي -

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

[dev-packages]
pylint = "*"
pyspark = "*"

[requires]
python_version = "3.5"

إخراج قذيفة -

Pipfile.lock not found, creating...
Locking [dev-packages] dependencies...

العملية عالقة في السطر الأخير أعلاه.
ينتهي بعد 15-20 دقيقة

pipenv ، الإصدار 2018.7.1

keshavkaul PySpark كبير جدًا ويمكن أن يستغرق بعض الوقت لتنزيله. امنحها بعض الوقت ، سيكون أفضل بكثير بعد ذلك (لأن Pipenv يخزن النتيجة مؤقتًا).

(أو يمكنك حث المطورين على إصدار توزيع للعجلات. سيساعد ذلك قليلاً).

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

هل من الممكن الحصول على بعض المعلومات أو شريط التقدم مثل apt-get أو wget (سرعة التنزيل ، الحجم الذي تم تنزيله ، الحجم الإجمالي) أثناء تنزيلات المكتبات؟
أعتقد أن هذه هي المشكلة هنا ، يبدو أن pipenv كان بطيئًا بالنسبة لي ولكنه كان مجرد تنزيل للمكتبة ، واضطررت إلى فتح شاشة نظام لفهم أن pipenv كان يقوم بتنزيل الملفات وكم تم تنزيله بالفعل ، وما السرعة وما إلى ذلك

هافا نفس المشكلة: Locking [packages] dependencies... توقف إلى الأبد
بيئتي:

• macOS High Sierra 10.13.6
• بايثون: Python 3.6.4
• pipenv: الإصدار 2018.7.1

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

كذلك هنا. Pipenv بطيئة جدا.
يستغرق القفل والتثبيت ساعة.

أعتقد أنه تم الرد على هذه المشكلة بشكل جيد هنا: https://github.com/pypa/pipenv/issues/1914#issuecomment -378846926

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

• بقلم techalchemy

هل سيكون من الممكن الحصول على قائمة التجزئات من PyPI API ، بدلاً من حسابها بأنفسنا؟

pipenv رائع ، ولكن يبدو أن هذه المشكلة لا تزال قائمة. سيكون سعيدا لرؤية أي تقدم. - لم يعمل قفل القفل.

pipenv رائع ، ولكن يبدو أن هذه المشكلة لا تزال قائمة. سيكون سعيدا لرؤية أي تقدم. - لم يعمل قفل القفل.

عملت من أجلي

لقد وجدت أن استخدام Git Bash على Windows كان بطيئًا جدًا مقارنة بـ Powershell. ليس لدي أي إحصائيات أو بيانات حول هذا ، لكن PS بدا أسرع. لذلك إذا كنت تستخدم Git Bash ، فقد ترغب في تجربة PS الأصلي مقابل pipenv 'ing.

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

pipenv install pandas --verbose
Installing pandas…
⠋ Installing...Installing 'pandas'
$ ['/Users/sinscary/.local/share/virtualenvs/signzy-MSzur11z/bin/pip', 'install', '--verbose', '--upgrade', 'pandas', '-i', 'https://pypi.org/simple']
Adding pandas to Pipfile's [packages]…
✔ Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
⠦ Locking...

عالق في القفل لأكثر من 30 دقيقة. أنا أستخدم python 3.7.0 و macos mojave. أي مساعدة في ذلك.

لماذا تم إغلاق كل القضايا الخاصة بهذا الموضوع؟ لا يمكنني تثبيت شيء واحد باستخدام pipenv بسبب تعليق خطوة القفل.

يستغرق إنشاء صورة عامل الإرساء التالية أكثر من 30 دقيقة على الكمبيوتر المحمول الخاص بي (i7 / 16Gb) ، ويعمل الأمر pipenv install ... للأعمار ...

Dockerfile

FROM python:3.7-alpine

# Update package list.
RUN set -ex && apk update

# Install apk dependencies.
RUN set -ex && apk add --no-cache musl-dev gcc libffi-dev openssl-dev make

# Install Pipenv.
RUN set -ex && pip install pipenv --upgrade

# Copy Pipfiles.
RUN mkdir /website
COPY Pipfile /website

# Install Pipenv dependencies.
WORKDIR /website
RUN set -ex && pipenv install --system --skip-lock --verbose

Pipfile

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


[requires]
python_version = "3.7"

[packages]
sanic = "*"
jinja2 = "*"
asyncpg = "*"
uvloop = "*"
munch = "*"

[dev-packages]

[pipenv]
allow_prereleases = true

هل هذا طبيعي؟ هل يمكن لشخص أن يتكاثر؟

التحديث: كن حذرًا مع Alpine Linux

أدركت أن المشكلة ليست من جانب pipenv ...

لقد استبدلت صورة عامل إرساء قاعدة Alpine بأخرى مبنية على Debian-Slim والآن تنتهي pipenv install في غضون ثوانٍ.

المشكلة في المثال الذي قدمته هي أن Alpine Linux سيحاول دائمًا إنشاء حزم تحتوي على cython-extension أو c-extensions من المصدر ، والتي يمكن أن تستغرق وقتًا طويلاً في حاوية Docker ، بينما يقوم Debian Linux بتثبيتها باستخدام wheel تنسيق

المزيد عن هذا: https://stackoverflow.com/questions/49037742/why-does-it-take-ages-to-install-pandas-on-alpine-linux

لقد تركت pipenv منذ فترة طويلة وكلما احتجت إلى إنشاء بيئة افتراضية قيد الاستخدام "venv" أو خيارات أخرى.

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

click

استغرق التثبيت 15/20 دقيقة ، واختبارات الإنترنت بسرعة تزيد عن 60 ميجابت في الثانية وتعمل على جهاز MacBook Pro 2019 محدث (ليس خياري للأجهزة).

الرجاء استخدام virtualenv في الوقت الحاضر. حتى يتوفر حل أفضل

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

في حالة عدم وجود حزم أولية جديدة منذ التشغيل الأخير ، فمن المؤكد أنه يمكن تخطي العملية؟