"الترقية" هو اسم مستعار تافه لـ "install --upgrade". بحاجة إلى التفكير أكثر قليلا
حول "ترقية الكل" ؛ لسبب واحد ، أفترض أنه سيؤدي فقط إلى ترقية الحزم
داخل sys.prefix؟ (على سبيل المثال ، إذا كنت داخل Virtualenv ، فلن تحاول ذلك
ترقية الحزم العالمية). سيكون هذا سببًا للتحرك
UninstallPathSet.can_uninstall () إلى دالة ذات تسمية عامة (أو
طريقة InstallRequirement) ، لذا فهي توفر "هل يمكنني لمس هذا؟"
قرارات.

Original Comment By: Carl Meyer

للتسجيل ، أعتقد أن هذه تبدو فكرة جيدة ، بالنظر إلى القدرة على ذلك
قم بإلغاء التثبيت قبل الترقية. على الرغم من أنني أفضل خيار --all لـ
upgrade بدلاً من الأمر upgrade-all .

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

Original Comment By: Jannis Leidel

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

تتطلب الترقية-all منك معرفة ما هو "قابل للترقية". ربما واحد
الموقع المسبق هو أنه يعيش فيه/lib/pythonX.Y/site-packages
(ببساطة تحت sys.prefix لا يكفي).

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

حاولت إلغاء تثبيت حزمة قابلة للتحرير باستخدام "pip uninstall" وهو الأمر تمامًا
عرضت بشكل معقول إزالة رابط .egg وتحديث easy-install.pth. لكن ذلك
لا يمكن ترقية الحزمة بشكل معقول ، لذا فإن can_uninstall إلى حد ما
يختلف عن can_upgrade.

Original Comment By: Ian Bicking

نعم ، أنت محق في أن can_uninstall و can_upgrade مختلفان.

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

Original Comment By: Carl Meyer

+1 لهذا الخطأ

Original Comment By: smyrman

تم وضع علامة على المشكلة رقم 167 على أنها نسخة مكررة من هذه المشكلة.

Original Comment By: Carl Meyer

1

(echo pip; pip freeze | awk 'BEGIN{FS="=="}{print $1}') | xargs sudo pip

تثبيت -U

يجب أن يؤدي هذا إلى ترقية جميع الحزم المثبتة (بما في ذلك النقطة نفسها). إذا
يمكنك تشغيله في virtualenv ، فربما لا تحتاج إلى استخدام sudo.

بالطبع ينطوي على مخاطر عالية للفشل - في حالة ترقية إحدى الحزم
فشل العملية برمتها ستفشل (يشبه port upgrade outdated في
MacPorts).

Original Comment By: Tomasz Elendt

+1 للترقية - الكل

لماذا في الوقت الحالي يجب أن تمتص جميع مرافق إدارة وحدات Python؟ لماذا لا
واحد يوفر ترقية بسيطة + ترقية - كل الأمر؟

Original Comment By: Anonymous

لا أمانع في أخذ لقطة في التنفيذ ، ولكن أولاً بعض الأسئلة.

هو الإجماع العام على أن أمر "ترقية" جديد يدعم "- all"
الخيار تضاف إلى النقطة؟

يجب أن تؤثر ترقية النقطة الجارية فقط على البيئة التي تعمل فيها. إذا
التشغيل من virtualenv ، ثم تتم ترقية الحزم المحلية لتلك البيئة فقط ؛
نفس الشيء لغير Virtualenv

Original Comment By: Kelsey Hightower

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

Original Comment By: Carl Meyer

كارل: رائع ، سأبدأ وأقوم بتحديث هذه التذكرة بالنتائج.

Original Comment By: Kelsey Hightower

أثناء العمل على أمر الترقية ، ظهرت الأسئلة التالية:

• ما هي الطرق التي يجب أن تحصل على دعم
  تطوير؟ هل يجب أن ندعم ملف المتطلبات؟
• كيف يجب أن تتعامل ترقية النقطة مع الحزم التي لم يتم تثبيتها بالفعل؟
  هل يجب تثبيت الحزم المفقودة؟

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

# pip upgrade some_installed_package

Try and locate a package that satisfies the requirement. If the

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

# pip upgrade --all

Locate all installed packages (non-editables) and update them to a new

الإصدار إذا كان متاحًا.

# pip upgrade some_other_package

Warning: some_other_package not installed, use pip install

بعض الحزم_الآخرى.

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

أفكار؟

Original Comment By: Kelsey Hightower

أعتقد أن "ترقية النقطة" يجب أن تكون اسمًا مستعارًا دقيقًا لـ "تثبيت النقطة - ترقية" مثل
انه يعمل الان. هذا يعني أنه نعم ، يقوم بتثبيت الحزم المطلوبة إذا كانت كذلك
غير مثبتة ، ونعم ، فهي تقبل ملفات المتطلبات ذات -r. ينبغي له
تكون قابلة للتنفيذ مع عدم وجود رمز جديد تقريبًا.

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

Original Comment By: Carl Meyer

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

Original Comment By: Kelsey Hightower

حصلت على معظم الكود ، بقي القليل من التلميع قبل أن أنشر الكود
للمراجعة.

لكى يفعل:

• الاختبارات
• ملف متطلبات التصفية ؛ إضافة عناصر غير قابلة للتحرير إلى قائمة الحزم إلى
  تطوير.

تشغيل النقطة باستخدام أمر الترقية

# pip upgrade --all

All packages up-to-date


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

All packages up-to-date


# pip upgrade PyYAML

Package updates available:

  PyYAML: N/A (installed) 3.09 (latest)

Downloading/unpacking PyYAML

  Downloading PyYAML-3.09.tar.gz (238Kb): 238Kb downloaded

....

Successfully installed PyYAML

Cleaning up...


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  PyYAML: 3.09 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

All packages up-to-date


# pip upgrade PyYAML==3.08

Downloading/unpacking PyYAML==3.08

....

Successfully installed PyYAML

Cleaning up...


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

Package updates available:

  PyYAML: 3.08 (installed) 3.09 (latest)

Downloading/unpacking PyYAML

...

Successfully installed PyYAML

Cleaning up...

  Removing temporary dir /root/upgrade_env/build...

Original Comment By: Kelsey Hightower

آخر مجموعة من الأسئلة (أتمنى):

• يجب أن تقوم ترقية النقطة بتحليل ملف المتطلبات والتصفية
  قابلة للتحرير؟ ماذا عن متطلبات URL؟

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

نرحب بأي نصائح (تبحث حاليًا في pip.req.parse_requirements )

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

في الوقت الحالي ، أقوم بإضافة حزم إلى قائمة الترقية فقط عندما:

• الحزمة غير مثبتة
• تتوفر ترقية (إصدار لاحق من الفهارس) ، وليست صريحة
  تم طلب الإصدار
• يختلف الإصدار المطلوب عن الإصدار المثبت (Version miss
  مباراة).
• أقوم بتأجيل ملف المتطلبات إلى أمر التثبيت حتى أقوم بالتصفية
  من المتطلبات غير القابلة للتحرير.

Original Comment By: Kelsey Hightower

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

Original Comment By: Kelsey Hightower

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

Original Comment By: Kelsey Hightower

نعم ، يبدو أنك تفعل أكثر مما ينبغي. تثبيت Pip
- الترقية تفعل كل ما تناقشه بالفعل (التحقق من أحدث
الإصدارات ، إلخ) ؛ يجب أن تكون كل "ترقية النقطة" بمثابة تمرير ذي خطين
كل شيء انتهى لتثبيت - ترقية.

الكود الحقيقي الوحيد الذي يجب كتابته هنا هو رمز "الترقية - الكل" للحصول عليه
القائمة الكاملة للحزم المثبتة القابلة للترقية في البيئة.

Original Comment By: Carl Meyer

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

سأعيد العوامل وتنظيف الأشياء. التغييرات الحالية في شوكة بلدي على
فرع قيادة الترقية.

https://bitbucket.org/khightower/pip/changeset/2bdc202b446c

Original Comment By: Kelsey Hightower

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

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

تشغيل أمر ترقية النقطة

# pip upgrade Mako


Downloading/unpacking Mako

  Running setup.py egg_info for package Mako


    warning: no files found matching '*.jpg' under directory 'doc'

    warning: no files found matching '*.sty' under directory 'doc'

    warning: no files found matching 'autohandler' under directory 'doc'

    warning: no files found matching '*.xml' under directory 'examples'

    warning: no files found matching '*.mako' under directory 'examples'

    warning: no files found matching '*.dat' under directory 'test'

    warning: no files found matching 'ez_setup.py'

Downloading/unpacking MarkupSafe>=0.9.2 (from Mako)

  Running setup.py egg_info for package MarkupSafe


Installing collected packages: Mako, MarkupSafe

  Found existing installation: Mako 0.3.6

    Uninstalling Mako:

      Successfully uninstalled Mako

  Running setup.py install for Mako

    changing mode of build/scripts-2.7/mako-render from 644 to 755


    warning: no files found matching '*.jpg' under directory 'doc'

    warning: no files found matching '*.sty' under directory 'doc'

    warning: no files found matching 'autohandler' under directory 'doc'

    warning: no files found matching '*.xml' under directory 'examples'

    warning: no files found matching '*.mako' under directory 'examples'

    warning: no files found matching '*.dat' under directory 'test'

    warning: no files found matching 'ez_setup.py'

    changing mode of /root/upgrade_env/bin/mako-render to 755

  Found existing installation: MarkupSafe 0.11

    Uninstalling MarkupSafe:

      Successfully uninstalled MarkupSafe

  Running setup.py install for MarkupSafe


    building 'markupsafe._speedups' extension

    gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall

-نماذج Wstrict -fPIC -I / opt / OpenPython-2.7.1 / include / python2.7 -c
markupsafe / _speedups.c -o build / temp.linux-x86_64-2.7 / markupsafe / _speedups.o

    gcc -pthread -shared

بناء / temp.linux-x86_64-2.7 / markupsafe / _speedups.o -o
build / lib.linux-x86_64-2.7 / markupsafe / _speedups.so

Successfully installed Mako MarkupSafe

Cleaning up...

Original Comment By: Kelsey Hightower

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

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

Original Comment By: Carl Meyer

شكرًا كارل ، سأختتم هذا وأبدأ في النظر إلى رقم 13

Original Comment By: Kelsey Hightower

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

https://bitbucket.org/khightower/pip/src/fa7b2a6d2bf1/pip/commands/upgrade.py

Original Comment By: Kelsey Hightower

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

https://github.com/pypa/pip/pull/313
https://github.com/jedie/pip/commit/7a31d70dabe0e809184fe1b5280c5a7ccf420dd5

jedie أعتقد أنك قصدت توجيه تعليقك إلىkhightower. vbabiy رحلت تعليقها إلى هنا لكنها لم تكتب أمر الترقية.

+1

kelseyhightower أي تقدم؟

+1

+1!

+1

+1

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

بدلاً من ذلك ، سأكون سعيدًا لرؤية التعليق "تم التصحيح!" ؛)

+1

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

pradyun راجع https://github.com/pypa/pip/issues/59#issuecomment -9418336

+1

اعتقدت أن هذا قد تم دمجه بالفعل. يمكنني التخلص من مهارة الثعبان الخاصة بي ومنحها فرصة أخرى.

هل سيتم تضمين هذه الميزة في 1.5؟ لا يمكن العثور على أي إشارة إليه في الوثائق 1.5 ...

+1

ما هو وضع هذه القضية؟

تم حظره بواسطة # 988

إذا كان الأمر مهمًا حقًا بالنسبة لك ، فهناك حلول بديلة لترقية جميع الحزم ؛ لقد جمعت نصًا للقيام بذلك بالتوازي (https://github.com/ariccio/update-pip-packages) ، وهناك العديد من التطبيقات الأخرى في أماكن أخرى على الإنترنت.

هناك جزءان لهذه المشكلة. قد يتم حظر upgrade-all بواسطة gh-988 ، لكني لا أرى كيف تم حظر upgrade . يمكن أن يكون pip upgrade اسمًا مستعارًا بسيطًا لـ pip install -U --no-deps . سيؤدي هذا إلى حل إحدى المشكلات الرئيسية لاستخدام install_requires في ملفات setup.py. ألا يمكن القيام بذلك في وقت قريب؟

يمكن أن تكون ترقية النقطة اسمًا مستعارًا بسيطًا لتثبيت النقطة -U - no-deps

من الوصف:

pip upgrade مثل pip install --upgrade باستثناء أنه سيكون غير متكرر افتراضيًا (وعرض خيار --recursive ). لقد تسبب سلوكها الافتراضي المتكرر الحالي في حزن الكثيرين (# 304). بالنسبة لكيفية إجراء ترقيات غير متكررة الآن ، انظر هنا

هذا ليس pip install -U --no-deps

"غير العودية" في هذا السياق لا تعني ببساطة –no-deps . ستعمل الترقية غير التكرارية على ترقية التبعيات ، ولكن فقط إذا لزم الأمر للوفاء بالمتطلبات الرئيسية.

qwcode شكرا للتوضيح. إذن هذا ليس ما أهتم به. لماذا تسمي هذا "غير متكرر" ، فهو لا يزال تكراريًا ولكنه أكثر ذكاءً / مختلفًا؟

كنت تحت انطباع من المناقشة في gh-571 أن غير التكراري حقًا هو الافتراضي المطلوب. سيكون هذا منطقيًا بالتأكيد ، ويمنع الاضطرار دائمًا إلى كتابة تعليمات برمجية مثل https://github.com/scipy/scipy/commit/8e7ee0c4b3c16.

في # 571 ، "non-recursive" ليس --no-deps إنه تكراري "أذكى / مختلف" كما تقول.
لاحظ الاختبار test_upgrade_with_needed_recursive_upgrades() من ذلك PR.

دون أن تتعثر في شروط ، هناك 3 أشياء:

1. "ترقية أكثر ذكاءً / مختلفة" ، أي النوع الذي يحدث في حزمة نظام التشغيل الذي يمكن أن يتضمن أيضًا ترقية التبعيات (ولكن فقط إذا كانت بحاجة إلى ترقية فعلية).
2. ما تفعله النقطة الآن ، وهو ترقية جميع التبعيات ، بغض النظر عن الحاجة أو حل النزاع.
3. --no-deps

بعض الطرق الممكنة للتمييز بين # 1 و # 2

1. "غير العودية" مقابل "العودية"
2. "عادي" مقابل "متكرر"
3. "فقط إذا لزم الأمر" عودي "مقابل" افعل ذلك بصرف النظر عن التكرار "

أنا منفتح على استخدام أفضل المصطلحات ... لست متأكدًا من ماهية هذه المصطلحات.

أعتقد أنني أحب هذه العبارة العودية "فقط إذا لزم الأمر". ربما يجب علي استخدام ذلك هنا في المستندات:

أنا أحب ذلك أيضا. إذا وصفت الخيارات الثلاثة معًا على أنها

a. non-recursive
b. only if needed recursive
c. recursive (or "do it regardless recursive")

سيكون ذلك واضحا.

ثم تريد اختيار افتراضيات جيدة. لكل من upgrade و install -U ، إما (أ) أو (ب) يمكن أن يكون له معنى. أنا أفضل (أ) بشدة ، لكن (ب) منطقي أيضًا نظرًا لأن هذا ما يفعله تغليف نظام التشغيل.

(ج) ليس له أي معنى كإعداد افتراضي ، لذا يرجى إعادة النظر في قرارك بعدم تغيير install -U .

لتوضيح سبب تفضيلي الشديد (أ): يجب على المستخدم المطمئن الذي يريد (ب) والحصول على (أ) قراءة رسالة تقول "non-recursive upgrade can't satisfy all dependencies, please use only-if-needed recursive" ، وهي ليست صفقة كبيرة. إذا كان الإعداد الافتراضي هو (ب) ، فقد ينتهي الأمر بهذا المستخدم المطمئن بترقية أو حتى تثبيت معطل لحزمة لا يريد فعلاً لمسها. قد يستغرق ذلك ساعات أو حتى أيامًا للتعافي منه.

(ج) ليس له أي معنى كإعداد افتراضي ، لذا يرجى إعادة النظر في قرارك بعدم تغيير install -U

سبب ترك install -U بمفرده هو فقط لأسباب تتعلق بالتوافق ، ثم إلى إهماله في النهاية.

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

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

يبدو خفض install -U جيدًا.

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

قد يكون الاعتماد على --no-deps أمرًا جيدًا للمستخدمين المتمرسين للغاية ، لكن المستخدمين الجدد لن يتعلموا عنه إلا بعد أن تسوء الأمور.

على أي حال ، يبدو أنني لن أستطيع إقناعك. ثم عد إلى الدليل

try:
   import dependency
except ImportError:
    install_requires.append('dependency')
else:
    if dependency.version < 'x.y.z':
        raise ValueError('Please upgrade dependency to x.y.z')

أنه.

qwcode شكرا على الشرح التفصيلي. آمل أن يتقدم هذا في المستقبل القريب - فقط إذا لزم الأمر ، سيكون التكرار تحسنًا كبيرًا على السلوك الحالي.

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

هل هناك أي تحديثات بشأن هذه القضية؟

لدينا الآن 2015 وما زلت بحاجة إلى النسخ من stackoverflow pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U

أجل ، كل التقدم مرتبط بهذه القضية.

يقوم GitHub بعمل جيد في الإحالة المرجعية للأشياء. كل هذه قابلة للنقر! (أنا متأكد من أنك تعرف هذا؟)

نعم بالتأكيد ولكني لا أفهم سبب تأخير هذه الميزة "البسيطة".

ما هو سبب ذلك؟

Am 16.04.2015 um 05:28 schrieb Alexander Riccio [email protected] :

أجل ، كل التقدم مرتبط بهذه القضية.

يقوم GitHub بعمل جيد في الإحالة المرجعية للأشياء. كل هذه قابلة للنقر! (أنا متأكد من أنك تعرف هذا؟)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub.

بالنسبة إلى pip upgrade-all ، يبدو أن الإجماع هو انتظار العمل المتعلق بالرقم 988 قبل إصدار أي أوامر جديدة لامعة لا تزال معيبة في النهاية ويمكن أن تكون خطرة على بيئة العمل. إصدار بسيط من upgrade-all لا يحل المتطلبات بشكل صحيح يمكنه بسهولة كسر الحزم الحالية

+1

ماذا تفعل على مدى 4 سنوات؟

+1

+1

+1

muhasturk حاليا ينتظر ... https://github.com/pypa/pip/issues/59#issuecomment -93646462

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 ... آسف على البريد العشوائي ، ولكن تشغيل pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U يؤلم!

+1

في حالة اهتمام أي شخص بالعمل على هذا ، أعتقد أن التعليقات أعلاه مربكة إلى حد ما - AFAICT الحالة الفعلية هي أن pip upgrade-all محظور حاليًا بسبب الحاجة إلى نظام حل تبعية مناسب ، ولكن pip upgrade يمكن تنفيذ

(انظر أيضًا الموضوع الذي يبدأ هنا وردdstufft هنا والتعليق هنا بالموافقة على التقييم أعلاه.)

إليك مناقشة أخرى من قائمة pypa-dev من عام مضى (توافق على أنه يمكن إجراء pip upgrade FOO الآن) https://groups.google.com/forum/#!searchin/pypa -dev / pip $ 20 ترقية / pypa-dev / vVLmo1PevTg / oBkHCPBLb9YJ

شكراqwcode! لقد رأيت للتو الوصف الجديد على https://pip.pypa.io/en/latest/user_guide/#only -if-needed-recursive-Upgrade- وهذا مفيد.

+1

اذا لم اكن مخطئ:

إذا لم يتم تثبيت xxx:

• pip upgrade xxx سيكون مساويًا لـ pip install xxx
• pip upgrade xxx --recursive سيكون ما يعادل pip install xxx --upgrade

إذا تم تثبيت xxx:

• سيظل pip upgrade xxx --recursive ما يعادل pip install xxx --upgrade (حسب التصميم)
• ولكن لا يوجد حاليًا ما يعادل pip upgrade xxx ، قد يكون هذا pip install xxx --upgrade-only-if-needed/--upgrade-lazy

ليس من الواضح ما هي القيمة المضافة لأمر جديد على إضافة خيار جديد إلى pip install ؟

ليس من الواضح ما هي القيمة المضافة لأمر جديد على إضافة خيار جديد إلى pip install ؟

السلوك الافتراضي pip install -U غير مقبول للعديد من المشاريع. انظر تعليقي أعلاه (https://github.com/pypa/pip/issues/59#issuecomment-52434862). وإليك شرح أطول: http://article.gmane.org/gmane.comp.python.distutils.devel/24218

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

كل هذا يمهد ممرات البقر. إنه ليس استخدامًا شخصيًا

بالفعل. لا يقرأ الناس المستندات. سنصلح بالفعل جميع مستندات التثبيت التي يمكننا العثور عليها ، ولكن بمجرد أن يرى المستخدم -U أو --upgrade هذا ما سيستخدمه. إن فرصة أن يستخدم الناس --no-deps أو --only-as-needed أو أي شيء قبل أن يتعرضوا للعض بشكل خطير هي فرصة بعيدة.

لماذا لا يمكنك بدلاً من ذلك تغيير تثبيت النقطة الحالي - استخدام الترقية إلى تثبيت النقطة - مطلوب الترقية فقط؟

ولكي نكون واضحين: نتجنب pip install --upgrade الآن _و_ لا نستخدم install_requires لهذا السبب. هذا هو مدى سوء الأمر.

أعتقد أن هناك سوء فهم بسيط هنا - يوافق IIUCxavfernandez على إضافة وظيفة الترقية غير التكرارية ، pip install .

xavfernandez : لاحظ أن هناك حاليًا مناقشة تحدث في رقم 3194 حول ما سيكون أوضح واجهة مستخدم لهذه الوظيفة.

(وسيتم إهمال pip install -U ثم إزالته ، لذلك يجيب هذا على السؤال حول كيف سيعرف المستخدمون عدم استخدامه :-).)

أعتقد أن هناك سوء فهم بسيط هنا

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

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

لن يكون هناك سبب للاستمرار في استخدام تثبيت النقطة

ما هي المشكلة لماذا؟ المشكلة (على الأقل لـ qwcode في التعليقات أعلاه) مع تغيير pip install --upgrade إلى السلوك الصحيح هي كسر التوافق مع الإصدارات السابقة. لذا فإن pip upgrade هو السبيل لتجنب هذا الانقطاع _و_ الحصول على القيمة الافتراضية الصحيحة.

rgommers : لكي نكون منصفين ، سوف نحصل على عدد غير صفري من الأسئلة المربكة حول سبب إخبارنا بتشغيل pip upgrade foo عندما لا يكون لديّ foo مثبتًا ، لا يعمل (جادل ذهابًا وإيابًا حتى يحاولوا بالفعل تشغيل الأمر بدلاً من افتراض أنه لن ينجح والتظاهر بأنهم قاموا بتشغيله)

في # 3194 ، كتبت تعليقًا مفاده أنه ربما يكون الطريق الصحيح للمضي قدمًا هو إزالة --upgrade من pip install ، وجعل pip install دائمًا بترقية العناصر المسماة بشكل صريح ، والافتراضي إلى الحد الأدنى من استراتيجية الترقية للاعتماديات بعلامة --recursive للحصول على السلوك الحالي عند الترقية.

أعتقد أنني أوافق على أنني أشعر أنه مع # 3194 ، ستصبح تجربة المستخدم الافتراضية pip upgrade foo بدلاً من pip install [-U] foo . المشكلة الوحيدة التي أواجهها هي أنني أعتقد أنه من المربك الحصول على الأمرين ونظرًا لأنني أعتقد أن pip upgrade سيكون الخيار "الصحيح" ليستخدمه الأشخاص ، أعتقد أنه من التافه أن يكون لديك الأمر الواضح الاسم يكون اسم خاطئ.

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

حسنًا ، لن أجادل في أن المواطن المتخلف مهم هنا. كنت دائمًا أؤيد تغيير سلوك pip install --upgrade . إنه الأنظف ، والتكلفة تبدو صغيرة. ولكن بدا لي أنه تم رفضه من قِبل qwcode ، لذلك كان pip upgrade أفضل شيء تالي (وقد تم قبوله بالفعل من قِبل مطوري النقاط قبل عام).

إذا أردنا الآن العودة إلى تغيير الإعدادات الافتراضية / السلوك مقابل pip install ، فهذا رائع.

dstufft هذا منطقي تمامًا بالنسبة لي - لا يمكن أن يكون الصداع بهذا السوء :)

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

xavfernandez فرض القرارات على المستخدمين هو نوع من --upgrade-only-needed و --upgrade-eager .

xavfernandez إذن أنت تقترح أنه في الموقف الأخير سيكون الأمر pip install --upgrade-only-needed ؟ يبدو قبيحا.

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

ومع ذلك ، فإن شيئًا ما على هذا المنوال سيكون مفيدًا للغاية ، مثل فكرة تثبيت نسخة محددة.

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

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

سيكون مسار الهجرة الواضح هو:

إصدار النقطة X:

• إضافة خيارات pip install --eager ، pip install --no-eager ، حيث يعني --eager أنه بالنسبة للمتطلبات مع عدم إرفاق قيود الإصدار ، نحاول تثبيت أحدث إصدار حتى إذا كان هناك بالفعل بعض الإصدارات المثبتة ، و --no-eager يعني أننا راضون إذا تم تثبيت أي إصدار
• أضف أيضًا الخيار pip install --eager-recursive مع الدلالات الحالية -U
• يبقى --no-eager الخيار الافتراضي
• إذا لم يتم تحديد أي من هذه الخيارات ، وتم تمرير متطلب بدون رقم إصدار مرفق pip install ، وتم استيفاء هذا المطلب بالفعل ، فقم بإخراج تحذير يفيد بأننا لم نقم بترقية الحزمة الخاصة بك ، ولكن في المستقبل سنقوم بذلك ، لذلك يجب عليك استخدام --no-eager إذا كنت تريد الحفاظ على السلوك الحالي
• أضف تحذير إيقاف إلى pip install -U لإحالة الأشخاص إلى pip install --eager-recursive

إصدار النقطة ص:

• تبديل الافتراضي pip install إلى --eager

إصدار النقطة Z:

• إزالة pip install -U

لقد صنعت إصدارات مختلفة من Y و Z لأنني أتوق للحصول على --eager لذلك ربما يمكننا إجراء هذا التغيير وفقًا لجدول أكثر صرامة ، مع الاحتفاظ بـ pip install -U لبعض الوقت نظرًا لأن الكثير من الوثائق تشير بالفعل ولا يسبب أي ضرر. لكن من الواضح أن Y = Z خيار :-)

chriskrycho : هذا يبدو وكأنه أشياء رائعة ، لكن هذه المناقشة

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

ما هو مسار الإهمال العادي للنقطة؟ الوقت / على أساس الإصدار؟ ما هي المدة التي يحتاجها شيء ما ليتم إهماله قبل إزالته؟

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

عادة ما نقوم بدورة إهمال من نسختين.

الإصدارات الرئيسية أفترض؟ الإصدارات الثانوية سريعة حقًا (7.0 -> 7.1 كانت شهرًا واحدًا). عادة نصف عام بين الإصدارات الرئيسية ، لذلك تحذيرات من الإهلاك لمدة عام واحد؟

أجل ، آسف. الإصدارات الرئيسية. إذا قمنا بإيقاف شيء ما في 8.x فسيكون تحذيرًا أصفر اللون لبقية 8.x ، وتحذير أحمر لكل 9.x ، وستتم إزالته في 10.x.

شكرا.

نسخdstufft الصورة تعليق من https://github.com/pypa/pip/pull/3194#issuecomment -152357835 هنا، لأنه هو أفضل ملخص للوضع:

أعتقد أن tl ؛ dr هو أنني أعتقد تمامًا أننا بحاجة إلى إصلاح السلوك "الافتراضي" ، فنحن بحاجة فقط إلى الاستقرار على التنفيذ المحدد لإصلاحه:

1. حافظ على تثبيت UX be pip - قم بترقية وتغيير الافتراضي.
2. انقل UX إلى ترقية النقطة باستخدام الإعداد الافتراضي "الصحيح" وأضف علامة - متتابعة.
3. انقل UX إلى نقطة التثبيت ، وأزل الترقية ، وأضف علامة - متتالية.

2 ج:

(1) لديه UX جيد ، يمكن القيام به الآن
(2) تجربة مستخدم أسوأ قليلاً (بها install و upgrade ) ، يمكن إجراؤها الآن
(3) ثاني أفضل تجربة مستخدم ، يمكن تغيير pip install الآن ، وإزالة --upgrade ستتم فقط في 10.0 (تم إهمالها في 8.0 و 9.0).

لا أفهم سبب كون مشكلة التوافق المتخلف (والتي يجب أن تكون ثانوية في كلتا الحالتين) لـ (1) ستكون أسوأ من (3). لذا (1) يبدو أفضل. إذا كان bw التوافق مصدر قلق حقيقي ، فاختر (2).

على أي حال ، حان الوقت لنسميها ليلة.

أعتقد أن الفرق بين (3) و (1) يعود إلى ما إذا كنا نعتقد أن التثبيت أو الترقية هي العملية الأكثر شيوعًا التي يريدها الناس - إذا كان الأمر كذلك ، فمن المحتمل أن يكون الأمر القصير كما في (3) هو الأفضل. إنها ليست مشكلة كبيرة في كلتا الحالتين.

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

أنا لست مرتبطًا على الإطلاق بالتهجئة "الحثيثة" ، لكن التكرار العودي ليس له معنى على أنه الكلمة الرئيسية للتبديل بين تشغيل وإيقاف الترقيات. أعتقد أنه يمكننا استخدام --upgrade-non-recursive (افتراضيًا مستقبليًا) ، --upgrade-recursive ، --upgrade-none أو نحو ذلك ، لكنه لا يزال يبرز السلوك التكراري المربك (لن يكون لدي أي فكرة عن --upgrade-non-recursive يعني --upgrade-none يبدو مضللاً وكأنه سيتأكد من عدم ترقية أي حزم حتى إذا لزم الأمر للحفاظ على الذات- التناسق.

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

--upgrade-non-recursive (المستقبل الافتراضي) ...

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

أعتقد أن الفرق بين (3) و (1) يعود إلى ما إذا كنا نعتقد أن التثبيت أو الترقية هي العملية الأكثر شيوعًا التي يريدها الناس

أتوقع "تثبيت". على الأقل أعلم أنني أقوم فقط بترقية الحزم التي أستخدمها بكثرة عن قصد ، ولكن في كل مرة أرى شيئًا مثيرًا للاهتمام / مفيدًا ، يكون الأمر على بعد pip install pkgname .

(لا يعني ذلك أنني مستخدم عادي ، لذلك قد تكون توقعاتي خاطئة)

أعتقد أنني سأؤيد:

• لا يوجد pip upgrade يمكن أن يكون اسمًا مستعارًا لـ pip install
• لا يتغير السلوك pip install (بدون الخيار --upgrade* )
• سيحاول pip install --some_name فقط ترقية الحزم المحددة في سطر الأوامر وليس تبعياتها
• pip install --some_other_name للإبقاء على سلوك --upgrade القديم متاحًا

ثم هناك خياران:

• لا نحتاج / نريد مسار إهمال ، إذن يمكن أن يكون --some_name --upgrade و --some_other_name يمكن أن يكون أي شيء يبدو أفضل
• نحتاج إلى مسار إهمال ، ثم يعطي --upgrade في النقطة 8 تحذيرًا يقول إنه مهمل ويجب علينا استخدام --some_other_name للاحتفاظ بالسلوك القديم أو بالأحرى التبديل إلى --some_name أكثر أمانًا لترقية الحزم المحددة وتبعياتها فقط إذا لزم الأمر.

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

يبدو لي أن الحل "الأفضل" الواضح هو الاحتفاظ بـ pip install كأمر ، وتغيير سلوك --upgrade لعدم ترقية التبعيات. المشكلة الحقيقية الوحيدة هي التوافق مع الإصدارات السابقة ، ولكن هل كان لدينا _ أي مستخدمين يجادلون بأنهم يعتمدون على السلوك الحالي؟

أنا شخصياً أميل إلى طريقة العرض "Go for it، and to check with back التوافق". يمكنني أن أزعم أن السلوك الحالي هو في الواقع خطأ ، وهذا التغيير سيكون إصلاحًا للخلل. لكنني أعتقد أنه في مرحلة ما نحتاج إلى أن نكون قادرين على القول بأننا وصلنا إلى نقطة جيدة ، وسنأخذ نظرة أكثر صرامة حول التوافق مع الإصدارات السابقة. لا أعتقد أننا في هذه المرحلة بعد ، ولكن قد نحتاج إلى البدء في إخبار المجتمع بما نشعر أنه لا يزال يتعين علينا القيام به من أجل الوصول إلى هذه النقطة.

لا تزال هناك حاجة (IMO) لنوع من الأوامر pip install --upgrade :all: لترقية جميع الحزم المثبتة. لكن هذه وظيفة جديدة ، لذا فهي ليست ذات صلة هنا.

يعتبر السلوك الحالي مفيدًا ، خاصة بالنسبة لمشاريع مثل Pyramid التي ليست مشروعًا واحدًا ولكنها في الواقع مجموعة من المشاريع. سيكون من المفيد أن تكون قادرًا على القيام بشيء مثل pip install --upgrade-recursive Pyramid لترقية Pyramid وجميع تبعياته إلى أحدث إصدار. إن إزالة الشيء التكراري معًا يعني أنه يتعين علي إما تتبع جميع التبعيات يدويًا والقيام بـ pip install --upgrade Pyramid dep1 dep2 dep3 dep4 (مع شجرة التبعية بأكملها) أو أحتاج إلى عمل افتراضي pip install --upgrade :all: وربما الترقية أكثر أشياء مما أريد بالفعل ترقيته. في # 3194 ، ذكر مستخدم واحد على الأقل أنه يرغب في أن يكون السلوك الحالي متاحًا عبر علامة لأنه مفيد في بعض الحالات.

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

تعجبني فكرة الأمر _new_ pip upgrade [--recursive] كما في # 3194 (وإيقاف install --upgrade )

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

أنا أميل إلى طريقة العرض "Go for it، and to check with back التوافق"

أنا لست:) على الأقل للمنطق الأساسي مثل هذا.

جعله كذلك ، يقوم تثبيت النقطة ضمنيًا بإجراء ترقية "بسيطة"

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

qwcode لا أعرف ، لا أعتقد أنه سيكون على ما يرام. المشكلة الرئيسية في pip upgrade هي إما أنك تزيل الطريقة التي يقول بها الأشخاص "أعطني أحدث إصدار من هذا بغض النظر عما إذا كان مثبتًا أم لا" أو أن لديك أمرين يقومان بنفس الشيء تقريبًا ( pip install و pip upgrade ). قد يكون هناك بعض الانقطاع على المدى القصير ، لكنني قلق بعض الشيء بشأن النموذج العقلي الفعلي البالغ pip upgrade لأنني أستطيع أن أرى أشخاصًا ينتشرون على نطاق واسع يستبدلون تعليمات التثبيت الخاصة بهم من pip install foo إلى pip upgrade foo (لكن لماذا أقوم بترقية شيء لم أقم بتثبيته بالفعل ؟!).

إيه ، أعتقد أنه سيكون على ما يرام أعني.

انتشار واسع محل إرشادات التثبيت الخاصة بهم من pip install foo إلى pip upgrade foo

roger ، لهذا السبب أعتقد أن upgrade يجب أن يقوم بالترقية فقط. أما بالنسبة لـ "turd" --fill-in-missing ، فأنا لست عالقًا في ذلك ، لذا لا تأخذني لأعني أنه لا بد لي من الحصول على ذلك ، ولكن انظر أدناه.

"أعطني أحدث إصدار من هذا بغض النظر عما إذا كان مثبتًا أم لا"

• إذا لم يكن لدي FOO ، فأنا pip install FOO وأحصل على أحدث إصدار.
• إذا كان لدي FOO ، ثم pip upgrade FOO وحصلت على أحدث إصدار.

أعتقد أننا نتحدث عن حالتين:

1. لا أعرف ما إذا كان لديّ FOO ، وأريد _one_ الأمر للحصول على أحدث FOO ، سواء كان لديّ أم لا.
2. أريد _one_ الأمر للحصول على أحدث FOO و BAR . لدي FOO مثبتًا ، لكن ليس BAR .

هل نحن مدينون للمستخدمين بأمر _one_ لهذه؟ أفضل البساطة والوضوح في الأوامر على إعطاء الاختصارات للناس. ولكن إذا طلب المستخدمون ذلك ، فهذا هو المكان الذي يأتي فيه شيء مثل --fill-in-missing .

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

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

• ملائم:
  
  
  
  • ينفذ apt install <pkg> "تثبيتًا" - إما للترقيات أو التثبيت بناءً على ما إذا كان مثبتًا بالفعل أم لا.
  
  
  • apt upgrade بترقية كافة الحزم المثبتة
  
  
  • apt upgrade <pkg> غير موجود ، الطريقة الوحيدة لترقية حزمة واحدة هي apt install <pkg> (والتي تقبل أيضًا أنواعًا مختلفة من محددات الإصدار)
  
  
• يم:
  
  
  
  • ينفذ yum install <pkg> "تثبيتًا"
  
  
  • yum upgrade بترقية كافة الحزم المثبتة
  
  
  • yum upgrade <pkg> بترقية قائمة الحزم المحددة. لا أعرف ماذا سيحدث إذا لم يتم تثبيتها بالفعل.
  
  
• البيرة:
  
  
  
  • ينفذ brew install <pkg> "تثبيتًا"
  
  
  • brew upgrade بترقية جميع الحزم
  
  
  • brew upgrade <pkg> بترقية قائمة الحزم المحددة. لا أعرف ماذا سيحدث إذا لم يتم تثبيتها بالفعل.
  
  

لذا فإن استخدام التثبيت للترقيات هو في الواقع ما تفعله أدوات التوزيع :-). لا يعني ذلك أننا مضطرون إلى ذلك أيضًا ؛ مجرد نقطة بيانات.

لا أعرف ما إذا كان لدي FOO ، وأريد أمرًا واحدًا للحصول على أحدث FOO ، سواء كان لدي أم لا.

أعتقد أن حالة الاستخدام الأكثر إلحاحًا لهذا الأمر هي التوثيق. مثال: مستندات django التي قمت بربطها في سلسلة المحادثات الأخرى والتي ترشد الأشخاص إلى تشغيل pip install -U <some package> . لا تريد أن تطلب من الأشخاص "تشغيل pip install <pkg> إلا إذا كنت قد قمت بالفعل بتثبيته ، فقم بتشغيل pip upgrade <pkg> " لأن هذه الطريقة مربكة للغاية بالنسبة للمبتدئين ، ولكن إذا لم يكن install " إن مجرد إخبار الأشخاص بتشغيل pip install <pkg> سيؤدي أيضًا إلى حدوث ارتباك حيث يبدأ الأشخاص في العمل من خلال البرنامج التعليمي الخاص بك مع تثبيت إصدار قديم ومن ثم ليس لديهم أي فكرة عن سبب عدم عمل الأشياء بشكل صحيح ويلومونك على ذلك. لذلك أنت بالتأكيد بحاجة إلى أمر "تثبيت" واحد ، ويجب أن يكون بسيطًا وواضحًا لتضمينه في المستندات.

متابعة سلوك Homebrew للمقارنة: brew upgrade يفشل إذا حاولت تثبيت حزمة غير مثبتة:

$ brew upgrade git
Error: No such file or directory - /usr/local/Cellar/git

أيضًا ، يتغير سلوك brew upgrade (انظر المناقشة هنا ) ؛ في إصدار مستقبلي ، سوف يتحول إلى طلب --all لترقية جميع حزم التثبيت المثبتة.

نقطة إيضاح

كنت أعلم أن شخصًا ما سوف يلتقط هذا. :)
كنت على وشك الرد على نفسي. كنت أركز على الترقيات.

ترقية yum[...] لا أعرف ماذا سيحدث إذا لم تكن مثبتة بالفعل.

لا تفعل أي شيء

يم التثبيتينفذ "تثبيت"

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

مستندات django التي ربطتها في الخيط الآخر

للتوضيح ، لم يكونوا مستندات Django الفعلية. مستندات Django تقول pip install Django (https://docs.djangoproject.com/en/1.8/topics/install/)

أعتقد أنه أمر سيئ حقًا ، نظرًا للطريقة التي يعمل بها -U حاليًا ، لتعود الناس على استخدام install -U .

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

سوف يحدث ارتباكًا حيث يبدأ الأشخاص في العمل من خلال البرنامج التعليمي الخاص بك
مع إصدار قديم [...] لذا فأنت بالتأكيد بحاجة إلى أمر "تثبيت" واحد

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

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

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

أعتقد أن البرامج التعليمية يجب أن تطلب من الأشخاص "التثبيت"

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

النقطة الأساسية هنا هي أن PyPI ليس مستودعًا "منظمًا" ، مثل التوزيعات المستودعات. يمكنك أن تطمئن إلى حد ما أن "التثبيت" آمن من مستودع توزيعة افتراضي ... أنت لا تعرف ذلك مع PyPI. كل ترقية هي مقامرة إلى حد ما. "التثبيت" ، كما هو ، هو محافظ.

ضع في اعتبارك أن جعل pip install يتصرف مثل "تثبيت" بدون إصلاح # 988 سيؤدي إلى كسر الأشياء.

ضع في اعتبارك مكان تثبيت A و B و A يتطلب B<2 . الآن أذهب إلى تشغيل pip install B ، والذي يعمل على زيادة B إلى الإصدار 3 أو أيًا كان (بسبب عدم مراعاة القيود المثبتة) ، والآن تم تعطيل بيئتي.

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

من التافه الخروج بمثل هذه السيناريوهات. مثال (لم يتم تكوينه للأسف): حاليًا statsmodels تم كسره بواسطة أحدث pandas (0.17.0). أنا مستخدم لكليهما. لدي مجموعة من إصدارات Python مثبتة و venvs موجودة. لذلك أعلم أنه بالنسبة لأي Python / venv ، أود تثبيت pandas فقط إذا لم يكن موجودًا بعد. إذا كان الأمر كذلك ، فمن المحتمل أن يكون لديّ أيضًا statsmodels وبعد ذلك ستؤدي كلمة "upinstall" إلى كسرها.

rgommers Hmm ، لذلك أنت متأكد تمامًا من أنه ليس لديك 0.17.0 في بيئة افتراضية في أي مكان؟ أعتقد أنه يمكن أن يحدث على الرغم من أنني أعتقد أنني ربما سأفعل ذلك من خلال القيام بـ pip install pandas!=0.17.0 أو pip install pandas<0.17 لكنني أعتقد أنه ليس من غير المعقول تمامًا الاعتماد على ما قمت بتثبيته بالفعل.

حسنًا ، أنت متأكد تمامًا من أنه ليس لديك 0.17.0 من الباندا في بيئة افتراضية في أي مكان؟

هذا ليس ما قلت. لدي venv مع الباندا 0.17.0 ، واحد فقط لا أملك فيه نماذج statsmodels. pip install pandas<0.17 سيقوم بالمهمة ، لكن لم يخطر ببالي استخدام ذلك (بشكل أساسي لأنني لم أكن بحاجة إلى ذلك ، الأمر install يعمل لهذا الغرض).

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

+1

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

rgommers ربما فعلوا القرار؟ https://pip.pypa.io/en/stable/user_guide/#only -if-needed-recursive-Upgrade

rgommers ربما فعلوا القرار؟ https://pip.pypa.io/en/stable/user_guide/#only -if-needed-recursive-Upgrade

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

rgommers من الرابط الذي نشرته أعلاه قرأت أن المطورين سيقومون بإجراء ترقية. ولا تخطط لإضافة خيار "فقط عند الحاجة" لتثبيت الأمر لأنهم لم ينشئوا مصطلحًا لهذا الخيار واستخدموا الوصف فقط بين علامات الاقتباس. إذن من تعليقك (أو تعليق dstuff) في 30 أكتوبر - هو: _2. انقل UX إلى ترقية Pip باستخدام الإعداد الافتراضي "الصحيح" ..._ (راجع للشغل أنا أفضل هذا)
أنا متأكد من أنك كنت تفكر أكثر في هذا الموضوع وترى أشياء أكثر دقة مما أفعله. لذا يرجى كتابة ما (إذا كنت تعتقد أن شيئًا ما) لا يزال مفتوحًا. إذا كنت تقصد أنه قد يكون من الجيد أن يكتب المطورون هنا قرارهم صراحة وأن يغلقوا هذه المشكلة في النهاية - أوافق.

بالمناسبة. يمكن أن يكون الموقف أقل إشكالية بكثير إذا كان لدينا شيء مثل

pip freeze > checkpoint.txt
pip checkout checkpoint.txt

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

pip checkout git+https://github.com/somebody_trusted/pip_distro4ubuntu<strong i="12">@bleeding_egde_branch</strong>
#or
pip checkout git+https://github.com/somebody_trusted/pip_distro4ubuntu<strong i="13">@stable</strong>

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

(من المفيد أيضًا الاطلاع على هذا الموضوع: https://pypi.python.org/pypi/peep)

@ Liso77 الأمر بسيط: لم تنته المناقشة حول هذه المسألة. هناك علاقات عامة تنتظر تنفيذ الأمر upgrade (gh-3194) ، لكن مطوري النقطة (على الأقل qwcode و dstufft ، وربما أيضًا xavfernandez وpfmoore) يحتاجون إلى تحديد ما إذا كان هذا ما يريدون ، أو يريدون تغيير سلوك pip install بدلاً من ذلك. حتى يحدث ذلك ، لن يتغير شيء.

+1

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

رمي بآرائي الشخصية:

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

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

هذا يترك لنا upgrade --install (أقصر من --install-missing ) و install --upgrade . معنويًا ، "الترقية إلى الأحدث [والتثبيت إذا لم يكن موجودًا]" و "تثبيت الأحدث [أو الترقية إلى الأحدث إذا كانت موجودة بالفعل]". ليس هناك فرق كبير هنا المنظمة البحرية الدولية. install --upgrade هو الإصدار الموجود بالفعل ويمكن التعرف عليه ، ولكنه غير متوافق مع الإصدارات السابقة.
إليك أمر آخر للمزيج: أمر جديد باسم install-upgrade (أو upstall ؟) ، حيث لا يحصل التثبيت أو الترقية على خيار "القيام بالآخر أيضًا" ولكن يتم تقديم أمر جديد باستخدام دلالات واضحة في موقع مهم: اسم الأمر نفسه. سيكون هذا هو المفضل لدي.

TL ؛ DR : تقديم upgrade و upgrade-install ، وإيقاف install --upgrade . كل الوظائف مع دلالات واضحة.
أضف رسائل أو يطلب اختياريًا تثبيت الأوامر وترقيتها إذا فشلت عملياتها بسبب وجود حزمة بالفعل أو غير موجودة.

فعل هذا مرة أخرى يدويًا هذا الصباح. هل هناك أي أخبار عن هذه الميزة؟

+1

+1

+1

الجميع ، يرجى استخدام رد فعل ممتاز على OP والتوقف عن إرسال بريد عشوائي إلى البريد الوارد للجميع.

نظرًا لأن النقطة لها نموذج ضمان جودة مختلف عن توزيعات لينكس ، فأنا متأكد تمامًا من أن الترقية العشوائية لجميع الأوامر هي مجرد كسر في الإعداد

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

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

الجميع ، يرجى استخدام رد فعل ممتاز على OP والتوقف عن إرسال بريد عشوائي إلى البريد الوارد للجميع.

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

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

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

نقطة انطلاق للتنفيذ

اعتقدت أن هذا هو الغرض من https://github.com/pypa/pip/pull/3194؟ من هناك ، انجرف النقاش إلى عدة بدائل لتسمية الأوامر والسلوك دون إجماع من قبل المطورين الأساسيين. هل سيساعد على تنفيذ العديد من هذه البدائل؟ أم أن https://github.com/pypa/pip/pull/3194 يحتاج فقط إلى التحديث؟

sfriesel لقد فاتك "وأنت على استعداد لمتابعة ذلك من خلال". يبدو أن الشخص الذي قام بهذه العلاقات العامة قد نفد الوقت أو الاهتمام (مشكلة شائعة). من المحتمل أن تكون الخطوة التالية في هذا الأمر إما لـ OP أو أي شخص آخر يرغب في تولي ملكية PR ، لكتابة ملخص بأسلوب PEP للوظيفة الحالية ، ما هي القضايا المعلقة المختلفة ، ما يقترحه على أنه حل لهذه القضايا المختلفة ، ودعوة للتعليقات لإعادة بدء المناقشة. إذا كان النقاش كبيرًا جدًا على جيثب ، فربما يحتاج إلى أخذ وثيقته إلى distutils-sig لمزيد من المدخلات. إذا لم يتمكن من اتخاذ قرار بشأن حل يرضي عنه بشأن مختلف القضايا ، أو لم يتمكن من الحصول على إجماع من المناقشة ، فعندئذ نعم ، ربما يكون رقم 3194 قد مات (حتى يعيد شخص آخر المشكلة مرة أخرى ، وعند هذه النقطة أكون قد ماتت. أتمنى أن يدمجوا جميع الأعمال المنجزة في علاقاتهم العامة الجديدة).

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

pfmoore أوافق تمامًا.

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

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

ليس لدى pypi قاعدة بيانات لإصدارات الحزم

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

سيتم حل ذلك عن طريق PEP 426 ، من بين أشياء أخرى ، لكنني لا أعرف ما هو وضع هذا PEP.

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

لاحظ أننا لا نحتاج في الواقع إلى أي نوع من رد "أريد هذا" من الناس

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

سأكون ممتنًا إذا امتنع الأشخاص عن إرسال اختبار ping لهذه المشكلة ما لم يكن لديهم رمز صالح للعمل

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

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

آه ، لم أدرك أن القيام بذلك أدى إلى تفادي الإشعارات. اجل انها فكرة جيدة.

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

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

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

/ سم مكعبqwcodedstufftpfmoorexavfernandez

إليك رابط كتابتي: https://gist.github.com/pradyunsg/a5abeac4af90fbdc54bb266c32c0d2d8

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

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

تحذير: ______________________________________ تعليق طويل في المستقبل

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

FWIW ، فعل git شيئًا مشابهًا لما نناقشه حول --upgrade ، حيث قام بتغيير السلوك الافتراضي git push في عام 2014. link

إذا كان هناك اهتمام بتغيير سلوك pip install --upgrade ، فإليك اقتراح بذر (يرجى الرجوع إلى هذا P1) لتلك المناقشة:

• بدءًا من الإصدار الرئيسي التالي (9.0) ، يطبع pip install --upgrade تحذيرًا:

""
تحذير: ستتوقف النقطة عن ترقية التبعيات إلى أحدثها
الإصدار دون قيد أو شرط افتراضيًا بدء الإصدار 11.0.

للحفاظ على السلوك الحالي بعد تغيير السلوك الافتراضي ، إلى
تمرير أمر التثبيت --upgrade-strategy eager .

لبدء استخدام السلوك الجديد على الفور ، إلى أمر التثبيت
تمرير --upgrade-strategy non-eager .

لإخماد هذه الرسالة ،.

لمزيد من التفاصيل ، اقرأ.
""

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

• يمكن أن تستخدم الرسالة عملية تنظيف.
• يمكن أن يكون الخيار حتى علامتين ، --upgrade-eager و --upgrade-non-eager أو شيء من هذا القبيل. هذا هو زواج الدرّاجات ، أي الخطوة الأخيرة.
  
  
  
  • ما لم يحدث شيء جذري ، في الإصدار 11.0 ، pip install --upgrade يغير السلوك ليكون غير متلهف عند ترقية التبعيات.
  
  

تحرير: أضع 3 دورات إصدار رئيسية للتغيير ، فقط لإعطاء المزيد من الوقت للأشخاص للتبديل. قد يكون غير ضروري. ربما ، تحذيرات طباعة إصدار رئيسي واحد وإجراء التغيير التالي كافٍ؟

dstufft جاء

إذا كان أمر الترقية هو الطريق إلى الأمام ، فإليك اقتراح بذر لإعادة بدء تلك المناقشة (راجع هذا بـ P2 ، إذا كنت تريد):

1. نسخ pip upgrade عبر معظم الخيارات والسلوك من pip install .
2. ستتم إضافة العلم --dry-run إلى install و upgrade للأوامر التي تطبع النقطة التي ستحاولها إذا تم تشغيلها بالفعل.
3. pip install <out_of_date_pkg> لا يغير السلوك.
4. pip upgrade <not_installed_pkg> سيفشل.
5. pip upgrade <up_to_date_pkg> لن يفعل شيئًا ، قل لماذا لم يفعل شيئًا والخروج برمز خروج صفري.
6. سيجري pip upgrade <out_of_date_pkg> ترقية متكررة غير حريصة.
   
   
   
   • : white_check_mark: افتراضي للترقية العودية غير النهمة
   
   
7. pip upgrade --eager package سيتصرف مثل pip install --upgrade .
   
   
   
   • : white_check_mark: السماح بالاشتراك في السلوك الحالي
   
   
8. pip install --upgrade يطبع RemovedInPip10Warning .
   لأنه سيتم إزالته.

بالإضافة إلى ذلك ، ما هي أفكارك حول:

1. جعل أمر الترقية تفاعلياً؟ (شيء مثل ما يفعله apt-get)
   
   
   
   • جعل pip install <pkg> يتصرف مثل ieup install مدير حزمة نظام التشغيل؟
   
   
2. وجود --only-binary افتراضيًا في أمر الترقية الجديد؟
   
   
   
   • إذا كان الأمر جيدًا ، فماذا عن إضافة --only-source و --no-source في أمر الترقية؟
   
   
3. إضافة خيار "تعليق" تحديث الحزمة؟ IMO ، هذا مطلب upgrade-all .
4. هل يعقل التفريق بين هذه الحالات ، أي تتطلب CLI مختلفة؟
   
   
   
   • التثبيت: غير مثبت -> محدث
   
   
   • ترقية: قديمة -> محدثة
   
   
   • التثبيت: {not-install، out-date} -> محدث
   
   

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

ربما النوم فوق هذا قد يساعد.

أنا شخصياً لا أرى قيمة كبيرة في الحفاظ على الاتساق مع سلوك قليل إذا كان أي شخص سعيدًا به. أتساءل عما إذا كان الحصول على واحد من أجل Python 2 (احتضان الاستقرار) والآخر ل Python 3 (احتضان التغيير) سيكون أفضل أم أسوأ.

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

أتساءل عما إذا كان الحصول على واحد من أجل Python 2 (احتضان الاستقرار) والآخر ل Python 3 (احتضان التغيير) سيكون أفضل أم أسوأ.

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

OTOH ، أرى ما تعتقده حول مدى قبول التوافق مع الإصدارات السابقة ...

يبدو أن التحذير في النقطة 9 ، بالإضافة إلى الخيارات الإضافية لتعديل سلوك pip install --upgrade ، --eager/non-eager (أو أي اسم آخر) يبدو جيدًا بالنسبة لي.

صدم. إشعار آخر للجميع.

pfmooredstufftqwcode أنا لا أريد أن أكون فضولي ولكن هل يمكن أن يرجى اتخاذ بعض الوقت لذلك، خلال عطلة نهاية الأسبوع أو الأسبوع القادم؟

حسنًا ، لذا تعليقاتي:

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

إعادة أسئلتك الإضافية:

1. أنا -1 على جعل الأمر تفاعليًا. ما لم تكن هناك مشكلة محددة يحتاج المستخدم إلى اتخاذ قرار بشأنها ، على غرار "هذه النتيجة لما طلبته هي شيء لم تكن على دراية به بوضوح ، ويمكن أن تكون مشكلة - هل تريد المتابعة" إذن ضوضاء عديمة الفائدة. أنا ضد المطالبات "هل أنت متأكد" بشكل عام. إذا كان لديك اقتراح محدد لموجه تعتقد أنه يستحق الإضافة ، فلا تتردد في السؤال مرة أخرى مع التفاصيل المضمنة.
2. لا يجب أن نجعل الترقيات مختلفة عن عمليات التثبيت ، لذلك لا يكون --only-binary افتراضيًا. لاستخدامي الشخصي ، ربما أرغب دائمًا في الحصول على pip upgrade --only-binary في المقام الأول ، لكنني أريد أن يكون صريحًا.
3. لست متأكدًا مما تقصده بشأن "الاحتفاظ" بالتحديثات. الرجاء التوضيح. ولكن كرد عام ، أقول لا تهتم في المقام الأول ، فلنحافظ على العلاقات العامة الأولية خالية من "الإضافات الاختيارية" - يمكن إضافتها لاحقًا.
4. أليس هذا هو الموضوع الرئيسي للنقاش حول النقاشات المختلفة لهذه الميزة؟ كبداية ، ألا يؤثر ذلك على السؤال الأساسي install --upgrade مقابل upgrade ؟ لا أذكر أنه كان هناك حل لهذا السؤال ، لذلك أنا مندهش قليلاً أنك تتوقع إجابة "بسيطة" على هذا السؤال؟ أنا بالتأكيد ليس لدي إجابة جيدة.

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

أعلم أنه من الصعب كتابة العلاقات العامة ، ومن المحبط أن يبدو أنها تتورط في المناقشات والأسئلة ، ولكن في النهاية ، أعتقد أنه سيتعين على شخص ما كتابة واحدة ، ووضعها هناك على أنها "هذا هو الحل أقترح - هل من تعليقات؟ "

لا يجب أن نجعل الترقيات مختلفة عن عمليات التثبيت [snip] ، ربما سأريد دائمًا pip upgrade --only-binary في المقام الأول ، لكنني أريد أن يكون واضحًا.

إذا كنت ترغب دائمًا في شيء ما ، فيجب أن يكون الخيار الافتراضي ¹ . لكنني أعتقد أن الحفاظ على التناسق عبر install upgrade وأمر محتمل

لست متأكدًا مما تقصده بشأن "الاحتفاظ" بالتحديثات.

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

ملاحظة للنفس: apt-mark مفاهيم للنقطة

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

نفس الشيء.

أليس هذا هو الموضوع الرئيسي للنقاش حول النقاشات المختلفة لهذه الميزة؟

بالضبط لماذا أردت أن أعرف ما رأيكم يا رفاق.

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

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

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

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

اختر أيهما تشعر أنه الخيار الأفضل ، وقم بتنفيذه وسنرى كيف ستسير الأمور من هناك.
[قص]
أعتقد أنه سيتعين على شخص ما كتابة واحدة [العلاقات العامة] ، ووضعها هناك على النحو التالي "هذا هو الحل الذي أقترحه - هل من تعليقات؟"

كنت أفكر على غرار "لنكتشف بالضبط ما نريده أولاً" ثم نمضي قدمًا وننفذ ذلك.

¹ ما لم يكسر عالم شخص آخر

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

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

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

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

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

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

لا يجب أن نجعل الترقيات مختلفة عن عمليات التثبيت [snip] ، ربما سأريد دائمًا ترقية النقطة - فقط ثنائية في المقام الأول ، لكنني أريد أن يكون واضحًا.

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

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

توضيح: كلمة "أنت" في تعليقي كانت تشير إلى المستخدمين النهائيين (جمع واحد) ، pfmoore هي واحدة في هذه الحالة المحددة. أنا حقا كان يجب أن أستخدم بعض الكلمات الأخرى.

بعض الأفكار حول استراتيجيات الترقية. رأي شخصي ، كل هذا بالطبع :-)

افترض أنني أفعل pip upgrade foo

1. إذا لم يكن لدي حاليًا foo مثبتًا ، أتوقع حدوث خطأ. بالنسبة لي ، "التثبيت" و "الترقية" هما نشاطان منفصلان لا أريد دمجهما.
2. إذا لم يكن هناك إصدار متاح أحدث مما هو مثبت حاليًا (انظر أدناه re --only-binary ) فأنا أتوقع إشعارًا بأنه لا يوجد شيء يمكن القيام به.
3. بخلاف ذلك ، أتوقع ترقية foo إلى أحدث إصدار. هذا ما طلبته ، لذا يجب أن يحدث.
   
   
   
   • لست مقتنعًا بأن إضافة القيود أمر منطقي. ماذا يعني pip upgrade foo>1.0 إذا كان لدي 1.1 مثبتًا ولكن 1.2 متاح؟ إنها ليست ترقية إذا تركت 1.1 هناك ، ولكن إذا تمت ترقيتها إلى 1.2 ، فستكون هي نفسها pip upgrade foo . ربما يمكنك أن تنسب معنى إلى شيء مثل pip upgrade foo<2.0 لكن IMO سيكون حالة غير عادية للغاية ، ولا يستحق التعقيد. لذلك لنفترض أن pip upgrade يأخذ فقط قائمة بأسماء الحزم (على عكس المتطلبات).
   
   
   • وبالمثل ، لا أعرف كيف أفسر pip upgrade <path_to_archive/wheel> . لنفترض أنه غير مسموح به في المقام الأول.
   
   
4. قد أرغب أو لا أرغب في السماح للنقطة بمحاولة البناء من المصدر (يجب أن يكون هذا قرار المستخدم ، حيث لا تستطيع النقطة معرفة ما إذا كان البناء من المصدر سيعمل أم لا ، وليس لديها القدرة على المحاولة مرة أخرى باستخدام إصدار مختلف إذا كان فشل بناء المصدر). لذلك يجب أن يكون --only-binary خيارًا للمستخدم ، وإذا تم تحديده ، فهذا يعني أن النقطة يجب أن تتجاهل توزيع المصدر عند العمل على "ما هو متاح". (يمكننا بالطبع اختيار الثنائيات فقط ، ولدينا خيار --allow-source ، ولكن في كلتا الحالتين ، يجب أن يتطابق install upgrade مع install في هذا الصدد).

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

• القاعدة الأساسية في ذهني هي أنه لا يجب علينا فعل أي شيء حيال التبعيات ، ما لم نقم بترقية الحزمة المحددة من قبل المستخدم. إذن هذه هي نقطة البداية. إذا لم تتم ترقية الهدف ، فلا تنظر حتى إلى التبعيات. أبدا.
• وجهة نظري هي أن _all_ التبعيات يجب أن يتم التعامل معها بنفس الطريقة - سواء كانت تبعيات مباشرة أو غير مباشرة للحزمة المحددة من قبل المستخدم ، فهي غير ذات صلة. لا أعتقد أن هذا مثير للجدل.
• يجب أن يكون الافتراض الأساسي هنا هو أن المستخدم لا يعرف ما هي قائمة التبعيات. بعد كل شيء ، فإن الهدف من وجود التبعيات الضمنية هو أنه لا يتعين على المستخدم إدارتها. لذا فإن أي حل يحتاج إلى أن يعرفه المستخدم صراحةً عن التبعية هو معيب ، من وجهة نظري (ما لم يفشل أمر ما برسالة حول تبعية معينة ، وفي هذه الحالة قد يعيد المستخدم تشغيل تلك التبعية المحددة في أحد الخيارات - لكن يجب علينا ذلك أن تتطلع إلى العمل لأول مرة في أكبر عدد ممكن من الحالات ، لذلك لا ينبغي اعتبار هذا أمرًا عاديًا).
• أود أن أقول أنه بشكل افتراضي ، يجب أن يكون الأسلوب هو ترقية التبعيات التي _have_ ليتم ترقيتها لتلبية القيود الجديدة. هناك مشكلة سيئة تكمن هنا ، حيث قد تتغير القيود اعتمادًا على ما يتم ترقيته. ولكن ما إذا كنا نقوم بحل كامل لهذه المشكلة ، أو نحاول ببساطة حل "أفضل جهد" ليس بهذه الأهمية (أشك في أن الرسوم البيانية التبعية المعقدة ذات القيود المتضاربة شائعة في الحياة الواقعية). النقطة المهمة هي المبدأ ، أننا لا نقوم بترقية أي شيء لم يطلب المستخدم ترقيته ، إلا إذا اضطررنا لذلك.
• قد يكون من المفيد وجود علامة تقول "ترقية كل شيء إلى أحدث إصدار" (للتوافق مع الإصدارات السابقة ، على الأقل). والأفضل من ذلك هو أن يكون لديك أدوات (من المحتمل أن تكون خارجية) تحلل خيارات الترقية وتقدم تقارير عنها. ثم يمكن للمستخدمين أن يقرروا بأنفسهم. لكني لا أعرف أنني سأرى حاجة على الإطلاق لأي من هذين الخيارين بنفسي.
• بدلاً من خيار "الترقية الحثيثة" ، من المرجح أن أرغب في الحصول على أمر upgrade-all (أو upgrade --all إذا أردنا الاحتفاظ بأمر واحد). يجب أن يكون هذا مطابقًا لغويًا لـ upgrade مع كل حزمة مثبتة مدرجة في سطر الأوامر. بمجرد أن أقوم بإجراء ترقيات عمياء للحزم (عادة قد لا أعرف أو أوثق شجرة التبعية للحزم الخاصة بي) ربما أريد فقط "كل شيء". أكثر من ذلك إذا كنت أستخدم البيئات الافتراضية لعزل الأشياء.
• يظهر السؤال --only-binary مرة أخرى هنا. بالتأكيد إذا حدد المستخدم --only-binary للترقية الرئيسية ، فيجب افتراض أن التبعيات تعني --only-binary . ولكن حتى إذا سمح المستخدم بتثبيتات المصدر عند ترقية الحزمة الرئيسية ، فإن تقديم خطر الفشل الذي ينطوي عليه القيام بترقية مصدر تبعية يبدو غير معقول. لذلك أقترح أنه يجب علينا فقط التفكير في الثنائيات لترقية التبعيات ، ما لم يسمح المستخدم صراحةً بالمصدر. قد يعني ذلك الحاجة إلى خيار --allow-source dep1,dep2,... . أتوقع أن يكون هذا الاقتراح مثيرًا للجدل ، لكن ضع في اعتبارك حزمة Python الخالصة foo التي يتم توزيعها فقط في شكل المصدر ، وهذا يعتمد على numpy. لدينا foo 1.0 اعتمادًا على numpy> = 1.10 ، و foo 2.0 اعتمادًا على numpy> = 1.11. المستخدم لديه foo 1.0 ويريد الترقية. ليس لديهم الوسائل لبناء كتلة. يجب أن يسمحوا بترقيات المصدر لـ foo ، لكنهم لا يريدون إضاعة الوقت في محاولة إنشاء رقم 1.11 (أو الأسوأ من ذلك ، قد ينجح بناؤه ولكنه يعطي بنية غير محسّنة ، مما يكسر نظامهم). يمكنهم بالطبع تحديد --only-binary numpy لكنهم قد لا يدركون حتى أن foo يعتمد على numpy.

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

على حد علمي ، ستكون التحديات التالية هي تحديات التنفيذ:

1. من الصعب حل SAT الكامل. لا أعرف ما يكفي لفهم ما هي البدائل الأبسط ، وكيف تختلف عن محلل SAT. (حسنًا ، أعتقد أن الترقية الحثيثة بسيطة بما يكفي - ولهذا السبب هذا ما نفعله في الوقت الحالي). على وجه التحديد ، عندما نحصل على موقف نقوم فيه بترقية شيء ما ، فإن المبدأ البسيط "لا تقم بترقية أي شيء لست مضطرًا إليه" ينص على أنه لا ينبغي ترقيته.
2. لقد تساءلت عن أي شيء سوى قيود التبعية الأساسية. بمجرد أن ننخرط في الحدود العليا للإصدارات ، أو قوائم الإصدارات المسموح بها ، تصبح الأمور سيئة. لكن من الناحية الواقعية ، من المحتمل أن تكون مثل هذه الحالات نادرة جدًا (أود أن يقوم شخص ما بإجراء بحث حول معلومات التبعية الفعلية من PyPI - قد أحاول القيام بذلك ، لكنني أشك في أنني سأحصل على الوقت).
3. عندما يكون لدينا أهداف متعددة - pip upgrade a b c - هل نتعامل مع هذا على أنه 3 إجراءات منفصلة ، "ترقية a" ، ثم "ترقية b" ثم "ترقية c" ، أو هل ندمج الثلاثة في "مجمع" واحد إجراء بطريقة ما (لاحظ أنه لأنني أقترح معالجة تبعيات مختلفة عن الأهداف ، فهذا _ليس _ هو نفسه pip upgrade dummy حيث تعتمد الدمية على a و b و c ونفترض أنه تمت ترقية الدمية).

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

لذلك لدينا حاليًا عمليتان ، pip install و pip install --upgrade ، لكني أعتقد أن كلا الأمرين يفعل شيئًا لا يريد أحد حدوثه في الواقع.

بالنسبة إلى pip install ، نحصل على هذا النوع من السلوك الغريب حيث قد تحصل على أحدث إصدار (أو قد لا تحصل عليه!) بناءً على ما تم تثبيته بالفعل في نظامك. أعتقد أن هذا النوع من الغرابة يجعل استخدام النقطة أكثر صعوبة ، ولا أعتقد أنه منطقي تمامًا (ما هو الموقف الذي قد تهتم به لعدم الترقية ولكنك لا تزال ترغب في تثبيت الأحدث إذا لم يكن لديك بالفعل هو - هي؟). أعتقد أن حقيقة أن هذا الأمر لديه هذا السلوك الغريب ربما الأخير ربما ليس هو السبب في أننا نرى الكثير من الأشخاص يصلون إلى pip install ---upgrade كأمرهم الأساسي بدلاً من pip install .

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

ما أعتقد أنه يجب علينا القيام به هنا ، هو اكتشاف مسار لإجراء تثبيت النقطة ... يجب أن ينتهي تثبيت النقطة more consistent. In that I mean دائمًا بالحصول على أحدث إصدار مقبول (محددات معينة وعلامات التعديل مثل - فقط ثنائي ") بغض النظر عما تم تثبيته مسبقًا.

أعتقد أن إعطاء هذا الأمر نوعًا من السلوك --eager أو --recursive أو --upgrade-all-the-things سيكون أمرًا جيدًا.

لا أعتقد أن الأمر pip upgrade الذي يأخذ قائمة الحزم هو شيء يجب أن نفعله. أعتقد أنه إذا أضفنا مثل هذا الأمر ، فيجب استخدامه ببساطة لترقية كل شيء مثبت إلى أحدث الإصدارات (مع مراعاة معلومات سلسلة التبعية ، وكذلك المُعدِّلات مثل --only-binary ).

هاه؟ إذن ، pip install foo لا يفشل دائمًا إذا تم تثبيت foo؟ يبدو هذا خطأ بالنسبة لي ، كنت أتوقع أن أقول "مثبت بالفعل".

لست مهتمًا بفكرة أن يكون pip install "تثبيت أو ترقية". من الأفضل أن أكون صريحًا وكل ذلك.

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

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

ماذا تتوقع أن يفعل pip install foo-1.0-none-any.whl إذا كان foo 2.0 مثبتًا بالفعل؟ تخفيض؟ بصمت لا تفعل شيئا؟ أفضل رؤية خطأ "مثبت بالفعل" لطيفًا وبسيطًا بدلاً من مجموعة معقدة من القواعد التي أشك في أن يتذكرها الناس من الناحية العملية.

ليس لدي خبرة كبيرة مع مديري حزم Linux ، لذلك لا يمكنني التعليق على أوجه التشابه (أو غير ذلك) مع النقطة. لكنني لا أعتقد أنني أتوقع ترقية apt-get install foo ، لذا إذا قلت إنها كذلك ، يمكنني فقط الرد بأنني أجد هذا غريبًا أيضًا.

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

سؤال جانبي سريع حول هذا: ماذا عن "تأكيد تثبيت هذا الإصدار المحدد"؟

بغض النظر ، لدينا هذا السلوك اليوم.

pfmoore :

ما الذي تتوقعه من تثبيت النقطة foo-1.0-none-any.whl إذا كان foo 2.0 مثبتًا بالفعل؟ تخفيض؟ بصمت لا تفعل شيئا؟ أفضل رؤية خطأ "مثبت بالفعل" لطيفًا وبسيطًا بدلاً من مجموعة معقدة من القواعد التي أشك في أن يتذكرها الناس من الناحية العملية.

هاه ، التوقعات أشياء مفاجئة. أود أن أقول أنه من الواضح أنه في هذه الحالة يجب تخفيض النقطة. قال المستخدم صراحةً تمامًا إنه يريد أن يقوم Pip بتثبيت هذه العجلة المعينة ، لذلك يجب على Pip تثبيت تلك العجلة المعينة. لا يوجد شيء معقد في ذلك. لكن حالة "مسار / ملف التوزيع صريحًا" هي 536 - ربما يجب أن نبقي هذه المناقشة مركزة أكثر على ما يحدث إذا قال المستخدم "pip install foo" ، والذي ينتقل إلى فهرس الحزمة ويعثر على foo 2.0 ، عندما يكون foo 1.0 مثبتًا بالفعل.

أنا أتفق بشدة مع موقف دونالد هنا. إذا بدأنا من السؤال "ما الذي يجب أن يفعله pip install ؟" ، فيمكنني إذن أن أرى كيف يمكن للمرء أن يجادل في ذلك ، حسنًا ، يقول "تثبيت" في الاسم ، لذا يجب عليه فقط تثبيت الأشياء ، وعدم ترقيتها أبدًا ( حسنًا ، إلا عندما يكون هناك بعض القيود). ولكن إذا بدأنا من السؤال "ما هي العمليات التي يريدها المستخدمون؟" ، فإن الأمر الذي قد يُثبِّت الأحدث ، أو قد يترك لك إصدارًا قديمًا ، يكون حقًا غريبًا وغير بديهي. أؤكد أنه في 99٪ من الحالات التي يكتب فيها المستخدمون pip install x ، يرجع السبب في ذلك إلى أنهم (أ) إما غير متأكدين مما إذا كان مثبتًا أو يعلمون أنه غير مثبت ، و (ب) يريدون التأكد من أنهم هل قمت بتثبيته لأنهم على وشك البدء في استخدامه لأول مرة. (إذا لم تكن هذه هي المرة الأولى ، لكانوا يعرفون أنه تم تثبيته ، لذلك لن يقوموا بتشغيل pip install .) في هذه الحالة ، فإن إعطائهم أحدث إصدار هو الشيء الصحيح الذي يجب فعله.

nchammas :

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

بالنسبة إلى "إصدار محدد" يوجد pip install x==<version> .

يمكنني أيضًا أن أتخيل أنه بالنسبة لبعض أنواع البرمجة النصية / الاستخدام البرمجي ، قد يكون من المفيد أن يكون لديك أمر pip require x له نفس دلالات تثبيت حزمة بـ Dist-Requires: x ، أي أنه يتأكد من أن بعض تم تثبيت الإصدار ولكن مع عدم وجود ضمانات حول ما. لكن هذا سيكون أمرًا منخفض المستوى غير مخصص للمستخدمين النهائيين.

طريقة واحدة للتفكير في الفرق بين هذه: إذا x لم يتم تثبيت، فإنه سيكون بخير ل pip require x لتثبيت بعض نسخة قديمة عشوائي. ( وربما ينبغي ، لإجبار الناس على أن يكونوا أقوياء ضدها .) ولكن لن يقبل أحد على الإطلاق pip install x تثبيت بعض الإصدارات القديمة العشوائية.

(هذه تجربة فكرية ، أنا لا أؤيد حقًا أن اختيار Dist-Requires: x أو pip require x في بيئة لا يوجد بها x يجب أن يختاروا إصدارًا قديمًا عشوائيًا x للتثبيت.)

حسنًا ، أعتقد أن هناك أيضًا حالة أخرى حيث يكتب المستخدمون pip install x ، أي عندما يعرفون بالفعل أنه مثبت ، لكنهم معتادون على الأنظمة ذات السلوك على غرار Debian حيث يقوم install بالترقية دائمًا . من الواضح أن هؤلاء المستخدمين يريدون أيضًا الترقية :-).

أفضل عدم إضافة الأمر pip upgrade .

مستخدمو النقطة لديهم بالفعل بعض التوقعات لسلوك النقطة.
تأتي نقطة الألم الرئيسية من السلوك الافتراضي pip instal --upgrade لذلك دعونا نركز على ذلك.

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

نعم ، أنا بالتأكيد أحاول التعامل مع هذا من خلال "ما هي العمليات التي يريد المستخدم القيام بها" مقابل "العمليات التي يجب أن يقوم بها الأمر X". سأقوم بعد ذلك بهذه العملية عالية المستوى التي أعتقد أن المستخدمين يريدون القيام بها ، وأحاول تعيينها لأمر واحد مسمى (كما هو واضح ، تثبيت النقطة الأحدث '' ليس سهل الاستخدام للغاية) .

من الواضح أن هذا كله غامض للغاية ، لكن يمكنني القول أن 99٪ من الوقت الذي أقوم به هو pip install -U <whatever> لأن ذلك يتطابق بشكل أفضل مع ما أتوقعه من المثبت في ضوء ما هو متاح حاليًا. أرى أيضًا في العديد من نصوص التشغيل الآلي أشخاصًا يستخدمون pip install -U . إنه أيضًا ما يفعله مديرو الحزم المشهورون الآخرون للغات افتراضيًا مثل npm. في الحالات التي أرى فيها أشخاصًا لا يستخدمون -U ، فذلك بسبب الطبيعة التكرارية له ، وليس لأنهم لا يريدون تثبيت أحدث إصدار من الأشياء.

مستخدمو النقطة لديهم بالفعل بعض التوقعات لسلوك النقطة.

على الرغم من ذلك ، فإن التوقع الرئيسي الذي لدي حول النقطة كمستخدم هو أنه في حوالي 50 ٪ من الاستدعاءات ، ستفعل شيئًا مفاجئًا وخاطئًا بشكل واضح. وأنا لست واحدة فقط - انظر على سبيل المثالglyph الصورة محاضرة في pycon الأسبوع الماضي حيث لاحظ أن النقطة هي كبيرة إلا أن جميع الافتراضات يتم تقسيم وتتطلب unbreak لي الأعلام. هذا ليس انتقادًا لمطوري النقاط ، أفهم أنك / نحن جميعًا نعمل في ظل مجموعة معقدة من القيود ، وليست حجة أنه يجب علينا فقط كسر الأشياء من أجل كسرها - تحتوي النقطة على الكثير من القطع والكثير منها على ما يرام! ولكن نظرًا للحالة الإجمالية للإعدادات الافتراضية للبوب ، فأنا _ حقًا _ لست مقتنعًا بالحجج المتعلقة بالنموذج "النقطة كانت دائمًا تعمل X ، لذلك يجب أن تفعل النقطة دائمًا X". إذا كنت تريد أن تجادل برفض تثبيت النقطة للترقية ، فهذا أمر رائع ، لكنني أفضل كثيرًا أن أرى هذه الحجة تدور حول المزايا الفعلية ، وليس فقط على القصور الذاتي.

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

قد لا يكون هذا التغيير بالذات أحد هؤلاء ، لكنني أعتقد أنه كذلك.

نعم ، أنا بالتأكيد أحاول التعامل مع هذا من خلال "ما هي العمليات التي يريد المستخدم القيام بها" مقابل "العمليات التي يجب أن يقوم بها الأمر X". سأقوم بعد ذلك بهذه العملية عالية المستوى التي أعتقد أن المستخدمين يريدون القيام بها ، وأحاول تعيينها لأمر واحد مسمى (كما هو واضح ، تثبيت النقطة الأحدث '' ليس سهل الاستخدام للغاية) .

موافق. لنفترض أنني على استعداد لأعتبر نفسي مقتنعًا (إلى حد ما) بهذا الأمر. ومع ذلك ، إذا افترضنا أن هذا هو الشيء الصحيح الذي ينبغي عمله ، فماذا عن التبعيات؟ أنا مقتنع بنسبة 100٪ أن "محاولة تثبيت numpy من المصدر" ليست دائمًا ما هو مطلوب. لذلك نقوم فقط بتثبيت numpy من العجلات ، ما لم يذكر المستخدم صراحةً numpy. خذ هذا على أنه أمر مفروغ منه في الوقت الحالي ، ثم افترض أن لدينا الموقف الذي وصفته سابقًا.

• المستخدم لديه foo 1.0 و numpy 1.10 مثبتًا ، foo 1.0 يعتمد على numpy> = 1.10
• يتوفر PyPI foo 2.0 ، ويعتمد ذلك على numpy> = 1.11. لا توجد عجلات 1.11 فارغة.

ماذا يفعل pip install foo ؟ من المفترض ترك المستخدم عند 1.0 ، لأنه تثبيت عامل؟ ولكن هل ينجح (كما تم تثبيت foo) أم يفشل (لأنه لا يمكنه تثبيت أحدث إصدار)؟ إذا كان الأول فكيف يكتشف المستخدم أن نظامه قديم؟ إذا كان الأخير ، كيف يقول المستخدم "أريد فقط التأكد من وجود foo"؟ حسنًا ، يمكن للمستخدم أن يفعل pip list --outdated ، لاحظ أن foo 2.0 موجود ويقوم بعمل pip install foo (راجع للشغل ، لا يزال هذا يبدو غريبًا تمامًا بالنسبة لي ، لدي foo ، لكنني أعلم أن هناك إصدارًا جديدًا ، لذا أقوم بتثبيت النقطة ؟؟؟ Nevermind ...) وتحصل على النجاح ، ولكن يبقى 1.0 مثبتًا؟

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

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

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

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

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

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

بالنظر إلى ذلك ، أعتقد أنه افتراضيًا في الوقت الحالي ، يجب أن نسحب حزمة المصدر 1.11 غير المفككة ونحاول تثبيتها ، ولكن إذا حددوا --only-binary ، إذن المحلل الافتراضي الخاص بنا (الذي نحتاجه بشدة ، SAT أو التتبع الخلفي أو أيًا كان) سترى أن foo-2.0 ليس تثبيتًا قابلاً للحل وسيعود بعد ذلك إلى تثبيت foo-1.0 . هذا ليس افتراضيًا رائعًا ، خاصة بالنسبة لمستخدمي Windows حيث يكون التجميع _ أكثر صعوبة_ ، ولكن أعتقد أنه يعكس واقع اليوم.

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

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

ولكن إليك الطريقة التي أقترح بها معالجة هذه المشكلات مقابل pip install foo (تحديدًا هذا الأمر - أنا لا أتحدث عن pip install foo==whatever أو pip install ./foo-*.whl أو pip install bar حيث bar لديه Requires-Dist: foo ):

1) استعلم عن الفهرس للعثور على أحدث إصدار مرشح foo ؛ اتصل بهذا $LATEST . في حالة عدم وجود إصدارات مرشح ، ثم الخطأ.

2) إذا كان $LATEST مثبتًا بالفعل ، فقم بالإنهاء بنجاح.

3) تحقق مما إذا كان هناك توزيع $LATEST يمكن تثبيته على البيئة الحالية. (مثال على أسباب عدم وجود: هناك عجلات فقط ، ولكن لا توجد قوائم sdists ، والعجلات لا تتوافق مع البيئة الحالية. لا توجد أي عجلة مطابقة ، وهناك قائمة عرض ، لكن المستخدم قد تجاوز --binary-only :all: . ليس هناك أي عجلة مطابقة ، وهناك sdist ، ولكن هناك علامة على sdist تقول "أنا أعمل فقط على python 3" والمستخدم يقوم بتشغيل python 2 - من المحتمل أن يقوم ipython / jupyter اقترح هذا كميزة جديدة قريبًا ، ب / ج يريدون إسقاط دعم Python 2 للإصدارات الجديدة في يناير بينما لا يزالون يوفرون LTS يدعم Python-2.)

4) إذا كان $LATEST _لا يحتوي على توزيع قابل للتطبيق: قم بإصدار تحذير لإخبار المستخدم أن إصدارًا جديدًا متاحًا ولكن ليس لبيئته ، من الناحية المثالية مع تلميح إلى ما يحتاجون إلى القيام به إذا كانوا يفعلون بالفعل تريد الإصدار الجديد (على سبيل المثال ، "ipython 6.0.1 متاح ولكنه يتطلب python> = 3.4 ، ولديك python 2.7 - ضع في اعتبارك ترقية python" ، أو "numpy 1.12 متاح ، ولكن لا يوجد ثنائي لـ ppc64 ولديك بناء معطل من المصدر - ضع في اعتبارك --allow-source numpy ). ثم أزل $LATEST من قائمة الإصدارات المرشحة وانتقل إلى الخطوة 1.

5) إذا كان لدى $LATEST _does_ توزيع قابل للتطبيق ، فحاول تثبيت هذا التوزيع.

6) إذا فشل تثبيته (على سبيل المثال ، b / c هو sdist ولا يوجد مترجم) ، ثم حدث خطأ. وإلا ، فقم بالإنهاء بنجاح.

njsmith ثنائي فقط متعامد إلى حد ما ، موافق ، ولكن IMO إذا كنا نحاول تصميم أوامر "تفعل ما يتوقعه المستخدم" ، فمن المهم أن تحصل على هذا بشكل صحيح في نفس الوقت.

dstufft المشكلة مع "تثبيت numpy ما لم يقول المستخدم --binary-only تم شرحه في المثال في مشاركتي الملحمية السابقة - (1) قل أن foo متاح فقط في النموذج المصدر ، و (2) المستخدم قد لا (ولا يجب عليك فعلاً) معرفة أن foo يعتمد على numpy. ثم لا يمكن للمستخدم أن يقول --only-binary :all: وليس لديه فكرة أنه يحتاج إلى --only-binary numpy حتى _after_ a (طويل) فشل التجميع. أو (ربما الأسوأ من ذلك) تجميع ناجح يترك المستخدم مع numpy غير محسّن (هذه الأيام ، numpy يصنف خارج الصندوق على Windows ، لكنه يعطي بنية غير محسّنة).

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

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

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

كنت أتوقع أن يكون هناك. أنا مهتم بالمضي قدما بهذا الأمر. هيا بنا نقوم بذلك! :ابتسامة:

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

لبدء الأشياء ، إليك قائمة غير مكتملة على الأرجح:

1. يريد المستخدم تثبيت حزمة لم يتم تثبيتها بعد.
2. يحاول مستخدم تثبيت حزمة مثبتة بالفعل.
3. يريد المستخدم ترقية حزمة مثبتة.
4. يحاول مستخدم ترقية حزمة غير مثبتة.
5. يريد المستخدم التأكد من تثبيت أحدث إصدار من الحزمة ، سواء تم تثبيتها بالفعل أم لا.
6. لا يرغب المستخدم عادةً في ترقية جميع التبعيات وبدلاً من ذلك يجب إشباعها فقط.
7. يريد المستخدم ترقية / تثبيت حزمة لكنه لا يريد البناء من المصدر (لا الحزمة ولا تبعياتها). ربما أكثر احتمالا من:
8. يرغب المستخدم في الترقية / التثبيت من المصدر.

مقترحاتي الشخصية لهذا ، كمستخدم:

1) & 7) يجب أن يحاول pip install foo حل أحدث إصدار متاح (مع مراعاة التبعيات) وتثبيته. الخوارزمية ستكون njsmith .
2) pip install foo → أظهر تحذيرًا من أن foo مثبت بالفعل واقترح استخدام pip upgrade foo
3) & 7) يحاول pip upgrade foo تثبيت أحدث إصدار متاح من foo ، مرة أخرى باتباع خوارزمية njsmith . إذا تعذر تثبيت إصدار أحدث لأنه غير متوفر للنظام الأساسي ولا يوجد sdist أو لا يرغب المستخدم في الإنشاء من المصدر ، فقم بإظهار ذلك. تنجح في كلتا الحالتين وتفشل فقط إذا فشل التثبيت نفسه.
4) يخفق pip upgrade foo إذا لم يتم تثبيت الحزمة.
5) pip install-uprade foo أو pip install foo --ensure-latest أو pip install foo --upgrade (بشكل أساسي هو نفسه حاليًا باستثناء غير المتحمسين).
7) يجب أن تكون جميع العمليات غير متحمسة وأن يكون العلم --eager متاحًا للحصول على الوظيفة القديمة install --upgrade . إذا لم يتم تثبيت تبعية بعد ، فقم بتثبيت أحدث. إذا كانت راضية بالفعل ، فلا تفعل شيئًا. إذا لم يكن مستوفيًا ، فقم بتثبيت أحدث إصدار لا يزال مُرضيًا (لمتطلبات الحد الأعلى).
8) pip upgrade foo --allow-source أو pip upgrade foo --allow-source numpy ، إذا كان foo يعتمد على الإصدارات غير الثنائية المعقدة. تحرير: لا أعرف ما إذا كان هذا سيكون قابلاً للتطبيق ، انظر التعليق أدناه.

لا تتردد في تمديد القائمة ونشر مقترحاتك الخاصة.

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

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

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

لا تحتوي الحزم التي قمت بتثبيتها عادةً على أي تبعيات أخرى "> =" (ومعظمها لا يمتلك ذلك حتى) لذلك لا يوجد شيء معقد هنا. فقط احصل على أحدث إصدار. أكبر قيد لدي هو أن هناك بعض الحزم التي لا يمكنني إنشاؤها (numpy ، scipy ، lxml ، pyyaml ​​، matplotlib ، pyqt) لذلك أريد فقط ثنائيات لتلك. ربما يمكنني فقط وضع --only-binary <these> في pip.ini (أو على الأقل أتمنى أن أستطيع ...)

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

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

كل النقاش حول التبعيات والقيود ، في تجربتي ، هو نظري بالكامل تقريبًا. لدي حاليًا 160 حزمة مثبتة في نظام Python الخاص بي (مزيج من وحدات البرمجة العلمية وتحليل البيانات والويب والبرمجة العامة). 100 منهم ليس لديهم متطلبات. بالنسبة للباقي ، لا يوجد أي شيء أكثر تعقيدًا من قائمة الحزم - لا توجد قيود على الإصدار أو أي شيء أكثر تعقيدًا من Requires: six, dask, pillow, networkx . أطول قائمة من التبعيات تحتوي على 9 عناصر.

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

• SQLAlchemy (يتطلب اختياريًا مترجمًا ، سيستخدم Python النقي إذا لم يكن كذلك).
• PyYAML (يتطلب مترجمًا اختياريًا ، سيستخدم Python النقي إذا لم يكن كذلك).
• Markupsafe (يتطلب اختياريًا مترجمًا ، سيستخدم Python النقي إذا لم يكن كذلك).
• PyCrypto (يتطلب دائمًا مترجمًا)
• pycparser (لا يتطلب مترجمًا أبدًا)
• HTplib2 (لا يتطلب مترجمًا أبدًا)
• anyjson (لا تتطلب مترجمًا أبدًا)
• zope.interface (يتطلب اختياريًا مترجمًا ، سيستخدم Pure Python إذا لم يكن كذلك).
• docopt (لا يتطلب مترجمًا أبدًا)
• ماكو (لا يتطلب مترجمًا أبدًا)
• انها خطيرة (لا تتطلب مترجم)
• amqp (لا يتطلب مترجمًا أبدًا)
• ordereddict (لا يتطلب مترجم)

وهكذا ، يمكنك مشاهدة قائمة طويلة من الحزم الأكثر شيوعًا وما إذا كانت تحتوي على عجلات أم لا على http://pythonwheels.com/.

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

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

لقد حصلت على هذا الأمر من بعض أسئلة SO منذ فترة وأنا أستخدمها حاليًا لهذا الغرض. إنها دون المستوى الأمثل ، لكنها تعمل مع معظم الحزم الخاصة بي ، باستثناء واحدة. (يستخدم المشغل py لأنني على Windows.)

pip list -o | cut -d " " -f 1 | xargs -n1 py -m pip install -U

الآن ، المشكلة الوحيدة التي أواجهها هي حزمة flake8 ، والتي لها المتطلبات التالية:

Requires-Dist: pyflakes (>=0.8.1,<1.1)
Requires-Dist: pep8 (>=1.5.7,!=1.6.0,!=1.6.1,!=1.6.2)
Requires-Dist: mccabe (>=0.2.1,<0.5)

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

dstufft لماذا؟ إذا كان foo يعتمد على pyyaml ​​وأطلب ترقية foo ، فلن تتم ترقية pyyaml ​​(لا توجد ثنائيات جديدة) ولكن لا يزال من الممكن ترقية foo ، حيث لا يزال هناك Pyyaml ​​الأصلي.

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

حسنًا ، ربما تكون المشكلة التي أواجهها هي في الواقع مع خيار --only-binary ، وهو خيار خشن جدًا. إذا كان لدينا خيار --prefer-binary ، والذي ينص على "استخدام الثنائيات فقط ، ما لم يكن ذلك يعني عدم وجود مرشحين ، وفي هذه الحالة أعد المحاولة للسماح بالمصدر" ، أظن أن العديد من مخاوفي من أن الترقية المفرطة قد تؤدي إلى تعطل قد يتم تخفيفها. وهو ما يعني ، كما اقترح njsmith ، أن الفروق الثنائية / المصادر التي أركز عليها قد تكون متعامدة مع هذه التذكرة (على الرغم من أنها ستغير موقفي إلى "لا يوجد حل مرض لمتطلباتي بدون شيء أفضل من --only-binary متوفر "...).

على وجه التحديد البيفلاك هو مشكلة

حسنًا ، هذا ليس موقفًا لدي (كما أقول ، ليس لدي أي شيء به تبعيات تم تثبيتها المعقدة). ليس لدي مشكلة في تحسين "ترقية الكل" لترقية الأشياء إلى "أحدث إصدار لا ينتج عنه أعطال" ولكن AIUI الذي يحتاج إلى نهج "SAT solver" للتوصل إلى الحل الصحيح. هذه مشكلة تنفيذية - يجب أن يعطي التصميم دائمًا النتائج الصحيحة.

pfmoore أعتقد أن العلم --prefer-binary قد يكون خيارًا جيدًا ، بغض النظر عن نتيجة هذه التذكرة. من المحتمل أن يتم إرفاقه مع تحذير عندما ينتهي ذلك بعدم تثبيت أحدث إصدار كان سيتم تثبيته بخلاف ذلك.

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

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

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

$ pip install foobar
I'm sorry, but foobar is already installed, you want to run ``pip upgrade foobar``
$ pip upgrade foobar
...

لن أفعل شيئًا من أجلي باستثناء إزعاجي ، على الرغم من أنه من الناحية الفنية "صحيح".

على العكس من ذلك ، إذا قلت "حسنًا ، إذا كان pip install foobar مثبتًا بالفعل على foobar ، فسنتصرف كما لو أنه غير مثبت ، وإذا قمت بتثبيت pip upgrade foobar فإننا سوف نتصرف كما لو كان مثبتًا بالفعل ، ينتهي بنا الأمر بأمرين يقومان بنفس الشيء بشكل أساسي ، باستثناء _ ربما _ بعض الاختلافات الطفيفة في كيفية معالجة الأشياء بالضبط ، والتي تخبرني أنها تنتمي كأمر واحد مع بعض --options للتعامل مع حالات الحافة. ​​أعتقد أن هذا أفضل لأنه يعني أنه لا يتعين على المستخدمين محاولة الاختيار بين الخيار الذي يريدونه مقدمًا ، فهناك أمر واحد لتثبيت الأشياء وبالنسبة لمعظم المستخدمين بشكل عام يفعل الشيء الصحيح.إذا كان بعض المستخدمين في سيناريو معين يطلب بعض الخيارات من جانبهم ، فعليهم أن يدفعوا تكلفة اتخاذ بعض الخيارات حول ما يجب استخدامه --flags .

موافق. اعتبرني مقتنعا. لقد أجريت بعض الأبحاث ، وحتى مثبّتي Windows (المفترض :-)) الذين أعرفهم يقومون بالتثبيت أثناء الترقية (إذا قمت بتثبيت شيء مثل VirtualBox ، فإنه يقول "لديك بالفعل إصدار سابق مثبت ، هل هل تريد الترقية؟ ") لدى Powershell حزمة تثبيت ، والتي لا تذكر شيئًا محددًا ، ولكن لا توجد حزمة ترقية. إلخ. لذا أعتقد أن مجرد وجود أمر "تثبيت" هو القاعدة.

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

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

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

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

وأنا أتفق تماما معdstufft الصورة الاحدث https://github.com/pypa/pip/issues/59#issuecomment -224341218
لهذا السبب (مرة أخرى) أنا أؤيد الحل البسيط لخيارات --eager / --non-eager .

أتفق أيضًا مع تعليق dstufft ، كما هو مذكور (نختار أمرًا واحدًا install ولا يوجد أمر update ).

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

وسؤال - هل سيشجع هذا الحزم العلمية على الإعلان بشكل صحيح عن تبعياتها؟ يجب أن يكون اعتبار هام.

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

يقترح هذا PR أيضًا أمر upgrade-all ، وهو حالة الاستخدام الرئيسية بالنسبة لي. هل تقول إننا نرفض هذا الأمر ، أم أنك ببساطة لا تملك رأيًا فيه؟

فهمي لما يعنيه --eager و -non-eager يتطابق مع ما قالتهpfmoore للتو (سواء كانت التبعيات عند الحاجة فقط أو مثبتة دائمًا) ، وأوافق على أن --non-eager يجب أن يكون الافتراضي. أوافق أيضًا على أن الاسم تافه على الرغم من أنه ليس لدي حل أفضل ليس مملوءًا بالفم. ربما --[no-]recursive أو شيء من هذا القبيل ، لا أعرف.

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

TL ؛ د
مناقشة لـ upgrade-all-packages - يبقى هنا.
مناقشة تفضيل ثنائي - أكثر من 3785 #
مناقشة التثبيت كترقية - أكثر من 3786 #

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

هذه فكرة جيدة. بينما تتعلق بهذه المشكلة ، أعتقد أنها تستحق مشكلتها الخاصة. (تعليق @ dstufft يجعلني أعتقد أن هناك اهتمامًا بمتابعته). أخذت الحرية لفتح # 3785 لمزيد من المناقشة حول هذا الموضوع.

يتطابق فهمي لما تعنيه --eager and-non-حريصًا مع ما قالتهpfmoore للتو (سواء كانت التبعيات عند الضرورة فقط أو مثبتة دائمًا)

ستعمل الترقية الحثيثة على تثبيت أحدث الإصدارات المسموح بها من جميع التبعيات (الفرعية) لن تقوم الترقية غير المتلهفة بترقية التبعية

أسماء الخيارات --eager و - non- حريصة غير بديهية إلى حد ما.

أنا موافق. أحب فكرة وضع السلوك وراء علم واحد.
--upgrade-strategy=eager/non-eager

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

أعتقد أن أفضل طريقة لإلقاء الدراجة هي بعد الانتهاء من الدلالات.

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

اعتقد ذلك. نحتاج ، على الأقل ، إلى إرساء بعض الحقائق الأساسية التي نتفق عليها. أنا في هذا.

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

أعتقد أننا يجب أن نترك هذه المشكلة مفتوحة الآن ، لأنها تقترح upgrade-all . لقد لاحظت بالفعل أن الترقية لا تحدث. فتحت # 3786 لمزيد من المناقشة حول أمر التثبيت كترقية.

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

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

أعتقد أن الجميع يتفقون على أن أمر "ترقية العالم" سيكون أمرًا رائعًا حقًا ، لكن IIUC تم حظره بينما ننتظر وصول عمل المحلل. في غضون ذلك ، قمت الواحدة حول pradyunsg .

أعتقد أن الجميع يتفقون على أن أمر "ترقية العالم" سيكون أمرًا رائعًا حقًا ، لكن IIUC تم حظره بينما ننتظر وصول عمل المحلل.

في الواقع تم حظر هذه المشكلة الآن بشكل صحيح بواسطة # 988. ذكر رقم الإصدار لربط المسألتين.

انا تقريبا نسيت...

لست متأكدًا مما تقصده بشأن "الاحتفاظ" بالتحديثات. الرجاء التوضيح.

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

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

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

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

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

آه لقد فهمت. هذا منطقي ، ويبدو أنه شيء معقول تريده.

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

_{_يذهب للنوم_}

ميزتان جميلتان تمتلكهما apt (وأعتقد أن مديري حزم النظام الآخرين مثل dnf لديهم ميزات مماثلة):

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

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

نفس الشيء. إذا أضفنا "ترقية العالم" ، فنحن بحاجة إلى إضافة القدرة على تمييز الحزم (مثل held / user-installed وربما أكثر) لإضافة معلومات لتحديد مسار العمل بشكل أفضل الترقيات. أرى أن هذا مطلب ، وليس من الجميل أن يكون لديك.

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

سأكون سعيدًا حقًا إذا رأيت شكلاً من أشكال pyproject.lock ...

التعليق رقم 200. رائع. : مبتسم:

إضافة إشارة إلى # 654 من أجل "تمييز" الحزم التي تحدثنا عنها.

هل يمكنك شرح ما تفعله البضائع؟ أين ستشاهد ملف pyproject.lock يتم تخزينه على جهاز المستخدم؟

يتم تخزين ملف قفل Rust's Cargo في جذر المشروع ، لتسجيل إصدار التبعيات المثبتة حاليًا. يتيح لك الالتزام بـ git مشاركة مجموعة متسقة من إصدارات التبعية مع المطورين الآخرين و CI. يحتوي مؤلف PHP على ملف قفل مشابه ، Composer.lock.

لطالما افترضت أن 'pip freeze' و 'pip install -r' كان من المفترض أن يقوموا بعمل مماثل ، وكان من المؤسف أن تنسيق ملف القفل كان سهل القراءة / الكتابة من قبل البشر ويختار الناس تحريره مباشرة. هل لم يكن يُنظر إلى ملف requirements.txt في الأصل على أنه ملف قفل؟

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

للمساعدة في فك التشابك في المناقشات حول upgrade-all و "ترقية السلوك" ، إليك تعليقات من rbtcollins و ncoghlan في المناقشة على القائمة حول الأخير حول SAT غير مطلوب للتنفيذ الأول لـ upgrade-all :

روبرت:

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

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

نيك:

عملت "yum Upgrade" بشكل جيد بما يكفي لسنوات بدون برنامج SAT مناسب ، والحزمة المحددة في تثبيت Linux النموذجي أكبر بكثير من تلك الموجودة في بيئة افتراضية نموذجية (على الرغم من أن توزيع التوزيعات يقلل من احتمالية وجود متطلبات متضاربة تنشأ في الأول مكان).

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

IMO ، pip upgrade-all هو إلى حد بعيد أهم عرض على الطاولة من بين جميع مناقشات "وظائف الترقية" المتنوعة. توفر "ترقية الكل" طريقة واضحة للحفاظ على تحديث نظامك ، مما يجعل الأسئلة حول التحديثات غير المتلهفة تترك الأمور في المستويات الأقدم أقل إلحاحًا ، بالإضافة إلى سد الفجوة الموجودة حاليًا.

على الرغم من أن الحل الكامل سيكون أمرًا رائعًا ، إلا أنني لا أرى أي سبب يجعل نقطة البداية لـ pip upgrade-all تقوم بما يفعله pip install -U <list every package that's installed here> . هذا ما كنت أتوقعه كمستخدم ، وهو يفعل بالضبط ما هو مطلوب في معظم الحالات. يمكن معالجة حالات الزاوية المعقدة حول المتطلبات المتضاربة في المقام الأول بالرجوع إلى ما سبق. إذا لم يكن ذلك كافيًا ، فيمكننا النظر في تعديل سلوك install -U لمعالجته ، أو غلاف خاص للأمر update-all ، أو حتى تنفيذ حل كامل في تلك المرحلة.

هل ستنفذ هذا في السنوات العشر القادمة؟

FWIW ، سأقوم بزيارته مرة أخرى في نهاية هذا الأسبوع.

magicgoose قال:
هل ستنفذ هذا في السنوات العشر القادمة؟

قال pfmoore أنه أفضل مما أستطيع:

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

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

رأي شخصي تمامًا

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

نظرًا لأننا نضمن دائمًا حالة الحصول المعروفة لمجموعة حزم Python القابلة للتثبيت

RonnyPfannschmidt IMO من المعقول تمامًا لمستخدمي pip أن

pfmoore تجربتي الشخصية مع مجرد تحديث جميع الحزم في بيئة ما هي أنه يكسر الأشياء بشكل منتظم جدًا ^ ^

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

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

RonnyPfannschmidt لا يزال مستخدمو Windows يفوق عدد مستخدمي Linux ~ 18 إلى 1 ، وليس لديهم أي شيء يمكن مقارنته بمجتمع إدارة حزم التوزيعات للرجوع إليه في هذه المرحلة (في حين أن التكنولوجيا الأساسية موجودة في الإصدارات الأخيرة ، ومجتمعات التعبئة والتغليف والتنظيم ليست). هذا يعني أنهم يعتمدون كثيرًا على أدوات مستوى المستخدم مثل النقطة وكوندا لالتقاط فترة الركود.

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

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

ملخص تقريبي لجزء منه فقط (PR gh-3194):

1. هناك قرار موثق يفيد بأن الأمر upgrade مرحب به (في القائمة البريدية للنقطة بالإضافة إلى المستندات و GitHub).
2. ثم يصدر اتصال من أحد المطورين البارزين (
3. يظهر مساهم جديد ، وينفذ كل شيء ، ويعالج جميع التعليقات بسرعة. العلاقات العامة جاهزة للدمج.
4. يغير المساهم الأساسي رأيه بشأن الرغبة في الحصول على upgrade .
5. تتبع مناقشات طويلة جدا ، دون نتيجة.
6. يستسلم المساهم ويختفي (معظم الناس يفعلون ذلك ، مثل هذه الأشياء محبطة).

وكان ذلك حتى قبل ظهورpradyunsg ، الذي يُظهر إصرارًا ملحوظًا.

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

أعلم أن لديك أفضل النوايا ، ولكن من فضلك كن أكثر حذرا مع هذا النوع من التعليقات.

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

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

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

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

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

rgommers على محمل الجد؟ كان هذا التعليق من شهور مضت ، وتم اقتباسه خارج سياقه هنا (ولكن بصراحة ، ليس لدي مشكلة في اقتباس pradyunsg ردًا على التعليق غير المفيد

إذا كنت "خارج القاعدة" ، فعندئذٍ كان بإمكانك قول ذلك في مايو في الوقت الذي قلته فيه ، بدلاً من انتقاؤه الآن ، خارج السياق.

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

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

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

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

سينظم جلسة Hangout سريعة ويتخذ نوعًا من القرار.

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

أو قم بتفويض شخص أو شخصين للعمل عليها بما يكفي للحصول على هذا الاستنتاج.

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

أو على الأقل اعتذر وقل شكراً لمقدم العلاقات العامة ،

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

هو بالتأكيد لديه شكري. من السهل أن تقول "هذا بدون قول" ، لكن لا ينبغي أن تقول ذلك - لا تشكر المشاريع مفتوحة المصدر المساهمين بما فيه الكفاية ، وهذه مشكلة. أثناء تواجدي في هذا الموضوع ، أود أن أشكر _الجميع_ الذين ساهموا في هذا النقاش - وأنا جاد تمامًا هنا - كما أعلم من التجربة كيف يمكن أن يكون استنزافًا. ولكن بشكل خاص لـ pradyunsg لكونه الضحية الحالية لجميع المناقشات والتغييرات التي لا نهاية لها في الاتجاه. شكرا لعدم الاستسلام! (بعد!!)

بدلاً من لومه على "عدم المتابعة".

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

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

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

لذا هل يمكنني أن أقترح أن نعود لمحاولة مساعدة pradyunsg في التوصل إلى

لذا هل يمكنني أن أقترح أن نعود لمحاولة مساعدة pradyunsg في التوصل إلى

نعم من فضلك. :البريء:

آه نسيت.

rgommers قال:
وكان ذلك حتى قبل ظهورpradyunsg ، الذي يُظهر إصرارًا ملحوظًا.

سآخذ هذا كمكمل ... شكرا.

pfmoore قال:
خاصة لـ pradyunsg لكونه الضحية الحالية لجميع المناقشات والتغييرات التي لا نهاية لها في الاتجاه. شكرا لعدم الاستسلام!

على الرحب والسعة.

(بعد!!)

آمل حقًا ألا تصل إلى تلك الحالة. ستكون حالة سيئة حقًا إذا حدث ذلك ، IMO. (أنا مغرور بهذه الطريقة)

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

• قررت العمل على هذا بعد أن أدركت كيف ستكون النسبة غير الفنية الكبيرة الفنية (إنها أكبر بكثير مما كنت أعتقده بشكل متحفظ) وأدركت أنه كانت هناك بالفعل محاولة فاشلة في هذا الشأن.
• قمت بتدوين الوضع ، لأنني كنت أشعر بالملل وكنت بحاجة إلى معرفة ما حدث على أي حال.
  
  
  
  • ربما قضيت وقتًا أطول (ومساحة هنا؟) على ذلك أكثر من اللازم ولكن على الأقل حصلت على نظرة عامة جيدة عن المشكلة بنفسي (وأي شخص آخر؟).
  
  
• أصبحت متحمسًا جدًا بعد كتابته. : مبتسم: أظهرها للعالم!
• بدأ مناقشة (طويلة !!!) حول تنفيذ أمر ترقية.
  
  
  
  • ظهرت بعض الأفكار غير المباشرة المفيدة في المناقشات. تم إنشاء قضايا جديدة لنفسه.
  
  
• تؤدي المناقشة إلى فكرة تغيير سلوك التثبيت إلى التثبيت ، مما يؤدي إلى إجراء ترقيات غير متحمسة افتراضيًا وإزالة جزء من الوظيفة التي يوفرها - الخيار المستهدف - 3 أشياء.
  
  
  
  • هذا هو المكان الذي ارتكبنا فيه خطأ - تجميع التغييرات الثلاثة المستقلة (إلى حد ما) والتي سيتم تنفيذها كواحد ، لأنه لم يدرك أحد هذا الجزء.
  
  
• لقد نفذت نفس الشيء. نظرًا لأنه تم تجميع التغييرات الثلاثة ، فقد تعثروا جميعًا عندما لم يكن هناك إجماع على تغيير سلوك التثبيت إلى التثبيت ، وهو التغيير المثير للجدل المحتمل.
• أدى الافتقار إلى الإجماع إلى بدء نقاش طويل وصل إلى النقطة التي تراجع فيها الناس عن المناقشة وأعتقد أنها دفعت تقريبًا إلى الإرهاق.
  
  
  
  • تم كسر بعض الافتراضات السابقة وتقرر أننا سنفعل الحد الأدنى من تغيير الاضطراب أولاً.
  
  
• لقد نفد وقت فراغي للعمل على هذا الأمر ، لذلك قمت بإنشاء بعض المشكلات الجديدة حتى يتمكن شخص آخر من العمل عليها بشكل مستقل ومن الأفضل ألا يرتكب نفس الخطأ الذي ارتكبناه هنا.
• توقفت.
• لقد عدت! سأحاول التبديل إلى الترقيات غير المتلهفة افتراضيًا بحلول 25 سبتمبر.

نعم ، دعنا نركز فقط على إصلاح pip install --upgrade ونترك كل شيء بالخارج في الوقت الحالي. هذا شرط لأي عمل آخر على أي حال.

pfmoore @ dstufft شكرا على الردود المدروسة. لم أقصد الإساءة إلى أي شخص ، لذا أعتذر إذا حدث ذلك بهذه الطريقة.

لن أرد على كل شيء ، لأنه لا أحد يبحث عن مناقشة طويلة هنا.

كان من الممكن أن تقول ذلك في مايو في الوقت الذي قلته فيه ،

كنت بعيدًا عن Github لمدة شهرين بعد ذلك ، لكن هذا ما أزعجني عندما رأيت هذا التعليق لأول مرة.

إذن أنت تقول أن قرارًا بهذا الحجم يجب أن يتخذه شخصان من جانب واحد؟

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

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

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

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

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

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

أثناء تواجدي في هذا الموضوع ، أود أن أشكر كل من ساهم في هذا النقاش

متفق. شكرا لكل من ساهم.

• وأنا جاد تمامًا هنا - كما أعلم من التجربة كيف يمكن أن يكون الأمر مستنزفًا.

إنه يستنزف. أنا شخصياً ألتزم هنا وفي Distutils-sig لأنه مهم لنظام Python البيئي ومستخدمي الحزم الخاصة بي ، لكن كلا المكانين لا يعطاني طاقة إيجابية بالضبط.

فقط في حالة انزلاقه من تحت الرادار - # 3972: ابتسم:

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

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

شكرًا لتوضيح ذلك - سأحاول أن أضع ذلك في الاعتبار وتجنب إعطاء هذا الانطباع في المستقبل.

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

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

pradyunsg مراجعة # 3972 موجودة في قائمة TODO الخاصة بي ، لم تضغط عليها بعد.

pradyunsg مراجعة # 3972 موجودة في قائمة TODO الخاصة بي ، لم تضغط عليها بعد.

شكرا!

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

أن من الصعب. كان Numpy و Scipy في هذا الموقف عندما بدأت العمل على هؤلاء. غير مسلي. أنا أقدر كل ما تفعله.

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

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

أقترح إغلاق هذه المشكلة بسبب ما ورد أعلاه وإنشاء مشكلات جديدة لأي شيء يُنظر إليه هنا على أنه لم يتم حله. أستطيع أن أرى شيئين:

• حوّل إستراتيجية الترقية الافتراضية إلى only-if-needed .
• إضافة وظيفة "ترقية العالم" التي تعتمد على # 988.

في 15/9/2016 ، كتب Nick Coghlan [email protected] :

RonnyPfannschmidt لا يزال عدد مستخدمي Windows يفوق عدد مستخدمي Linux ~ 18 إلى 1 ، و
ليس لديهم أي شيء يمكن مقارنته بمجتمع إدارة حزم التوزيعات
للرجوع إليها في هذه المرحلة (بينما التكنولوجيا الأساسية موجودة في الآونة الأخيرة
الإصدارات ، ومجتمعات الحزم والتنظيم ليست كذلك). هذا يعني أنهم
أكثر اعتمادًا على أدوات مستوى المستخدم مثل النقطة وكوندا لالتقاط ملف
تثاقل.

أليس كذلك
تحديث كوندا - الكل
جيد بما فيه الكفاية؟

تضمين التغريدة
حسنًا ، لا ، الأمر ليس كذلك.

كوندا وبيب أدوات ذات أهداف مختلفة. هذه قراءة رائعة عن هذا الموضوع. النقطة الثالثة هي الأكثر صلة بالموضوع.

إذا كان النقاش حول ترقية جميع الأسطح مرة أخرى (نأمل في إصدار جديد) فإن تصويتي هو تهجئته على النحو التالي:

pip install --upgrade :all:

pip install --upgrade :all: غريب للغاية. دعنا نلتزم بدلالات POSIX ، والتي يقوم بها الجميع بشكل أساسي في الوقت الحاضر: pip install --upgrade --all

ماذا عن pip install --upgrade بدون أي أسماء حزم أو محددات؟ من السهل أن تعمل بالصدفة؟

تقوم أدوات النقطة بهذه الطريقة مقابل pip-compile -P .

ربما يجب علينا سقيفة الدراجات بمجرد أن يكون لدينا نوع من العمل
التنفيذ... :)

في الأحد 12 فبراير 2017 الساعة 20:55 كتب FichteFoll [email protected] :

ماذا عن مجرد تثبيت النقطة - الترقية دون أي أسماء حزم أو
محددات؟ من السهل أن تعمل بالصدفة؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/pypa/pip/issues/59#issuecomment-279225595 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/ADH7SfnSBflH8rK3nFLw1hvYBaovjbcGks5rbyRUgaJpZM4AJ4Py
.

ماذا عن إصدار pip list --outdated الذي ينتج قائمته بتنسيق يمكن أن يكون مباشرة (على سبيل المثال ، بدون sed ، cut ، إلخ.) يتم تناوله بواسطة pip install --upgrade (على سبيل المثال ، pip list --outdated --format install | xargs pip install --upgrade أو شيء مشابه مع backticks)؟

مهما كانت الصيغة المستخدمة ، فإن أهم شيء هو إدخال هذا الأمر ، إنه أمر لا يصدق أنه لا يزال مفقودًا

في غضون ذلك ، أقترح عليك المحاولة
https://github.com/jgonggrijp/pip-review
مع pip-review --local --interactive اطلب حزمة تلو الحزمة إذا كنت تريد التحديث ، ليس جيدًا جدًا ولكن أفضل من لا شيء

@ SMH17 من المقبول تمامًا أنه لا يزال مفقودًا ، حيث لا يوجد بائعو Python التجاريون تمامًا يقدمون رسميًا وقت تطوير ممول للعمل على تحسينات استخدام

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

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

• احتفظ بتعريفات بيئة العمل الخاصة بك تحت التحكم بالمصادر لتحسين إمكانية إعادة الإنتاج على الأنظمة الأخرى (باستخدام شيء مثل https://github.com/jazzband/pip-tools أو https://github.com/kennethreitz/pipenv لتحديث هذه التعريفات باستمرار )
• تهدف إلى الترقية بشكل روتيني إلى الإصدارات الجديدة من التبعيات من أجل تقليل تعرض النوافذ لثغرات أمنية غير معروفة أو غير معلنة

هذا لا يعني أن الأوامر المقترحة هنا ليست مفيدة ، فهي أقل قيمة بشكل ملحوظ إذا كانت بيئة العمل الحالية تتم صيانتها بالفعل من خلال pip-compile + pip-sync ، أو pipenv lock + pipenv install .

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

مرحبا جميعا.

لقد كسرت بعض تبعيات حزمة Python الخاصة بي بسبب الأمر التالي:

pip install --upgrade packageName بترقية الحزم بشكل متكرر.

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

وماذا عن هذا ؟

sebma أعتقد أنه لا ينبغي تغيير السلوك الافتراضي. ربما يمكنك محاولة استخدام العلم -no-dependencies في المرة القادمة. يجب أن تعمل: +1:

sebma ، سأعلم كلاكما أنه قد تقرر بالفعل أن استراتيجية الترقية الافتراضية ستتغير في المستقبل (المرجع: https://github.com/pypa/pip/issues/3871# الإصدار 247789343). تمت إضافة الميزة الضرورية (مثل الوسيطة --upgrade-strategy ) في https://github.com/pypa/pip/pull/3972.

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

لقد أصدرت أداة ترقية تفاعلية لطيفة لملف المتطلبات: https://github.com/simion/pip-upgrader

قم بتحويل استراتيجية الترقية الافتراضية إلى فقط إذا لزم الأمر.

4500 فعل هذا.

إضافة وظيفة "ترقية العالم" التي تعتمد على # 988.

4551 للمناقشة حول هذا.

معالجة النقاط الواردة في الوظيفة العليا الحالية:

ستكون ترقية النقطة مثل تثبيت النقطة - الترقية إلا أنها ستكون غير متكررة افتراضيًا (وتقدم خيارًا متكررًا). لقد تسبب سلوكها الافتراضي المتكرر الحالي في حزن الكثيرين (# 304). بالنسبة لكيفية إجراء ترقيات غير متكررة الآن ، انظر هنا.

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

ترقية النقطة - الكل من شأنه ترقية جميع الحزم المثبتة.

4551 موجود وسيكون من الجيد إجراء مناقشة جديدة حول هذا الموضوع ؛ عندما ينتهي # 988.

dstufftxavfernandezpfmoore هل أي من كنت تعتقد أن يجب إغلاق هذه القضية؟

_{تعديل (2018/05/18): تمت إضافة علامات الترقيم + نص ثانوي}

يبدو معقولا.

اهلا جميعا،
لقد صنعت نصًا / جوهرًا بسيطًا يؤدي المهمة.

https://gist.github.com/serafeimgr/b4ca5d0de63950cc5349d4802d22f3f0

لماذا لا تفعل هذا ببساطة؟

pip install --upgrade $(pip list --outdated | awk '{print $1}' | tr '\n' ' ')

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

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

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

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

أعتقد أن pipenv & pipfile ستحل محل pip / requirements.txt على أي حال.
ربما يعرف kennethreitz المزيد عن خارطة الطريق وميزة --upgrade all.

qoheniac | tr ... زائدة عن الحاجة.

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