Pip: ترقيات "pip install -U" تبعيات راضية بالفعل

في رأيي أنه سلوك معروف ، لا أعرف ما إذا كان هذا خطأ بالفعل - أعتقد أن easy_install له نفس السلوك.

أود أن أرى آراء الآخرين.

ملاحظة: كان هناك سؤال في StackOverflow يتعلق بهذا: http://stackoverflow.com/questions/5937756/why-is-pip-looking-for-download-cache-if-the-same-exact-package-is -بالفعل- تركيب

ذات صلة بالموضوع رقم 49

إنه خطأ ، وهو نسخة مكررة من رقم 49.

لا أعتقد أنها نسخة مكررة من رقم 49. قرأت رقم 49 كقول إن install -U foo يجب ألا يعيد تثبيت _ foo نفسه_ إذا كان موجودًا بالفعل في أحدث إصدار - وهو يختلف عما إذا كان يجب إعادة تثبيت foo تبعيات راضية بالفعل.

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

• foo 0.1 يعتمد على lxml>=2.3.0
• تم تحرير foo 0.2 ، ويعتمد على lxml>=2.3.0 (نفس التبعية)
• تم تحرير lxml 2.4.0

إذا قمت بالفعل بتثبيت foo 0.1 و lxml 2.3.0 ، وأنا pip install -U foo ، فلن أرغب في تثبيت lxml 2.4.0 . يجب فقط تثبيت lxml 2.4.0 عندما يبدأ foo بالاعتماد على lxml>=2.4.0 .

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

أعتقد أننا إذا أجرينا هذا التغيير ، فسيجده بعض الناس مفاجئًا. يمكنني معرفة سبب الرغبة في ذلك في حالات معينة - لكن يمكنني أيضًا رؤية الحالات التي يكون فيها السلوك الحالي (ناقص # 49) هو الأفضل. لذا فأنا على الحياد بشأن هذا.

هل سيكون خيار سطر الأوامر الإضافي مناسبًا؟ pip install foo --upgrade مقابل pip install foo --upgrade-recursive ؟ (أو --upgrade-nonrecursive إذا كان الحفاظ على السلوك الحالي المتوافق مع الإصدارات السابقة مهمًا)

إن جعل الترقيات غير متكررة بشكل افتراضي من شأنه أن يوفر الاتساق مع مديري الحزم الآخرين ، مثل APT و Portage. وأعتقد أن هناك سببًا جيدًا لمثل هذا السلوك ، وهو أنه يتجنب الآثار الجانبية غير المقصودة - إذا كنت أرغب في ترقية حزمة P ، فأود إدخال أمر على غرار upgrade P ، ليس upgrade P --but-not-other-things .

من ناحية أخرى ، أعتقد أن أمر "ترقية الكل" (انظر # 59) يجب أن يكون تكراريًا افتراضيًا ، لأن "الكل" يجب أن تعني "الكل" افتراضيًا. في هذه الحالة ، قد يعني السلوك غير التكراري "ترقية جميع الحزم المثبتة مباشرةً ، ولكن ليس أي تبعيات لم يتم تثبيتها مباشرةً" (مثل Portage's emerge --update @world بدون --deep ).

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

يبدو أن هذا يحدث مع -I وكذلك -U.

نظرًا لأن -I يمثل --ignore-installed ، ويهدف إلى جعل النقطة تعمل كما لو لم يتم تثبيت أي شيء حاليًا ، فإن إعادة تثبيت كل شيء هو السلوك الصحيح لـ -I . وبالتالي فإن السلوك هنا ليس سوى خطأ في -U ، وليس لـ -I .

easy_install ليس له نفس السلوك. لن يقوم easy_install بإعادة تثبيت التبعيات إذا تم الوفاء بها بالفعل.

هذه ليست ميزة أو سلوكًا ، هذا خطأ.

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

لأولئك الذين يريدون فقط طريقة للقيام بهذا _now_ ، باستثناء تغيير السلوك / الرمز إلى "-U"

أعتقد أن هذا يحقق النتيجة المرجوة ، أليس كذلك؟

ترقية متطلبات المستوى الأعلى فقط:

• تثبيت Pip -U - لا يوجد-Deps REQS // يقوم بترقية المستوى الأعلى فقط
• pip install REQS // هذا الممر الثاني سوف يثبت أي تبعيات جديدة من الترقية

لأبسط الحالات التي تكون كافية ، لكنني لا أعتقد أن هذا يعمل مع ملف requirements.txt ، أو إذا كانت هناك تبعيات تحتوي على تحديثات لمتطلبات install_requires الخاصة بهم. لدينا نص برمجي معقد يقوم باختلاف متطلباتنا. txt ويقوم أكثر أو أقل بما تصفه ، لكنه لا يتعامل مع عمق الترقية> 1.

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

مرحبًا fdintino ، لقد جهزت اختبارًا أساسيًا بالمتطلبات ، -U و - no-deps وبدا أنه يعمل ، أي تمت ترقية العناصر الموجودة في ملف المتطلبات ، ولكن بدون تبعيات. يتوافق مع فهمي لما تقوم به الشفرة. إنه أمر ممل ، لذا قد يكون هناك فشل في هذه الفكرة.

في حالة احتواء متطلبات المستوى الأعلى على تبعية جديدة لـ "install_requires" ، لهذا السبب ذكرت أمر 2nd pass لتثبيت تلك المتطلبات.

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

فقط إذا لم تعد تلبي المتطلبات. لذلك ، على سبيل المثال ، إذا قمت بتحديث django-sentry ، وكان django-sentry مطلوبًا django-celery>=2.5.4,django-celery<3.0 حيث كان يتطلب سابقًا django-celery>=2.5.3,django-celery<3.0 (ربما بسبب إصلاح خطأ أو ميزة جديدة) ، ولدي حاليًا django-celery==2.5.3 ، إذًا أتوقع تحديث django-celery لتلبية المتطلبات ، بالطريقة التي يعمل بها التصحيح. ومع ذلك ، إذا كان لدي django-celery==2.5.4 ، فلن أتوقع أن يقوم بتحديث الكرفس. في حالة الكرفس ، فهي ليست مشكلة كبيرة ، ولكن عندما تحتوي الحزم على Django>1.2,Django<=1.4 ، وغالبًا ما تتم كتابة المشروعات لاستهداف Django 1.2 أو 1.3 أو 1.4 ، يمكن أن تكون الترقية غير المتوقعة لـ django مشكلة كبيرة.

fdintino شكرا. أنا أتابع الآن. لا ترغب في قطع جميع السلوكيات العودية (التي ستقوم بالترقيات اللازمة لتلبية المتطلبات) ، فقط تريد إيقاف الترقيات المتكررة "القسرية".

راجع للشغل ، تم اقتصاص تعليقك بسبب التنسيق. قد ترغب في إصلاح ذلك للآخرين.

لقد قمت بنشر فكرة تفصيلية عن تحقيق السلوك المطلوب باستخدام الأمرين بالتسلسل المذكورين أعلاه.
لا يعني ذلك أنه يبطل الرغبة في الحصول على هذه التذكرة أو السحب ، ولكن كان من المفيد لي أن أؤكد كيف
يعمل حاليا وما هو ممكن حاليا.
(تلميح: في المثال ، "b" هي موازية لـ django التي تم ذكرها على أنها مصدر قلق)

https://gist.github.com/3088149

التعليق موضع تقدير على جوهر إذا لم يكن هذا هو السيناريو.

لقد لاحظت أن هذا كان مفتوحًا لفترة طويلة.

لقد وجدت أن إصدار النقطة الخاص بي لديه الآن خيار القيام به

pip install --upgrade --upgrade-strategy=only-if-needed package

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

إذا فات الأوان لتغيير الإعداد الافتراضي ، فأعتقد أنه يمكن إغلاق هذا؟

في https://github.com/pypa/pip/issues/3871#issuecomment -247789343 ذكرت ما أعتقد أنه الطريقة التي سنمضي بها قدمًا في هذا الأمر ، مع إعادة الإنتاج هنا:

نعود إلى هذا الآن. هذا ما أعتقد أنه يجب علينا القيام به:

1. إضافة --upgrade-Strategy = [متحمس / غير متلهف] في النقطة vX التي تكون القيمة الافتراضية هي eager ، وتسمح للأشخاص بالاشتراك في الإستراتيجية غير المتحمسة. سيتيح لنا ذلك إجراء بعض الاختبارات الواقعية من الأشخاص دون فرض تغيير على الجميع دفعة واحدة.
2. بمجرد معالجة أي ملاحظات من 1. ، قم بتبديل الإعداد الافتراضي --upgrade-strategy إلى non-eager بالنقطة vX + 1. سيوفر لنا هذا الكثير من الاستخدام في العالم الحقيقي من خلال فرض تغيير على الجميع ، ولكنه يمنحنا فتحة هروبًا للأشخاص الذين ، لأي سبب من الأسباب ، كسرهم التغيير.
3. بمجرد معالجة أي ملاحظات من 2. ، انظر إلى إهمال --upgrade-strategy في النقطة vx + 2 (ستتم إزالتها وفقًا لسياسة الإيقاف العادية).

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

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

xavfernandezdstufft يمكن إغلاق هذا أو سوف ننتظر حتى مفاتيح افتراضية؟

ربما سننتظر حتى التبديل الافتراضي.

ختاما ، حيث تم دمج # 4500