متفق. السلوك الحالي للنقطة لروابط التبعية سيء حقًا.

4295

3610

[كتبت في # 3939 ، نقل تعليقي هنا]

إذن ، هذه هي المشكلة الرئيسية: إذا كنت لا أرغب في استخدام ملف requirements.txt (لأنني ، على سبيل المثال ، أريد تبعيات توضيحية كلها محددة في setup.cfg ) ، فكيف لي أن أحدد URL كتبعية؟

هذا لا يعمل:

[options]
install_requires = 
  requests==2.18.4
  https://github.com/example/example_lib/archive/master.zip

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

هناك مشكلة أخرى وهي أنه لا يمكن تحديد dependency_links ما يبدو في setup.cfg ، فقط كوسيطات setup.py. إذا كانت غير مهينة ، فيجب إصلاح ذلك.

هل هناك أخبار بخصوص هذا؟ هل هناك أي بديل قيد التقدم؟ يبدو أن التبعية_الارتباطات_ هي الخيار الوحيد للتوزيع الداخلي / الخاص للمكتبات.

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

لا أعتقد أننا وحدنا: https://stackoverflow.com/questions/3472430/how-can-i-make-setuptools-install-a-package-thats-not-on-pypi

أدوات robertour مثل devpi تدعم نهجًا أكثر وضوحًا منذ سنوات حتى الآن

dstufft راجع للشغل - أود أن أزعم أن وجود devpi يوضح حلاً أكثر وضوحًا للمشكلة التي تجعل روابط التبعية غير ضرورية

وراثة مؤشر IMHO + القائمة البيضاء / القائمة السوداء أكثر اتساقًا وأكثر قابلية للفهم على مستوى العمليات

RonnyPfannschmidt ، شكرًا على الاقتراح ، يبدو أنني reddit :

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

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

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

4175 يعني أن دعم URL لـ PEP 508 سيكون موجودًا في النقطة 10. أعتقد أنه يمكن إغلاق هذا.

أفكارpfmooredstufft؟

اعتقدت أن https://github.com/pypa/pip/pull/4175/commits/86b07792e7ae762beeaeb471ab9db87e31bc285d يعني أنه لا يمكن استخدام بناء الجملة @ للتبعيات ، لذلك هذا يعني أن # 4175 ليس حلاً لهذه المشكلة . كانت التعليقات هناك مفادها أنه لا ينبغي لنا تنفيذ دعم @ للاعتماديات حتى يتمكن PyPI من حظر التحميلات التي استخدمته (لأننا لا نريد تثبيت شيء من PyPI حتى نتمكن من انتزاع الأشياء من عناوين URL التعسفية ، محتمل).

لا ينبغي إهماله حتى يتوفر بديل ، أي دعم PEP 508. حتى ذلك الحين ، يستخدمه الكثير من الناس.

ما هو سير العمل المناسب لذلك؟

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

الآن يتعين على جميع المستخدمين إضافة - ارتباطات عملية - تبعية - عند تثبيت أداتي باستخدام نقطة ، وهي علامة مهملة وحتى تمت إزالتها مرة واحدة؟

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

دعنا ننتقل إلى هذا.

لا يملك --process-dependency-links بديلًا اليوم. لذا ، سأقترح أن نمضي قدمًا وأن نلغي إهماله.

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

pradyunsg ما لم تكن هناك خطة فعلية

لا أعتقد أن الأشخاص الذين يحتاجون إليه فعلاً لديهم أي حافز لإصلاح الوضع ما لم يقول بيب "لا ، أنا لا أتحمل ديونك"

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

1. هل توجد حزم على PyPI تحتوي على بيانات وصفية dependency_links ؟
2. هل يمكن تعديل PyPI لرفض تحميل المشاريع ذات dependency_links (أم أنها تفعل ذلك بالفعل)؟
3. بدلاً من ذلك ، هل يمكن أن يرفض pip ببساطة معالجة ارتباطات التبعية (بغض النظر عما إذا تم تعيين الخيار) للحزم التي تم تنزيلها من PyPI؟

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

لذلك ، مع التغييرات التالية:

1. لن تقوم Pip أبدًا بمعالجة روابط التبعية من PyPI (إما بشكل صريح أو لمجرد أننا نعلم أنها غير موجودة)
2. علامة --process-dependency-links غير مهملة ، لكنها تعمل فقط مع الفهارس المخصصة.

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

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

في الأساس ، لدينا ميزة تهدف إلى استبدال روابط التبعية ، لكن pip لم تبدأ في احترامها بعد ، لأننا لا نملك حتى الآن طريقة لمنع التحميلات إلى PyPI التي تستخدمها.

هل تقصد # 4175؟ الذي تم حظره بسبب 86b0779؟ ربما يمكننا تعديل https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L167 لإعطاء الخطأ فقط إذا كان comes_from هو PyPI؟

ثم يمكننا تغيير تحذير الإيقاف لـ --process-dependency-links ليقول إنه يجب على المستخدمين التبديل إلى بناء جملة @ ، وإسقاط --process-dependency-links بعد فترة إهمال معقولة (علينا البدء الساعة تدق من النقطة التي يصبح فيها بناء الجملة @ متاحًا).

pfmoore نعم هذا هو بالضبط ، ويبدو أنه مسار محتمل للمضي قدمًا.

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

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

أنا أؤيد إسقاط دعم ارتباطات التبعية بالكامل خلال فترة الإيقاف. وفي الوقت نفسه ، إضافة دعم تبعية عنوان URL لـ PEP 508 ، والذي أعتقد أنه يجب أن تظل النقطة عالية جدًا عند استخدامها وأنه لا يزال يتعين عليها الاشتراك.

هذا يعني:

• وضع القدرة على معالجة PEP 508 url-deps خلف علم
  
  
  
  • جانبا: يجب تسمية العلم بحيث يقوم المستخدم المعني بالأمان بفحص المستندات
  
  
• البدء في رفض تثبيت PEP 508 url-deps عندما تأتي من حزمة PyPI
• تظل روابط التبعية مهملة ولكن لدينا تاريخ لإسقاطها
  
  
  
  • بصراحة ، لا أريد أن أعطي هذا فترة إهمال أطول من إصدار واحد يطبع البديل.
  
  

لقد كتبت ذلك بالأمس لكنني لم أرسله. أدرك الآن أنه في الأساس نفس الشيء مثل تعليقpfmoore الأخير.

_ياي!

هل يجب أن تتطلب عناوين URL علامة التمكين؟ PEP 508 لا يقول ذلك ، والتطبيق الحالي لا يفعل ذلك. يمكنني رؤية المنطق ، لكنني لا أثق في حكمي على أسئلة الأمان مقابل أسئلة سهولة الاستخدام.

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

لا أثق في حكمي على أسئلة الأمان مقابل أسئلة سهولة الاستخدام.

أميل إلى: "كن آمنًا بشكل افتراضي" والاشتراك في السلوك الأقل أمانًا.

وثائق واضحة حول كيفية تحويل المشاريع من روابط التبعية إلى @ syntax قبل أن نبدأ في الضغط على المفتاح

يبدو أمرا جيدا لي.

أميل إلى: "كن آمنًا بشكل افتراضي" والاشتراك في السلوك الأقل أمانًا.

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

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

نرى؟ ليس الأمر أنه ليس لدي آراء ، فقط لست متأكدًا من عدم ظهور تحيزاتي: ابتسم:

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

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

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

لست متأكدا هنا. : /

نرى؟ ليس الأمر أنني لا أملك آراء ، فقط لست متأكدًا من عدم ظهور تحيزاتي 😄

هيهي.

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

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

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

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

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

في عملي ، نقع في بعض حالات الاستخدام pfmoore المذكورة ، أي التطوير الداخلي قبل أن تكون الحزمة مفتوحة المصدر ومغلقة المصدر وما إلى ذلك (دائمًا الحزم الداخلية اعتمادًا على الحزم الداخلية الأخرى ، وكلها في خادم التحكم في الإصدار ).
على الرغم من أنني أرى أيضًا حالة الاستخدام المحتملة لشخص يشير إلى موقع نظام الملفات ...
هل من المنطقي تقديم قائمة بالمضيفين / المواقع المدرجة في القائمة البيضاء؟ يجب أن يكون اسم العلم IMO ، كما اقترح pradyunsg ، وصفيًا بما يكفي لجعل المستخدم على دراية بالمخاطر التي تنطوي عليها. ربما --whitelisted-host ؟

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

يبدو أننا سنمضي قدمًا في علاقات عامة تقوم بما وصفه https://github.com/pypa/pip/issues/4187#issuecomment -389846189.

ترحيب PRs. :)

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

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

هناك اختبار موجود test_install_pep508_with_url_in_install_requires يوضح ذلك.

بالنسبة للخطأ عند التثبيت من PyPI ، لا أرى خيارًا أفضل من تحميل شيء ما فعليًا على PyPI له متطلبات عنوان URL. 😞 قمت بتحميل حزمة على PyPI لهذا الغرض. https://pypi.org/project/pep-508-url-deps/

شيء آخر - comes_from ليس عنوان URL أو مسارًا ، إنه سلسلة على طول خطوط 'box==0.1.0 from file:///private/tmp/box' . أيًا كان من يتطلع إلى إصلاح هذه المشكلة ، فعليه الآن اكتشاف طريقة أفضل لحل هذه المشكلة ، حتى يكون لدينا معلومات حول مكان نشأة الحزمة. :)

pfmoore هذه المشكلة قريبة وعزيزة على قلبي 😄 هل يمنحك تحميل

bstrdsmkr كلا ، وكما يقول pradyunsg ، الأمر ليس بهذه البساطة كما اعتقدت ، لأن comes_from ليس عنوان URL المصدر. لذلك لا أعرف متى سيكون لدي الوقت الآن (ليس لدي استخدام شخصي لهذه الميزة ، لذا فهي ليست على رأس قائمة أولوياتي).

كما هو مذكور أعلاه ، نرحب بالعلاقات العامة :-)

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

ما أفهمه هو أن الإصلاح المطلوب هو شيء مثل:

if req.url and is_like(req.url, PYPI.url):
    raise

في https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L172
حيث يقوم is_like() بإرجاع True إذا كان جذر عناوين url في نفس المجال. هل هذا صحيح؟

بلى. اعتقد ذلك. سيكون هذا هو رمز التغيير.

وسنحتاج إلى إضافة / تحديث الاختبارات وإدخال NEWS.

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

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

لا ، هناك ثقة صريحة. وإضافة إجراءات وقائية ضد استخدام المصادر الخارجية في التبعيات لن يؤدي IMHO إلى تحسين الموقف: فهو أكثر ملاءمة لإخفاء البرامج الضارة في pypi مقارنةً بـ VCS المتاح للجمهور.

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

0 تسجيل

dev -- public key --> pypa

1 تحميل

setuptools -- git+https:/.... --> pypa
pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks the signature matches the dev

2 خامل:

pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks it

2 استرجاع

flips a coin
if coin == 1:
  pip -- give me package git+https:/... --> pypi
  pip <-- signature || content -- pypi
  pip -- give me the signature --> vcs
  pip <-- signature -- vcs
else:
  pip -- give signature of package git+https:/... --> pypi
  pip <- signature -- pypi
  pip --> Tor --> give me that commit --> vcs
  pip <-- Tor <-- here -- vcs


pip checks if the signature matches the public key and signature from pypa
pip -- give me public key --> keyserver
pip <-- PK -- keyserver
pip checks signature given by VCS against the sdist given by pypy
pip caches public key and repo location

1 تتطابق المصادر المثبتة مع تلك الموجودة في VCS بسبب التوقيع
2 يتطابق المؤلف أيضًا
يمكن لـ 3 pypa الغش مع المستخدمين الجدد ، ولكن قد يتم اكتشاف الغش بواسطة المستخدمين القدامى
4 يمكن للمؤلف الغش من خلال إظهاره في فرع واجهة الويب بخلاف ما يُعطى لـ pypy وإرساله إلى pypy فرع آخر. لن تعمل بشكل جيد إذا جعلنا الفرع جزءًا إلزاميًا من URI.

KOLANICH أعتقد أنك تقصد PyPI (فهرس تغليف Python) عندما تقول pypy / pypa. PyPy هو تطبيق بديل لـ Python. PyPA (Python Packaging Authority) عبارة عن مجموعة من المتطوعين الذين يحتفظون بمشاريع كبرى في مساحة Python Packaging. من فضلك ، تصحيح الاختصارات أو الامتناع عن استخدامها.

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

يتم صيانة PyPI بواسطة متطوعين ، ويعملون على البنية التحتية المتبرع بها / المدعومة. أنت تقترح أن تتصل عبر Tor ، وهو متطوع آخر يدير / يدير الخدمة. كلاهما مشروعان كبيران ولهما تكلفة مرتبطة بإبقائهما قيد التشغيل ، على الرغم من أنه ليس بورن بشكل مباشر / مرئي لمستخدميه.

ومع ذلك ، ليس هذا هو المكان المناسب لهذه المناقشة. إذا كنت ترغب في اقتراح إعادة تصميم PyPI ، أقترح أن تبدأ المناقشة من جديد على https://github.com/pypa/warehouse.

شكرا لاقتراحك.

انظر # 5571 - العلاقات العامة لهذا السبب تم دفعه إلى إصدار لاحق.

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

علاوة على ذلك ، هذا أمر محير أكثر: ماذا تقصد عندما تقول PyPI؟ هل تقصد أي خادم يقوم بتنفيذ واجهة PyPI (مثل Artifactory) ، أو على وجه التحديد ، pypi.org؟

الآن ، من الواضح أن الشخص الذي يريد دعم تثبيت حزمة من خلال setuptools (ويعرف أيضًا باسم setup.py install ) ومن خلال استخدام pip install سيكون الآن في مأزق. تحديد روابط التبعية هو الطريقة الوحيدة لشخص ما في هذه الحالة للتعامل مع حزم مترابطة متعددة.

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

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

@ wvxvw-traiana أعتقد أنك فاتتك PR # 5571
قبل ذلك PR (وفي الإصدار الحالي - 18.0) سوف ترفض النقطة تثبيت أي تبعية محددة عبر صيغة PEP508.

بعد ذلك ، فإن العلاقات العامة (مدمجة بالفعل لذا يجب أن تكون في 18.1+) سوف ترفض النقطة فقط مثل هذه التبعيات إذا كانت الحزمة التي تعتمد عليها تأتي من pypi.org.

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

آمل ان هذا أوضح الأمور

bstrdsmkr هل هو نفس الأصل أم أن pypi حالة خاصة؟ بمعنى آخر

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

لإضافة مزيد من السياق حول الأسباب الكامنة وراء ذلك:

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

الشخص الذي يريد دعم تثبيت حزمة من خلال setuptools (المعروف أيضًا باسم تشغيل setup.py install) ومن خلال استخدام تثبيت النقطة ، سيكون الآن في مأزق.

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

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

هذا يعمل بشكل جيد. لا تشارك PyPI.

حسنًا ، من ناحية ، أنا سعيد لأن هذا لا يؤثر علي.

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

echo "not-pypi 151.101.61.63" >> /etc/hosts
pip install --index-url not-pypi

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

لم يتم تصميمها بحيث يصعب على المستخدمين حلها بواسطة المستخدمين. إنها وسيلة لتقديم حل (محدود) لحقيقة أن PyPI ليس لديها حتى الآن طريقة لمنع الأشخاص من تحميل الحزم ذات التبعيات المباشرة لعناوين URL. راجع https://github.com/pypa/pip/pull/4175#issuecomment -266305694 للحصول على بعض السياق.

dpwrussell pypi.org حالة خاصة. أي ريبو خاص لأي ريبو خاص يعمل بشكل جيد بعد التغيير.

@ wvxvw-traiana ، لا يعني ذلك منعك من القيام بذلك بنفسك. من المفترض أن تمنع شخصًا آخر من فعل ذلك لك عندما تعتقد أنك تقوم فقط بتثبيت حزمة من pypi.org

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

يضيف 5726 لغة تشير إلى استخدام عناوين URL لـ PEP 508 ، والتي تعد IMO هي آخر بت مطلوب لهذا الغرض.

حسنا إذا. اسمحوا لي أن ألخص:

• لا تزال روابط التبعية مهملة ومن المقرر الآن إزالتها في النقطة 19.0.
• الاستبدال القياسي المدعوم له هو تبعيات عنوان URL لـ PEP 508
• عند التثبيت من PyPI ، إذا كانت الحزمة تحتوي على تبعيات عنوان URL لـ PEP 508 ، فسيؤدي ذلك إلى إحباط التثبيت من نقطة.

أوضحpfmoore أسباب هذه القرارات هنا: https://github.com/pypa/pip/issues/4187#issuecomment -415067034

pradyunsg متى سيتم install_requires في setup.py؟ هل هناك موعد محدد؟

في الإصدار التالي من النقطة - 18.1 ، المقرر في أكتوبر. يمكنك قراءة المزيد حول دورة إصدار البيب لمدة 3 أشهر على https://pip.pypa.io/en/latest/development/release-process/. :)

يجب معالجة https://github.com/pypa/wheel/issues/249 قبل أن تصبح تبعيات عنوان URL لـ PEP 508 بديلاً قابلاً للتطبيق.

يجب معالجة pypa / wheel # 249 قبل أن تصبح تبعيات عنوان URL لـ PEP 508 بديلاً قابلاً للتطبيق.

لقد تم تناول هذا الأمر.

جاء في الملاحظات الإصدار 18.1

السماح باستخدام متطلبات عنوان URL لـ PEP 508 كعناصر تبعيات.

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

يعني هذا أساسًا أنه يمكن تحديد التبعيات باستخدام عناوين URL ، ولكن إذا لم تكن هذه عناوين URL لـ PyPI ، فلا يمكن تثبيت الحزمة باستخدام pip؟ ربما أكون مخطئًا تمامًا ، ولكن كيف يُفترض أن تُستخدم تبعيات عنوان URL بعد ذلك؟

لا يمكن أن تحتوي حزم

يمكن أن تحتوي الحزم غير المستضافة في PyPI على تبعيات عنوان url. إذا قمت بتثبيت الحزمة مباشرة من github (على سبيل المثال) ، فسيتم حل وتثبيت تبعيات عنوان url. مثال على هذا التثبيت:

pip install git+https://github.com/bstrdsmkr/some_package.git

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

إضافة ثانوية:

... إذا قمت بالتثبيت من عنوان url ، فيمكن أن يعتمد على عناوين url

... إذا قمت بالتثبيت من عنوان URL (VCS أو غير ذلك) أو ملف محلي أو فهرس حزمة ليس PyPI ، فيمكنه ...

فهل هناك نسخة من النقطة التي تعالج install_requires وفقًا للأوصاف أعلاه؟ لا يمكنني حل العلامات فوق الحالة النهائية وتشير وثائق النقطة الحالية إلى وثائق install_requires في setuptools التي لا تزال تقول استخدام dependency_links .

لا يمكنني التحدث إلى المستندات بنفسي ، ولكن تم إصدار هذا "الاسترخاء" للسماح للحزم التي لا تنتمي إلى PyPI بتثبيت التبعيات من عناوين url في النقطة 18.0

AFAIK ، تبعيات URL في install_requires مدعومة منذ النقطة 18.1:

السماح باستخدام متطلبات عنوان URL لـ PEP 508 كعناصر تبعيات.

المصدر: ملاحظات الإصدار

آه ، خطأ مطبعي من جانبي - من الواضح أن pietrodn صحيح

أريد أن أترك هنا مثالًا صغيرًا ولكنه ناجحًا لأولئك الذين واجهوا هذه المشكلة لأول مرة وهم مرعوبون (مثلي) بشأن ما يجب فعله مع روابط التبعية الخارجية. باستخدام سير العمل هذا ، يمكن للمستخدمين الآن تثبيت التثبيت من GitHub أو من المصادر المحلية (وليس PyPI) ، أو تثبيت متطلبات التثبيت. txt ، أو تثبيت python. الإصدار 18+ ، لذلك أعتقد أنه يغطي الكثير من القواعد. آمل أن يكون مفيدًا لشخص ما ، وأعتذر إذا بدا هذا خارج الموضوع للآخرين:

في ملف requirements.txt الخاص بك ، بافتراض أنك تريد أن يتمكن الأشخاص من الاعتماد على فرع GitHub dev من الحزمة "foo" ، على سبيل المثال:

scipy>=0.17
matplotlib>=2.0
foo @ git+https://github.com/foo-organization/foo@dev#egg=foo-9999

في ملف setup.py الخاص بك:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

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

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

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

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

أنت تخلط بين install_requires setup_requires .

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

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

مرحبًا يا رفاق ، أود فقط أن أشير إلى أن مسار الإيقاف في هذه الحالة كان قصيرًا جدًا. أعلم أنه تم وضع علامة على روابط التبعية على أنها مهملة لبعض الوقت ، لكن عناوين URL لـ PEP 508 ، والتي يمكن استخدامها لاستبدالها ، لم يتم تنفيذها حتى 18.1. نتيجة لذلك ، لم يكن هناك سوى فترة 3 أشهر للتبديل من روابط التبعية إلى متطلبات URL ، وهو وقت قصير جدًا للمشاريع الكبيرة.

rgerkin مرحبًا ، أحاول اتباع تعليماتك دون جدوى ،

البحث عن PACKAGE @ git + ssh: //[email protected] : OWNER / PACKAGE. بوابة @ فرع
قراءة https://pypi.org/simple/PACKAGE/
تعذر العثور على صفحة فهرس لـ "PACKAGE" (ربما بها أخطاء إملائية؟)
فهرس المسح لجميع الحزم (قد يستغرق ذلك بعض الوقت)
قراءة https://pypi.org/simple/

PACKAGE @ git + ssh: //[email protected] : OWNER / PACKAGE. git @ BRANCH ، هذا في install_requires.

هل لديك فكرة عن سبب حصولي على ما ورد أعلاه؟

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

لملاحظة شيء وجدته: استخدام setup.py لتثبيت الحزمة مع python setup.py install لا يزال يتطلب تصريحات التبعيات الخارجية في dependency_links .

في ملف setup.py الخاص بك:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

rgerkin شكرا لتقاسم هذا الحل. ولكن ماذا لو كنت أستخدم pbr لإعداد حزمة Python الخاصة بي؟ كيف تتكيف مع هذا لتناسب pbr؟

KevinMars لدي نفس المشكلة بالضبط. هل سبق لك أن اكتشفت الإصلاح؟ أحاول أن أطلب فرعًا معينًا من ريبو bitbucket خاص عبر SSH.

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