Pipenv: تحديث تبعية واحدة مقفلة فقط

قد يكون ذلك مفيدًا أيضًا لـ pipenv install ، لأنني أحيانًا أرغب في تثبيت تبعية جديدة دون تحديث الآخرين.

هناك شيء بسيط يجب أخذه في الاعتبار هنا: تغيير تبعية واحدة يمكن أن يغير مجموعة المتطلبات الإجمالية.
على سبيل المثال: قد يتطلب تحديث foo من 1.0 إلى 2.0 تحديث bar إلى> = 2.0 (بينما كان <2.0 من قبل) ، وهكذا.

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

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

آمل أن يساعد هذا!

في الواقع ، كان هذا ما قصدته:

سيؤدي ذلك إلى إنشاء Pipfile.lock مع تحديثات فقط لـ my-awesome-dep وتبعياته.

موافق بنسبة 100٪ - وسأذهب إلى أبعد من ذلك: يجب أن يكون هذا هو الوضع الافتراضي.

أي أن pipenv install foo يجب ألا يلمس أي شيء بخلاف foo وتبعياته. ومن المؤكد أن pipenv lock يجب ألا يقوم بترقية أي شيء مطلقًا - يجب فقط قفل ما تم تثبيته بالفعل.

AFAICT ، هذه هي طريقة عمل npm ، yarn ، gem ، إلخ ؛ ليس من المنطقي أن يكون لديك ملف قفل لا يقفل الحزم فعليًا ، لكنه يثق في مؤلفي الحزم لعدم كسر الأشياء في إصدارات التصحيح ، وبالتالي يقوم بترقيتها دون أن يُطلب منهم ذلك. يمكنني رؤية استخدام السماح بالترقيات ، ولكن يجب أن يكون ذلك ممكنًا ، لأنه أكثر إثارة للدهشة من عدم ترقيتها.

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

وجدت للتو هذه المشكلة ذات الصلة أيضًا: https://github.com/kennethreitz/pipenv/issues/418

أن تكون قادرًا على تحديد pipenv install --upgrade-strategy=only-if-needed يبدو وكأنه ما أبحث عنه ، على الرغم من أنه بالطبع كما ذكرت ، أعتقد أن هذا يجب أن يكون الافتراضي ، لأنه أصبح في نقطة 10. لكن القدرة على تحديده بشكل شبه دائم عبر سيكون env var شيء ، على أي حال.

سأندهش إذا كان هذا التغيير يكسر سير عمل أي شخص ( الكلمات الأخيرة الشهيرة ) ، لأنه أكثر تحفظًا من --upgrade-strategy=eager .

حاولت التغلب على هذا عن طريق تعيين export PIP_UPGRADE_STRATEGY=only-if-needed في تكوين shell الخاص بي. هذا لا يعمل ، ويظهر pipenv lock هذه السلوكيات المدهشة:

1. تقوم "بترقية" الحزم التي لا تحتاج إلى ترقية (لكن ...)
2. إنه في الواقع لا يقوم بترقية الإصدارات المثبتة! أي pip freeze و Pipfile.lock تظهر إصدارات مختلفة!

تخمين pipenv هو تفويض للنقطة للتثبيت ، وتحترم النقطة إعدادات متغير البيئة الخاصة بها ، لكن pipenv lock لا تفعل ذلك.

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

brettdh أعتقد أنه يمكنني إلقاء بعض الضوء لأن لديك معظم القطع. pipenv lock بتثبيت أي شيء ، ولا يدعي وجوده. يقوم فقط بإنشاء ملف القفل بالنظر إلى البيئة المضيفة ، وإصدار Python ، و Pipfile المقدم. إذا كنت تتلاعب ببيئتك بطريقة أخرى أو إذا كنت تستخدم النقطة بشكل مباشر / تتلاعب بإعدادات النقطة خارج pipenv / لا تستخدم pipenv run أو تستخدم pip freeze داخل مجموعة فرعية من pipenv ، فمن السهل جدًا ملف قفل غير متزامن من pip freeze . الاثنان ليسا مرتبطين حقًا.

للتوضيح:

1. Pipfile.lock هو حل تبعية مثبت بدقة باستخدام محلل أدوات النقطة استنادًا إلى المستخدم Pipfile
2. إذا كنت ترغب في الحفاظ على دبابيس صارمة لكل شيء أثناء ترقية حزمة واحدة فقط ، أعتقد أنه يمكنك القيام بذلك عن طريق التثبيت الصارم لكل شيء في Pipfile باستثناء الشيء الوحيد الذي تريد ترقيته (صححني إذا كنت مخطئًا vphilippon)

بالنسبة لملف lockfile و pip freeze مع بعضهما البعض ، يجب أن أعرف المزيد من المعلومات ، لكنني أعتقد أن لدينا مشكلة مفتوحة تتعلق بمحلل ملفات القفل عند استخدام إصدارات غير نظامية من Python لحلها.

techalchemy : إذا كان لدي Pipfile.lock مع A و B و C حيث يكون B تابعًا لـ A ، أود أن أكون قادرًا على تحديث A و B بدون تحديث C أو C بدون تحديث A و B.
مرة أخرى بالطبع يمكنني تثبيت جميع تبعياتي وتبعياتها في ملف Pipfile الخاص بي من أجل القيام بذلك ، ولكن هذا سيكون عبئًا على الحفاظ عليه (مثل معظم requirements.txt هي).

أنا أتفق مع كل ما كتبه @ k4nar . بالتأكيد ، يمكنني حتى تثبيت
كل شيء في requirements.txt وعدم استخدام pipenv. نقطة بيبينف هي
للحصول على أداة واحدة تجعل ذلك (والأشياء الافتراضية بالطبع)
أبسط في الإدارة على سبيل المثال ، يتم تأمين جميع الحزم افتراضيًا في الإصدار
من المعروف أنه يعمل ، ولكن يجب أن يكون من السهل ترقية ملف
قليل (دون ترقية الآخرين بشكل غير متوقع).
يوم الخميس ، 26 تشرين الأول (أكتوبر) 2017 ، الساعة 4:28 صباحًا من Yannick PÉROUX [email protected]
كتب:

techalchemy https://github.com/techalchemy : إذا كان لدي ملف Pipfile.lock
مع A و B و C حيث B هي تبعية لـ A ، أود أن أكون قادرًا على ذلك
تحديث A و B بدون تحديث C أو C بدون تحديث A و B.
مرة أخرى بالطبع يمكنني تثبيت كل تبعياتي وتبعياتها في ملف
Pipfile من أجل القيام بذلك ، ولكن سيكون ذلك عبئًا للحفاظ عليه (مثل
معظم المتطلبات. txt).

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kennethreitz/pipenv/issues/966#issuecomment-339591307 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAFlnqUOEKARiFD8kEk3GVczF3NXBdVOks5swEKcgaJpZM4QEf--
.

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

techalchemy لقد أشرت إلى pip freeze كاختصار لـ "إصدارات الحزم التي تختلف تثبيتها pipenv install عن إصدارات الحزم التي يحفظها pipenv lock إلى Pipfile.lock ."

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

هل يمكنك توضيح سؤالك قليلاً؟ أعتقد أن "الحل باستخدام أدوات النقطة" يشير إلى ما يفعله pipenv lock ، والسبب في عدم تأثره عند تعيين الإعدادات الافتراضية للنقطة؟ وهل يمكنك أن تكون أكثر تحديدًا بشأن ما تعنيه بـ "هذا السلوك"؟

brettdh تتضمن آلية القفل فكرة "دقة التبعية" التي لا توجد في pip . تمت معالجته بواسطة pip-tools (أو بالأحرى ، نسخة مصححة منه ، مدمجة بطريقة خاصة بواسطة pipenv والتي تجلب بعض الاختلافات مع الأداة الأصلية). باختصار ، تقرأ آلية القفل Pipfile وتنفذ دقة تبعية كاملة لتحديد مجموعة كاملة من الحزمة التي ستفي بكل القيود المحددة بواسطة الحزم المطلوبة وتبعياتها .

تضمين التغريدة

[...] إنه حل باستخدام أدوات الأنابيب التي تهمني.

لست متأكدًا من كيفية تأثير هذه --upgrade-strategy pip-tools ، لأنها تعمل على بعض العناصر الداخلية منخفضة المستوى pip . لدي شعور بأن هذا لن يعطي النتيجة المتوقعة ، لأن هذا الخيار يأخذ في الاعتبار ما تم تثبيته ، وهذا ليس ما يتم التعامل معه في تلك الآلية. ولكن لدينا طريقة أخرى لهذا في pip-tools يمكن القيام بها هنا.

السلوك "الأصلي" pip-tools هو أنه يقوم فقط بتحديث ما هو مطلوب في ملف القفل (في سياقه ، متطلباته. txt) ، ولكن هذا "فقد" بالطريقة التي تم بها دمج المحلل في pipenv . اسمحوا لي أن أشرح لماذا.

بالإشارة إلى سيرتي الذاتية حول كيفية عمل pip-tools : https://github.com/kennethreitz/pipenv/issues/875#issuecomment -337717817
تذكر جزء "تحديد مرشح"؟ يتم ذلك عن طريق الاستعلام عن الكائن Repository .
في pipenv ، نقوم مباشرة بتكوين PyPIRepository لـ Resolver ، لكن pip-tools يفعل شيئًا آخر ، فهو يستخدم عنصر LocalRequirementsRepository ، والذي يحتفظ بالدبابيس الموجودة من requirements.txt الموجودة سابقًا (إذا وجدت) ، و "الاحتياطيات" على PyPIRepository .

لذلك في pip-tools ، يحدث ما يلي عند اختيار مرشح:

1. الاستعلام عن LocalRequirementsRepository لمرشح يطابق foobar>=1.0,<2.0 .
2. تحقق مما إذا كان دبوس موجود يفي بهذه المتطلبات:
   
   
   
   • إذا كانت الإجابة بنعم ، أعد هذا الدبوس كمرشح.
   
   
   • إذا لم يكن الأمر كذلك ، فاستعلم عن proxied_repository ( PyPIRepository ) للمرشح.
   
   
3. عاد استخدام المرشح

بشكل فعال ، هذا يعني أن المسامير الموجودة يتم منحها "أولوية" كمرشح للمحاولة أولاً.

لكن في pipenv ، حاليًا ، ببساطة:

1. الاستعلام عن PyPIRepository (مباشرة) لمرشح يطابق foobar>=1.0,<2.0 .
2. عاد استخدام المرشح.

لذلك ، أعتقد أن نفس السلوك لإغلاق pipenv يمكن أن يتم عن طريق تحليل Pipfile.lock للحصول على الدبابيس الحالية واستخدام LocalRequirementsRepository ، مثل pip-tools يفعل pip-compile .

vphilippon هل لديك فكرة عن مدى صعوبة تنفيذ ذلك؟

تضمين التغريدة

• تحليل Pipfile.lock لاستخراج المسامير الحالية: لم تنظر إلى ذلك. يعتمد على كيفية تنظيم الأشياء في pipenv . نحتاج إلى مجموعة من InstallRequirements تمثل الدبابيس في Pipfile.lock .
• استخدام LocalRequirementsRepository : سهل إلى حد ما: قم بتغيير PyPIRepository لـ LocalRequirementsRepository .

لكن ، أثناء بحثي في هذا الأمر ، brettdh ، أدركت بعض الأشياء:

1. السلوك الافتراضي الحالي pipenv install لا يتطابق مع السلوك pipenv lock . لن يؤدي القيام بـ pipenv install requests بمفرده إلى تحديث requests إذا ظهر إصدار جديد (يشبه إلى حد كبير pip install ). ومع ذلك ، يؤدي تنفيذ pipenv lock إلى تحديث Pipfile.lock بأحدث إصدار من requests يطابق محدد Pipfile ، وقيود التبعية.
   هناك طريقتان رئيسيتان لرؤية هذا:
   
   
   
   • أ) يجب أن يظل Pipfile.lock مستقرًا قدر الإمكان بشكل افتراضي ، وليس تغيير المسامير إلا إذا لزم الأمر ، من أجل البقاء مثل البيئة الحالية ، والتغيير فقط في حالة تغيير البيئة.
   
   
   • ب) Pipfile.lock يجب أن تحصل على أحدث الإصدارات التي تحترم القيود البيئة / تبعيات من أجل حرية الاستفادة من نطاقات مفتوحة في Pipfile وليب التبعيات، والسماح لاكتساب باستمرار الإصدارات المتوافقة جديدة في بيئتك. يمكنك بعد ذلك تشغيل pipenv update للاستفادة من القفل الجديد.
   
   

IMHO, I would align the default behavior, which would be to go with A) by default. Because right now, everytime a lock is performed (i.e. after each installation), new versions can come in, which make the lockfile *drive the update of the environment*, which seems weird. But, this is arguable of course. While in development, I might want to continuously update my requirements to no get stale, like with B), so that should also be easily doable.

1. حتى إذا استخدمنا LocalRequirementsRepository لتجنب تحديث المسامير الحالية الصحيحة ، وانتهى الأمر بمحاذاة السلوكيات الافتراضية ، فإننا نحتاج بعد ذلك إلى معالجة ما يعادل --upgrade و --upgrade-strategy لجزء القفل . حاليًا ، سيؤثر تحديد بعض متغيرات البيئة (مثل PIP_UPGRADE و PIP_UPGRADE_STRATEGY ) على سلوك pipenv install ، لكن لن يؤثر على pipenv lock ، لأنه لا يؤثر سلوك pip-tools (لقد أكدت ذلك ، لأنني لم أكن متأكدًا في البداية).
   بخلاف ذلك ، لن تكون هناك طريقة لتحديث البيئة دون حذف Pipfile.lock (يشعر بالضيق ، و "كل شيء أو لا شيء") أو طلب إصدار أحدث (أعني إجراء pipenv install requests>2.18.4 صريحًا ، الأمر الذي يتطلب منك معرفة أن إصدارًا جديدًا قد خرج ، وتغيير المحدد في Pipfile نفسه ، مما يؤدي إلى زيادة الحد الأدنى) ، وهذا خطأ. نظرًا لأن "الأصل pip-tools " لا يتحول إلى pip للتعامل مع هذا (لأنه لا يرتبط بما هو مثبت حاليًا) ، فإنه يوفر خيارًا لتحديد التبعيات التي يجب تحديثها في lockfile ، وقم ببساطة بإزالة المسامير لهذه الحزم (أو جميعها) من قائمة الدبابيس الموجودة ، مما يؤدي بشكل فعال إلى استعلام PyPI. لست متأكدًا من كيفية مطابقة فكرة "- إستراتيجية الترقية" مع هذا.

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

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

(حل التبعية ليس بالأمر السهل. حل التبعية الجيد والعملي أسوأ حتى 😄)

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

ب) يجب أن يحصل Pipfile.lock على أحدث الإصدارات التي تحترم قيود / تبعيات البيئة من أجل الاستفادة بحرية من النطاقات المفتوحة في تبعيات Pipfile و lib ، مما يسمح بالحصول باستمرار على إصدارات متوافقة جديدة في بيئتك. يمكنك بعد ذلك تشغيل تحديث pipenv للاستفادة من القفل الجديد.

يمكن أن يعمل سير العمل هذا مع التكوين الحالي. يمكنك استخدام pipenv lock لإنشاء ملف قفل ، ولكن pipenv update سيعيد تثبيت البيئة بأكملها. أنا متأكد تمامًا من أنه يمكننا استخدام أحد تنسيقات الإخراج المختلفة الخاصة بنا لحل مخطط التبعية (لدينا بالفعل تنسيق json كما تعلم) وإعادة تثبيت الأشياء التي لا تتوافق مع ملف القفل فقط. قد يكون هذا أكثر منطقية ، لكن سأكون فضوليًا بشأن إدخال nateprewitt أو erinxocon قبل اتخاذ قرار

vphilippon أتفق تمامًا على أن A و B هما تدفقات عمل مرغوبة في مواقف مختلفة. لقد أربكتني بعض عباراتك حول B قليلاً ، على الرغم من ذلك ، يبدو أنها تقول إن pipenv lock قد ينتج عنه ملف قفل لا يتطابق في الواقع مع البيئة - لقد سمعت هذا بشكل خاص في أنه سيحتاج إلى "تشغيل pipenv update للاستفادة من القفل الجديد "- وكأن القفل" متقدم "على البيئة بدلاً من مطابقتها.

بغض النظر عما إذا كنت في سير عمل A أو B ، فإن بعض الأشياء تبدو ثابتة بالنسبة لي ، وأعتقد أن هذا مربعات مع ما يقوله techalchemy أيضًا:

• يجب أن تكون نتيجة pipenv lock دائمًا ملف قفل يطابق البيئة.
• يجب أن تكون نتيجة pipenv install دائمًا بيئة تطابق ملف القفل.

أنا أتجاهل تفاصيل التنفيذ ، ولكن هذا نوع من السلوك الأساسي الذي أتوقعه من مدير الحزم بميزة lockfile.

يسمح لك تشغيل pipenv update بشكل دوري بالبقاء في الوضع B طالما أنك تريد أن يكون كل شيء جديدًا ، كما أن القدرة على pipenv install --upgrade requests ستسمح بتحديثات محددة لحزمة واحدة وتبعياتها ، دون التأثير على الحزم التي لا تحتاج إلى ترقية دون داع.

هل فاتني أي حالات استخدام؟ يمكنني التفكير في تحسينات لـ B - على سبيل المثال علامة أو env var تخبرها أن يتم تحديثها دائمًا بشغف - لكنني أعتقد أن هذا يغطي الأساسيات. أعلم أيضًا أنني أقوم بتجديد الأرضية التي قمت بتغطيتها بالفعل ؛ من المفيد أن أتأكد من فهمي لما تتحدث عنه. :)

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

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

كحل محتمل لهذا: الشيء الذي تدعمه النقطة نفسها حاليًا ، لكن pip-compile لا ، هو فكرة ملف القيود.

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

هذه هي الميزة المفقودة حاليًا من pipenv ، حيث أن المدخلات المطلوبة لجيل Pipfile.lock هي:

1. محتويات Pipfile المحدثة كملف إدخال متطلبات جديد
2. المجموعة الكاملة من التبعيات الموجودة من Pipfile.lock كملف قيود ، باستثناء الحزم المسماة تحديدًا في الأمر الحالي

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

غير مدعوم حاليًا ، شكرًا على التعليقات

تضمين التغريدة

هل تعني:

1. يجب تغيير هذا السلوك ، لكنه ليس أولوية حاليًا ،
2. يجب إضافة هذا السلوك كشيء اختياري ، لكنه ليس أولوية حاليًا ، أو
3. لا ينبغي أن يضاف هذا السلوك؟

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

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

أعني أن هذا غير مدعوم حاليًا ، وأنا أقدر التعليقات.

أتفهم أنه غير مدعوم. هل تقول أيضًا أنك لن تقبل العلاقات العامة سواء بتغيير هذا السلوك أو إضافة هذا كخيار؟

ليس لدي أي فكرة.

@ k4nar ما زلت مهتمًا بعمل pipenv install --only <dep-to-update يمنع تحديث الأقسام غير ذات الصلة. نظرًا لأن @ kennethreitz يبدو غير مهتم بالمزيد من المناقشة ، يبدو لي أن هذه هي الطريقة الوحيدة لمعرفة ما إذا كان من الممكن قبول إضافة / تغيير السلوك هذا ( وبالتبعية ، ما إذا كان الأشخاص مثل

أنا مهتم ولكني لست متأكدًا من معرفة كيف ستكون أفضل طريقة لتنفيذ ذلك. هناك الكثير من المكونات قيد العمل (الأنابيب ، أدوات الأنابيب ، ملف الأنابيب ، الأنابيب ...) وربما الكثير من الحلول الممكنة.

حسب https://github.com/kennethreitz/pipenv/issues/966#issuecomment -339707418 ، يجب أن يكون واضحًا نسبيًا. منطق القرار هذا هو إلى حد كبير فقط من أدوات النقطة. كنت أخطط لتقديم وثيقة العلاقات العامة ، لكن لا يمكنني تبرير إنفاق العمل إذا لم نكن مستعدين للتحدث عن الكيفية التي نريد أن تبدو بها واجهة برمجة التطبيقات قبل قضاء الوقت في كتابة الكود.

أنا أبحث حاليًا في اتباع نهج بديل - نظرًا لأن Pipfile هو معيار ، لا تحتاج التفاعلات معه إلى المرور عبر pipenv ، وأود أن أتغلب على بعض الدلالات الغريبة الأخرى هنا مثل مسح Virtualenvs الموجودة لكل https : //github.com/kennethreitz/pipenv/issues/997.

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

pipenv install foo
vim Pipfile.lock  # Manually remove all the unwanted updates
git add && git commit && git push

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

IIUC ، هذا السلوك يعادل apt أداء apt dist-upgrade ضمنيًا كلما قمت بتشغيل apt install foo .

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

أنا مقتنع تمامًا بأن "تحديث كل شيء إلى أحدث إصدار مسموح به من قِبل Pipfile " يجب أن يكون عملية مطلوبة صراحةً ومنفصلة عن "install foo".

يجب أن تكون ثابتة في الماجستير

لا يزال السلوك موجودًا ، لقد اختبرته في pipenv 11.8.3 @ kennethreitz.

@ marius92mc يشير تعليق " --selective-upgrade و --keep-outdated المضافة في الإصدارات الأخيرة: https://docs.pipenv.org/#cmdoption -pipenv-install-keep قديمة

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

ncoghlan أعتقد أن هناك شيئًا واحدًا مطلوبًا (من السهل السؤال عنه ، وليس من السهل القيام به) هو الأسئلة الشائعة حول _كيف تتصرف هذه الخيارات (على الأقل لا يزال الأمر محيرًا بالنسبة لي).

على سبيل المثال: استخدام --selective-upgrade و --keep-outdated سيستمر في تحديث المكتبات القديمة في Pipfile.lock ، إذا لم تكن مرتبطة بشكل مباشر بالحزمة "المحددة" ليتم تحديثها .

يبدو أنه قد يكون هناك أخطاء في التنفيذ ، إذن.

الغرض منها هو ترك ملف pipfile.lock كما هو ، باستثناء التغيير الجديد.

اسمحوا لي أن أعرف ما إذا كان من المفيد تقديم اختبار Pipfile + .lock.

أعتقد أنك قدمت معلومات كافية لنا للتحقيق فيها. سأحاول القيام بذلك الآن.

في الواقع ، سيكون ملف الأنابيب / القفل رائعًا ، إذا كان يحتوي على نتائج قديمة.

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

@ kennethreitz https://github.com/simonpercivall/pipenv-selective-upgrade-test

هناك أي تحديثات بخصوص هذه المسألة ، @ kennethreitz؟

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

نرحب بالمساهمات كالعادة!

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

1. قم بتحديث قيود الإصدار الخاصة بالتبعية في setup.py
2. قم بتشغيل إما pipenv lock --selective-upgrade ; pipenv sync أو pipenv install --selective-upgrade "-e ."

wichert إذا تم Pipfile بطريقة تزيد من الحد الأدنى للإصدار المطلوب بما يتجاوز ما هو موجود في ملف القفل الحالي ، فيجب أن يغطي --keep-outdated ما تحتاجه بالفعل. --selective-upgrade للحالة التي لم يتغير فيها Pipfile ، لكنك تريد التحديث إلى إصدار مثبت جديد على أي حال.

ncoghlan Pipfile لم يتغير في هذا السيناريو ، فقط setup.py خلال تغيير الحد الأدنى لمتطلبات الإصدار لإحدى التبعيات ، عادةً إلى شيء أحدث وحاليًا في Pipfile.lock .

wichert pipenv لا يلتقط التغييرات التي تم إجراؤها على setup.py تلقائيًا لأنه ليس من أدوات الإعداد. يجب عليك تشغيل pipenv lock إذا كنت تريد أن يحدث ذلك.

ما هو الوضع الحالي لهذا؟ في 25 آذار (مارس) ، قال أحدهم إنه يعتقد أنه سيتم حل مشكلات التنفيذ "في اليومين المقبلين" ، وتم إغلاق تقارير الأخطاء الأخرى نظرًا لتعقبها هنا ؛ ولكن اعتبارًا من 2018.7.1 ما زلت أرى الخطأ الذي أبلغ عنه Simon Percivall (يتم تحديث التبعيات غير المباشرة دائمًا) ولم تتم مناقشة هذا الخطأ منذ التقرير الأصلي. هل ما زالت المشكلة قيد التتبع؟

(أنا أعيش حاليًا في مدينة من الدرجة الثانية في السنغال ، لذا فإن الإنترنت الخاص بي سيئ للغاية وسيكون من المغير لقواعد اللعبة عدم تفجير سقف بياناتي عند تحديث التبعيات غير المباشرة إن أمكن: P)

ملاحظة: شكرًا على صنع Pipenv ، إنه رائع <3

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

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

uranusjr FWIW ، لم أر أي مطالب بالنفعية في تعليق

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

كما هو الحال دائمًا ، شكرًا جزيلاً لك ولكل من يبذل وقته الثمين لتحسين pipenv. 👏

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

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

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

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

أعتقد أنه من المفاجئ بعض الشيء ولكن ليس من غير المعقول تمامًا أن يفسر pipenv foo = "*" ليعني "أنا فقط بحاجة للتأكد من _ بعض_ إصدار foo مثبت ، المستخدم لا يهتم بأي شيء". تحقيقًا لهذه الغاية ، يبدو أن وجود شيء مثل pipenv install --pin foo والذي ينتج عنه foo = "==1.2.3" بدلاً من foo = "*" في ملف Pipfile (حيث 1.2.3 هو أحدث إصدار حالي من foo) مساعدة.

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

(أدركت للتو أنني كنت أعلق على المشكلة الخاطئة. آسف على الفوضى ، من فضلك تجاهلي) 😞

حالة استخدام فعلية عانيت معها لعدة ساعات الآن: أريد قياس تغطية الاختبار في مشروع Django 2.0. حتى pipenv install --keep-outdated --selective-upgrade --dev coverage يصر على تحديث حزمة Django غير المطورة إلى الإصدار 2.1 ، والذي بسبب الكسر في مكان آخر لا يمكنني استخدامه بعد. يجب أن تكون هناك طريقة لتغيير مجموعة الحزم المثبتة دون ترقية الحزم غير ذات الصلة تمامًا إلى الإصدارات المعطلة. ستظل إمكانية الكسر في أحدث إصدار موجودة دائمًا.

سأحاول حلrfleschenberg ، لكنني لا أعرف ما إذا كان وجود خاصية _meta hash غير صحيحة على الأرجح سيؤدي إلى كسر أي شيء.

@ l0b0 إذا كان التطبيق الخاص بك لا يمكنه التعامل مع إصدار معين من Django ، أعتقد أنه من المنطقي ذكر هذا التقييد في ملف Pipfile الخاص بك؟

AlecBenzer هذا يبدو وكأنه شيء من أجل الإعداد.

wichert قد يكون هذا منطقيًا أيضًا (أنا في الواقع لست واضحًا تمامًا بشأن الظروف التي تريد أن يكون لديك كل من setup.py و Pipfile) ، ولكن إذا كان لديك سطر في ملف Pipfile الخاص بك يقول:

Django = "*"

أنت تخبر pipenv أنك تريد تثبيت أي إصدار من Django. إذا كان ما تريده حقًا هو تثبيت 2.0 أو أقل ، فأخبره أنه بدلاً من ذلك:

Django = "<=2.0.0"

بينما يقوم pipenv في هذه الحالة بالذات بترقية Django دون سبب حقيقي ، فقد يكون ذلك في مكان ما أسفل الخط الذي تحاول فيه تثبيت حزمة تتطلب Django> 2.0.0 ، وعند هذه النقطة سوف يثبتها pipenv بسعادة إذا لم تخبر بذلك ما تحتاجه <= 2.0.0.

إذا كان ما تريده حقًا هو تثبيت 2.0 أو أقل ، فأخبره بذلك بدلاً من ذلك

AlecBenzer عند الانعكاس ، ^major.minor.0 في package.json ، مما يمنع ترقيات الإصدارات الرئيسية غير المتوقعة ، حتى عندما يُطلب صراحةً الترقية إلى الأحدث. أتساءل عما إذا كان ينبغي على Pipenv أن يفعل الشيء نفسه - لكن هذه ستكون قضية منفصلة.

بالطبع ، يمنع ملف القفل الخاص بهم أيضًا الترقيات العرضية حتى للإصدارات الثانوية والإصدارات التصحيح ، وهو ما يتم طلبه هنا.

أعتقد أنه تمت مناقشته أعلاه وفي أي مكان آخر ، ولكن هناك توتر / مقايضة في مساحة التصميم بين npm / yarn و pipenv. أي مدير حزم لديه هذه الأهداف ظاهريًا ، مع بعض الأولوية النسبية:

• اجعل من السهل تثبيت الحزم وترقيتها
• اجعل من الصعب كسر تطبيقك عن طريق الخطأ من خلال ترقية التبعية الخاطئة

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

لا يبدو أن العلامة --keep-outdated تعمل على النحو المنشود ، كما ذكر عندما أعيد فتح المشكلة. ما إذا كان هذا السلوك يجب أو لا ينبغي أن يكون هو الوضع الافتراضي وكيف يتماشى مع مديري الحزم الآخرين ليست في الحقيقة القضية المركزية هنا. دعنا نصلح الشيء أولا.

تضمين التغريدة

عند الانعكاس ، يحدث لي الآن أن هذا هو ما تفعله npm / yarn افتراضيًا عند تثبيت حزمة ؛ يعثرون على أحدث إصدار major.minor ويحددون ^ major.minor.0 في package.json ، مما يمنع ترقيات الإصدارات الرئيسية غير المتوقعة ، حتى عندما يُطلب صراحةً الترقية إلى الأحدث. أتساءل عما إذا كان ينبغي على Pipenv أن يفعل الشيء نفسه - لكن هذه ستكون قضية منفصلة.

نعم ، هذا على غرار ما كنت أحاول اقتراحه في https://github.com/pypa/pipenv/issues/966#issuecomment -408420493

متحمس حقًا لسماع أنه يتم العمل على هذا!

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

benkuhn ليس هذا ما أعرفه - أفعل نفس القفل

حسنًا ، يمكنك على الأقل في بعض الأحيان تجنب التراجع باليد:

1. pipenv lock
2. git commit -m "FIXME: revert"
3. pipenv install packagename
4. git commit -m 'Add dependency on packagename'
5. git rebase -i
6. قم بإسقاط التزام FIXME: revert

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

يبدو أن --keep-outdated يحافظ بشكل منهجي على التبعيات الصريحة المحددة (غير المثبتة) في ملف Pipfile ، بينما يتم تحديث جميع التبعيات الضمنية.

هل أصح أنه لا يمكن تحديث / تثبيت تبعية واحدة باستخدام pipenv==2018.7.1 بدون تحديث التبعيات الأخرى؟ لقد جربت تركيبات مختلفة من --selective-upgrade و --keep-outdated دون نجاح.

تحرير Pipfile.lock يدويًا ليس ممتعًا ...

مثل @ max-arnold ، إنه أول يوم لي باستخدام الأداة في مشروع قائم ، ويجب أن أقول إنني محبط حقًا ، قبل أن أبدأ في استخدامه ، تحققت من موقع المستند وعرض الفيديو ، بدا الأمر مثيرًا للإعجاب بالنسبة لي ، والآن هذا: في مشروع حقيقي ، العمل مع pip أو pipenv هو نفسه تقريبًا ، لا أرى النقطة ، كما قال العديد من الأشخاص الآخرين في الموضوع ، إذا كان لدي ملف قفل ، لماذا تقوم بتحديث التبعيات الأخرى الخاصة بي إذا لم تكن هناك حاجة لتحديثها.

بالطبع ، ### إذا كان التحديث إلزاميًا ، فلا بأس من تحديث جميع التبعيات الضرورية ، ولكن فقط تلك ، وليس كل التبعيات القديمة بدلاً من ذلك.

أيضًا الخيارات --selective-upgrade و --keep-outdated ليست واضحة لما هو مفيد ، هناك مشكلة أخرى تبرز هذا هنا # 1554 ، ولا أحد قادر على الرد على ما تفعله هذه الخيارات ، لا يصدق.

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

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

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

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

لكن الأمور تزداد سوءًا الآن ، وما سأقوله إنه ليس رأيًا ، إنها حقيقة.

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

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

لذا فإن الاستنتاج (ومرة أخرى رأي ، ليس حقيقة مثل pipenv حطمت كل تبعياتي) وهي أن Pipenv بدلاً من مساعدتي في التعامل مع إدارة التبعيات ، فإنه يحولها إلى جحيم.

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

منذ حوالي شهر جربت بديلاً أكثر شمولاً لـ pipenv ، poetry ؛ لقد حل المشاكل _ أنا بحاجة لحل:
1) إدارة مجموعة واحدة من التبعيات (setup.py و setup.cfg و pip و pipfile -> pyproject.toml)
2) موجه نحو المستقبل ، متوافق مع الإصدارات السابقة (مرة أخرى pyproject.toml )
3) ليس له رأي إلى حد ما (
4) والحل لمشكلة Pipenv الكلاسيكية: "أيضًا ، عليك أن تخبرها صراحة [pipenv] بعدم تحديث الحزم المقفلة عند تثبيت حزم جديدة. يجب أن يكون هذا هو الخيار الافتراضي." [[1] (https://github.com/sdispater/poetry#what-about-pipenv)] [[2] (https://github.com/pypa/pipenv/issues/966#issuecomment-339117289)]

لقد وزنت مشاركة هذه الأفكار حول قضية pipenv ، ولكن كما قال uranusjr ، "لا أحد يفرض Pipenv على أي شخص" ، وأنا لا أجبر الشعر. يعجبني ، إنه يعمل بشكل جيد ، وهو يحل مشاكلي ، لكني أشارك فقط حلاً بديلاً أكثر شمولاً للمشكلة التي كنت أواجهها. فقط خذ كل هذا على أنه 2 ¢.

• كإخلاء طرف ، أنا لست عضوًا في فريق الشعر أو منتسبًا إليهم.

ملاحظة: أعتقد أن القلق بشأن كون Pipenv هو الحل "الرسمي" يرجع إلى تكامله من الدرجة الأولى - وهو أمر قد تراه أنت ، uranusjr ، بمثابة توصية بسيطة -

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

بالنسبة للمستخدمين المهتمين بتجربة المحلل البديل أعمل منذ عدة أسابيع حتى الآن ، يرجى تجربة https://github.com/sarugaku/passa والذي سينشئ ملفات قفل متوافقة. يقوم الشعر بالكثير من الأشياء المختلفة ، ولكن له أيضًا قيودًا وقضايا في حد ذاته ، ولدينا اختلاف في فلسفة التصميم حول النطاق.

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

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

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

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

تضمين التغريدة

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

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

كما أن لديها قيودًا وقضايا بحد ذاتها

اي واحدة؟ لدي فضول حقًا بشأن المشكلات أو القيود التي واجهتها أثناء استخدام الشعر.

اعتذاري لفول وقح جدا. الآن قراءة تعليقاتي أدرك أنه على الرغم من المعلومات التي قدمتها وبعض خياراتي لا تزال صالحة (IMHO) ، لم يتم تخصيصها بالطريقة التي كتبت بها ما أريد أن أقوله.

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

أعتقد أن هناك موضوعين قويين هنا:

• يجب أن يقوم pipenv بتحديث جميع التبعيات القديمة الخاصة بك حيث تحاول فقط تثبيت تبعية جديدة: تلك التي لا تحتاج إلى التحديث لأن الحزمة / الإصدار الجديد الذي نحاول تثبيته يمكن أن يعمل مع التبعيات الموجودة ، وحتى تلك التي لا توجد تبعيات الحزمة الجديدة التي نحاول تثبيتها؟ ربما يكون هذا خارج نطاق هذه التذكرة ، لكنه موضوع مهم حقًا للمناقشة.
• هل تسمح لنا إحدى هذه المعلمات --keep-outdated --selective-upgrade بتجنب هذا السلوك؟ ليس من الواضح ما تفعله هذه الخيارات ، فهناك نقص في الوثائق المتعلقة بها ، وحتى في المسألة ذات الصلة (# 1554) لا أحد يجيب على ذلك.

في حالة وجود خطأ في إحدى هذه المعلمات --keep-outdated --selective-upgrade ، ما زلت أعتقد أن عدم تعيين أي معلمة يحل التحديث غير الضروري للاعتماديات على أنها فكرة سيئة حقًا.

للمقارنة مع سيناريو مشابه ، تخيل أنك تقوم بتنفيذ apt-get install vim لتثبيت الأداة vim في نظامك (والاعتمادات أو التحديثات الضرورية لـ vim إذا تم تطبيقها) ، لكن تخيل ذلك أيضًا في هذه الحالة يقوم apt بتحديث جميع التبعيات الأخرى لنظامك: python ونظام QT و Linux kernel ... وما إلى ذلك. ليس الأمر أن apt لا يجب أن يسمح لنا بتحديث التبعيات الأخرى ، ولكن هناك أمر واضح للقيام بذلك: apt-get upgrade ، بينما apt-get install PACKAGE فقط قم بتثبيت / تحديث PACKAGE وتبعياتها.

sdispater ، فإن التمييز هو جوهر كل خلاف بيننا من قبل وهو دقيق بشكل لا يصدق ولكني https://caremad.io/posts/2013/07/setup-vs-requirement/ أو جيد مقال عن حالة استخدام الإكسير: http://blog.plataformatec.com.br/2016/07/understanding-deps-and-applications-in-your-mixfile/

pyproject.toml غير مدعوم حقًا للبيانات الوصفية لتعريف المكتبة - وليس على الإطلاق بواسطة أي إصدار من النقاط لا يطبق Peps 517 و 518 (كلاهما لا يزال لديه تفاصيل التنفيذ) كمرجع موثوق ملف إعلان المكتبة. setup.cfg موجود لهذا الغرض (الوريث الفعلي لـ setup.py ) ويجب دعم كل من IMHO بالفعل. تم نشر مكتبة وهي مخصصة للاستهلاك مع التبعيات المجردة حتى يتمكنوا من اللعب بلطف في وضع الحماية مع الآخرين ؛ التطبيقات عادة ما تكون كبيرة ومعقدة وحوش مع مئات التبعيات المباشرة في بعض الأحيان. لذا فإن أحد الاختلافات الرئيسية لدينا هو أنه عندما نصمم ونبني أدواتنا ، فإننا نأخذ ذلك في الاعتبار أيضًا

mrsarm بالنسبة ccncoghlan ويتعلق بمخاوف أمان OWASP). فيما يتعلق بالنقطة الثانية ، لم يتم تنفيذ السلوك بشكل صحيح حاليًا وهذا هو سبب استمرار فتح المشكلة ، مما أدى بنا إلى إعادة كتابة محلل الدعم وراء pipenv ، والذي ذكرته أعلاه. إنه ببساطة لم يدعم هذا السلوك. --selective-upgrade المفترض أن يقوم --keep-outdated سيحبط أي شيء يرضي التبعيات التي تتطلبها الحزمة الجديدة. مختلف قليلاً ، لكنني متأكد تمامًا من أنه لا يعمل بشكل صحيح في الوقت الحالي.

لا يتم دعم pyproject.toml حقًا للبيانات الوصفية لتعريف المكتبة - وليس على الإطلاق بواسطة أي إصدار من pip لا يقوم بتطبيق peps 517 و 518 (كلاهما لا يزال لديه تفاصيل التنفيذ) كملف إعلان موثوق للمكتبة . يوجد setup.cfg لهذا الغرض (الوريث الفعلي لـ setup.py) ويجب دعم كل من IMHO بالفعل.

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

لا يوجد في الواقع أي معيار حول setup.cfg الآن بخلاف الاصطلاحات التي أنشأتها Distutils و setuptools. pyproject.toml هو مطلقًا للبيانات الوصفية للمكتبة كخليفة لـ setup.py أو أن المجتمع قد وضع متطلبات البناء في setup.cfg بدلاً من ذلك.

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

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

الاختلاف الحقيقي الوحيد بين التطبيق والمكتبة في تجربتي مع Python والأنظمة البيئية الأخرى هو ما إذا كنت تستخدم ملف قفل أم لا. بالطبع هناك حالة ثالثة تريد فيها حقًا requirements.txt أو Pipfile ولا يوجد رمز فعلي ويبدو أن هذا هو كل ما ركز عليه pipenv حتى الآن ( pipenv install -e . ينهار في هذه الفئة حيث لا يزال pipenv خائفًا من محاولة دعم البيانات الوصفية للحزمة). لسوء الحظ ، على الرغم من أن تصميم pipenv أكثر نظافة مع هذا النهج ، إلا أنه أيضًا أقل فائدة لمعظم التطبيقات لأن PEP 518 قرر البحث عن كيفية تثبيت المشاريع في الوضع القابل للتحرير ، لذلك من أجل الاستمرار في استخدام pipenv ، سنكون عالقين في أدوات الإعداد تمامًا. طالما أنك لا تستطيع استخدام pyproject.toml للتبديل بعيدًا عن setuptools وما زلت تستخدم pipenv install -e . .

لا يوجد في الواقع أي معيار حول setup.cfg في الوقت الحالي بخلاف الاصطلاحات التي أنشأتها Distutils و setuptools. يعد pyproject.toml مخصصًا تمامًا للبيانات الوصفية للمكتبة باعتباره خليفة setup.py أو أن المجتمع قد وضع متطلبات الإنشاء في setup.cfg بدلاً من ذلك.

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

كان المجتمع قد وضع متطلبات البناء في setup.cfg بدلاً من ذلك.

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

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

ظهر هذا في القائمة البريدية مؤخرًا - لم يعلن أي شيء في أي مكان عن معيار حول pyproject.toml بخلاف أنه سيتم استخدامه للإعلان عن متطلبات نظام البناء. أي شيء آخر هو افتراض؛ يمكنك تسمية "البيانات الوصفية لتعريف المكتبة" ، لكنها ليست كذلك. حاول فقط تحديد نظام بناء بدون معلومات إضافية عن مشروعك (أي لا توجد بيانات وصفية متوافقة مع pep-345) وقم بتحميله على pypi وأخبرني كيف تسير الأمور.

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

من يقول أن التطبيقات لا تتطلب نقاط دخول؟ Pipenv لديه بنية كاملة للتعامل مع هذا.

لذلك من أجل الاستمرار في استخدام pipenv ، سنبقى عالقين في setuptools لفترة أطول حيث لا يمكنك استخدام pyproject.toml للتبديل بعيدًا عن setuptools وما زلت تستخدم تثبيت pipenv -e.

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

ظهر هذا في القائمة البريدية مؤخرًا - لم يعلن أي شيء في أي مكان عن معيار حول pyproject.toml

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

وبنفس المنطق الذي ذكرته هنا:

يعد Distutils جزءًا من المكتبة القياسية ويتم تثبيت setuptools مع pip الآن ، لذا فإن القول بعدم وجود معيار هو أمر سخيف بعض الشيء.

pyproject.toml هو معيار ، وقد تبناه المجتمع كموقع قياسي لوضع المعلومات المتعلقة بنظام الإنشاء وأجزاء أخرى من مشروع Python.

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

تم تثبيت PEP 517 على عمليات التثبيت القابلة للتحرير ... مما يعني أنه لا توجد طريقة قياسية لتثبيت مشروع في وضع قابل للتحرير إذا كنت لا تستخدم أدوات الإعداد (التي لها مفهوم يعرف باسم وضع التطوير الذي يثبت المشروع في الوضع القابل للتحرير).

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

نعم ، من المتوقع أن يقوم نظام الإنشاء بإخراج ملف PKG-INFO الموضح في PEP 345. هذا تنسيق نقل يتم وضعه في sdist أو عجلة ويتم إنشاؤه من setup.py/setup.cfg ، فهو ليس بديلاً مثل مثل البيانات الوصفية التي تواجه المستخدم. يدور استخدام PEP 518 لـ pyproject.toml حول دعم بدائل distutils / setuptools كنظام بناء ، ولا يحاول أحد استبدال تنسيقات sdist / wheel الآن. تحتاج أنظمة البناء البديلة هذه إلى مكان لوضع البيانات الوصفية الخاصة بها ولحسن الحظ حجز PEP 517 مساحة الاسم tool. لهذه الأنظمة للقيام بذلك. إنه ليس افتراضًا - فقد تبنى كل من flit والشعر مساحة الاسم هذه لـ "البيانات الوصفية لتعريف المكتبة".

حاول فقط تحديد نظام بناء بدون معلومات إضافية عن مشروعك (أي لا توجد بيانات وصفية متوافقة مع pep-345) وقم بتحميله على pypi وأخبرني كيف تسير الأمور.

كيف بناءة.

من يقول أن التطبيقات لا تتطلب نقاط دخول؟ Pipenv لديه بنية كاملة للتعامل مع هذا.

أين هذا البناء؟ لا أستطيع حتى العثور على كلمة "دخول" في أي صفحة من وثائق pipenv على https://pipenv.readthedocs.io/en/latest/ لذا يبدو أن "البنية الكاملة" تبدو بعيدة المنال؟ إذا كنت تقصد تثبيتات قابلة للتحرير ، فقد وصلنا إلى النقطة التي كنت أقوم بتوضيحها أعلاه - حيث قرر pipenv أن يقرن نفسه بـ pipenv install -e . كطريقة وحيدة للربط بين التطبيق وتطويره كحزمة ، لدعم pipenv في المستقبل المنظور هنا يقترن بـ setuptools. أعتقد أن الجدل بأكمله يتلخص في هذه النقطة حقًا والناس (بالتأكيد أنا) محبطون لأنه يمكننا الآن تحديد المكتبات التي لا تستخدم أدوات الإعداد ولكن لا يمكن تطويرها باستخدام pipenv. لكي نكون واضحين تمامًا ، فإن هذا ليس خطأ pipenv تمامًا (قرر PEP 518 إجراء عمليات تثبيت قابلة للتحرير) ، لكن رفضه الاعتراف بالمشكلة كان محبطًا في الخطاب حيث يوفر الشعر بديلاً يعالج هذه المشكلة بطريقة متوافقة بتنسيق pyproject.toml . يستمر Pipenv في القول إن الشعر يتخذ قرارات سيئة لكنه لا يحاول في الواقع توفير طريق للمضي قدمًا.

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts

يرجى قراءة الوثائق.

berjwregeer :

pyproject.toml هو معيار ، وقد تبناه المجتمع كموقع قياسي لوضع المعلومات المتعلقة بنظام البناء ، وأجزاء أخرى من مشروع Python.

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

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

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

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts
يرجى قراءة الوثائق.

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

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

لذا نعم ، من فضلك خذ سميتك في مكان آخر. موقفك غير مرحب به هنا. تحذير نهائي. لن يتم التسامح مع المحاولات المستمرة للتحريض على الصراع.