@ ccuranusjrncoghlanaltendkynjsmith _ _

أنا مقتنع بأن هذا شيء يحدث بشكل شائع (وكيل الشركة FW / التخزين المؤقت) - أشعر أننا بحاجة إلى إعداد تجاوز لتحديد مرآة لاستخدامها بدلاً من pypi إذا وجدناها في ملف الأنابيب - مثل PIPENV_PYPI_MIRROR أو PIPENV_PYPI_CACHING_PROXY أو شيء من هذا القبيل لتحديد أنه يجب تجربته أولاً ، مقسم إلى sources أمام pypi بشكل أساسي.

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

سأبدأ بملاحظة تحذير: حتى تنفذ PyPI آلية توقيع الحزمة المشابهة لـ PEP 458 لتوفير طريقة مستقلة عن TLS مقابل pip للتأكد من أن الحزم التي تنشأ اسميًا من PyPI تتطابق فعليًا مع ما نشرته PyPI ، فإن تقديم القدرة على إعادة توجيه حركة المرور بشفافية إلى خادم مختلف أمر يتعلق حقًا من منظور أمني.

لسوء الحظ ، فإن متجه الهجوم هذا مفتوح بالفعل عن طريق pip.conf ، لذا فإن تقديم شيء مشابه على المستوى pipenv لن يجعل أي شيء أسوأ مما هو عليه بالفعل.

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

pipenv --override-source-url 'default=https://pypi-proxy.example.com/api' --override-source-url 'https://pypi.python.org/simple=https://pypi-proxy.example.com/api'  --override-source-url 'https://pypi.org/simple=https://pypi-proxy.example.com/api' install

(البت الوحيد المحدد لـ PyPI هو استخدام "افتراضي" للإشارة إلى مصدر التنزيل الافتراضي للنقطة ، كما هو محدد في pip.conf ).

قد يكون توضيح خريطة تجاوز عنوان URL المصدر بالكامل في كل مرة أمرًا غير عملي للاستخدام في الممارسة العملية ، لذلك قد يبدو خياران لسكر CLI كما يلي:

pipenv --override-source-urls <config file> install

pipenv --pypi-mirror https://pypi-proxy.example.com/api install

ما إذا كان عرض طبقة --override-source-url على الفور أم لا هو سؤال مختلف - فقد يكون من المنطقي تنفيذ الخيار الأبسط --pypi-mirror أولاً ، مع الاحتفاظ بإمكانية --override-source-url و --override-source-urls كخيارات مستقبلية محتملة في الاعتبار أثناء القيام بذلك.

كان رسم الخرائط العامة {given URL: override URL} هو أول ما فكرت به أيضًا ، ولكن عند مزيد من الدراسة ، هناك بعض الحجج الخاصة بـ PyPI ذات الغلاف الخاص:

• تعد PyPI فريدة جدًا من حيث امتلاكها عنوان URL عام معروف والكثير من المرايا

• يحتوي PyPI بالفعل على عدة عناوين URL (على سبيل المثال ، من المحتمل أن يكون لدينا ملفات Pipfiles تطفو لفترة من الوقت باستخدام كل من https://pypi.python.org/simple و https://pypi.org/simple ، وربما أيضًا https://pypi.python.org/simple/ و https://pypi.org/simple/ مع الشرطة المائلة اللاحقة؟) ، وسيكون من الجيد أن نتمكن من حل هذه المشكلة مرة واحدة بدلاً من إجبار كل مستخدم على اكتشافها بنفسه

njsmith شاهد اقتراح sugar --pypi-mirror <URL> في الجزء الأخير من رسالتي - إذا كان التنفيذ الأولي يركز فقط على ذلك ، فيمكن عندئذٍ أن تبدأ إمكانية إعادة كتابة عنوان URL العامة كتفاصيل تنفيذ داخلية (مدفوعة بحقيقة أن " لدى PyPI "عناوين URL متعددة يتم حلها جميعها في النهاية إلى نفس المكان) ، ثم يتم اعتبارها للعرض كميزة في حد ذاتها لاحقًا (بعد التأكد من أنها تعمل على النحو المرغوب فيه للاستخدام الأساسي --pypi-mirror قضية).

آه ، صحيح ، فاتني ذلك :-)

هل هناك قاعدة عامة لتعيين وسيطات سطر الأوامر لنوع من التكوين الأكثر ثباتًا؟ أتخيل أن معظم مستخدمي هذا يريدون إعداده مرة واحدة ثم نسيانه.

كتب ncoghlan :

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

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

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

يختلف تغيير عنوان URL الافتراضي للفهرس (أو إضافة عنوان URL إضافي للفهرس) في pip.conf ، أو استخدام ميزة التجاوز المقترحة هنا من خلال ملف تكوين أو آلية قائمة على ملف تعريف shell: وهذا يعني "أنا ، أو بعض العمليات التعسفية I تم تشغيله في وقت ما مع حق الوصول للكتابة إلى دليلي الرئيسي (مثل ملف setup.py الخاص بـ sdist) ، وقررت تكوين إعداداتي للثقة في مصدر الحزم هذا ". وحتى مخطط التوقيع مثل PEP 458 ليس دفاعًا كاملاً ضد تلك الأنواع من الخدع إذا كانت المفاتيح العامة المستخدمة للتحقق هي نفسها مخزنة في مكان ما داخل دليلك الرئيسي بدلاً من دليل يتطلب امتيازات مرتفعة للتعديل.

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

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

كانت مخاوف pep 458 هي في الأساس ما كان يدور في ذهني ، نظرًا لأن الأشياء التي تكون عناوين url مختلفة ولكن في الواقع في pypi تختلف عما إذا قمت بنسخ pypi محليًا وادعت أنها كانت نفسها.

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

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

njsmith هذا أيضًا نموذج تهديد pip ، لأن تثبيت الحزمة يتطلب تنفيذ رمز تعسفي من ملفات sdist setup.py مسموح بها. يمكن لهذا الرمز بالفعل الكتابة فوق الأشياء الموجودة في دليلك الرئيسي مثل الإعدادات الخاصة بك ، أو إضافة أشياء إلى مسارك ، أو أي عدد من الأشياء. هذا هو السبب في أن منح امتياز صريح لـ pypi (فهرس معروف وموثوق) والمطالبة بفحص التجزئة يعد خطوة جيدة نحو الأمان. يسمح بالتحكم المركزي والقضاء على تهديدات الأمان المعروفة وتحديد التحقق من الحزم التي تقوم بتنزيلها بطريقة موزعة. ماذا قال ملف القفل الذي قمت بتنزيله عن التجزئة التي يجب أن تحصل عليها؟ لا يتطابق مع ما تحصل عليه من الفهرس؟ لكي يفشل وضع التشغيل هذا ، يجب أن يكون لديك إخفاقات في أكثر من جهاز محلي ، وفهرس وطبقة شبكة لأنك تتحدث عن وجود حزم تالفة متعددة في حزمة التطبيقات الخاصة بك تعمل في تجزئات التحقق من الحفلة مقابل فهرس موثوق ، وفي كثير من الحالات ، جاءت التجزئة نفسها من مصدر آخر غير متورط. إذن أنت الآن بحاجة إلى أن يكون لديك على الأقل ، كل عمليات التحقق من التجزئة في كل من pip و pipenv تم العبث بها بطريقة ما بحيث تولد تجزئات مطابقة لتلك التي تأمل فيها ، ولكن هل تقوم بتثبيت أشياء ضارة أخرى؟

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

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

techalchemy لا أرى أي صلة بهذا الموضوع على الإطلاق؟ أعتقد أن استنتاج كل ما سبق هو أن السماح للمستخدمين بتجاوز استخدامات pipenv المتطابقة لـ PyPI لا يؤدي إلى أي تهديدات إضافية ، والقيام بـ sudo pipenv لا معنى له في المقام الأول ، أليس كذلك؟

njsmith لا ، لا أعتقد أنه يجب على أي شخص استخدام sudo pipenv ، كما ذكرت أنه لا يتعلق بالموضوع حقًا ولكن نظرًا لأننا ذهبنا قليلاً في مسار نموذج التهديد ، اعتقدت أنه يستحق الاستكشاف. على وجه التحديد:

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

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

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

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

حسنًا ، لنحدد السلوك الذي نتوقعه أو نفضله. فهم عملي الحالي هو أن:

• إذا تم تمرير --pypi-mirror أو تم تعيين PIPENV_PYPI_MIRROR ، فإننا نفضل ذلك
• هل يجب أن نفضله على PyPI فقط؟ كيف نجري تقييم ما إذا كان عنوان url الخاص بالفهرس هو "PyPI" - لا يمكننا الاستعلام عنه ، لذلك يتعين علينا الاحتفاظ بقائمة
• هل يجب أن تحتوي القائمة على جميع التباديل الممكنة ، أم يجب أن نكتفي باستخدام عنواني url اللذين استخدمناهما في الماضي لتوليد ملفات Pipfiles كأشياء يجب أن نجرب المرآة المتوفرة من أجلها أولاً؟

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

يبدو أنه النهج الصحيح بالنسبة لي.

ما قالهnjsmith يطابق وجهة نظري أيضًا. عناوين URL الثلاثة للريبو التي أقترح استبدالها في PR الأولي ستكون:

• لم يتم تعيين أي شيء (أي عند الاعتماد على الإعداد الافتراضي لـ pip )
• https://pypi.python.org/simple
• https://pypi.org/simple

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

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

حسنًا ، كان تفكيري:

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

مدهش. أعتقد أن هذا يكفي للعمل به وبسيط بما يكفي للبناء. شكرا لكم جميعا!

يمكن إضافة ميزة مرآة الأمل قريبا ~

أنا أواجه هذه المشكلة أيضًا. الوضع هو:

• لديك خادم PyPI داخلي مع بعض الحزم الخاصة.
• لديك العديد من تطبيقات Python التي تستخدم Pipenv لإدارة تبعياتها.
• بعض التبعيات تعيش على خادم PyPI الداخلي ، والبعض الآخر على مجتمع PyPI. يقوم الشخص الداخلي بإعادة التوجيه إلى مجتمع PyPI لأي حزم غير موجودة.

تقوم إستراتيجية النشر الخاصة بي بالفعل بإعداد pip.conf على مستوى النظام والذي يشير إلى خادم PyPI الداخلي. والمثير للدهشة أنني وجدت أن Pipenv يتجاهل هذا التكوين.

ألاحظ أنه إذا كنت سأقوم بنقل / إعادة تسمية PyPI البيني ، فسيتعين تحديث العديد من التطبيقات مع Pipfiles وإعادة إنشاء ملفات Pipfile.lock الخاصة بهم. سيوفر خيار المرآة الوظيفة المطلوبة. سيعمل أيضًا ويشعر بأنه أقل زائدة عن الحاجة إذا كان بإمكان Pipenv قراءة تكوين النظام لـ Pip.

ترحيب PRs في هذا واحد بالمناسبة

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

هذا هو اقتراح سلوكي المتوقع:

• يمكن تعريف ملف التكوين لتعيين كل قيمة محددة في قسم [[المصدر]] من ملف Pipfile.
• يمكن أن يكون ملف toml يحتوي فقط على قسم [[المصدر]] من ملف Pipfile
• موقع هذا الملف مستوحى بشكل كبير من القواعد المحددة لـ pip.conf (على سبيل المثال: /etc/pipenrc.toml، ~ / .pipenvrc.toml
• يمكن أيضًا تعريف متغيرات البيئة لتجاوز هذه القيمة (تذكير: نحتاج إلى كل قيمة [[المصدر]]). يعرف ب
• السلوك الحالي لـ pipenv الآن هو:
  
  
  
  • عند إنشاء ملف Pipfile ، فإنه يأخذ القيم من ملف التكوين / متغير البيئة
  
  
  • إذا لم يتم تحديد ملف تكوين أو متغير بيئة ، فسيتم تطبيق السلوك الحالي لـ pipenv
  
  
  • يستمر pipenv دائمًا في إنشاء قسم [[المصدر]] من ملف Pipfile
  
  
  • في حالة وجود قسم [[مصدر]] من ملف Pipfile ، لا يحاول pipenv تجاوز القيم من ملف التكوين على الإطلاق.
  
  

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

كملاحظة جانبية: نحن نستخدم pipenv بشكل كبير في الإنتاج الآن ، لكني أحتاج إلى تذكير الجميع في كثير من الأحيان أنهم بحاجة إلى تغيير ملف Pipfile يدويًا عند بدء مشروع جديد للوصول إلى مستودع Arrifactory Pypi (للحصول على معلومات ، تقوم Nexus أيضًا بعمل Pypi ذاكرة التخزين المؤقت مجانًا و t يعمل بشكل رائع!). لدينا جدار حماية محدود للغاية ومن الممارسات الجيدة جدًا داخل الشركة تخزين التبعيات الخارجية مؤقتًا ، بحيث يمكن نسخها احتياطيًا وفحصها بحثًا عن نقاط الضعف على سبيل المثال.
إذا كانت هناك ميزة بسيطة مشابهة لملف التكوين العام أو المستخدم (مثلما نفعل بالفعل لـ pip أو npm) ، حتى نتمكن من نشرها على جميع محطات العمل لدينا حتى يرتكب مطورونا أخطاء أقل ، فسيكون ذلك مثاليًا بالنسبة لي)

ربما فاتني شيء ما ، لكن هذا يبدو وكأنه تراجع. لقد كنا على 11.6.0 لفترة من الوقت ، ولحسن الحظ فوضنا pipenv للإعدادات الموجودة في pip.conf ، والتي تشير إلى مرآة pypi داخلية.

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

للتوضيح: بعد الترقية إلى 2018.05.18 ، يحاول pipenv تثبيت حزم جديدة من pypi.org ، حتى مع وجود المرآة المحددة في ملف Pipfile [.lock] الخاص بنا.

ربما ما أراه هو مشكلة منفصلة عن هذه ...

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

أنا أعمل على العلاقات العامة لهذا الغرض.

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

أفترض أنك تتحدث عن استخدام devpi كوكيل تخزين مؤقت لـ PyPi الرسمي. بالنسبة للنقطة نفسها ، ستحتاج إلى تعديل /etc/pip.conf و /usr/lib64/python3.6/disutils/distutils.cfg للنقطة لاستخدام خادم devpi المحلي لجميع الطلبات.

ومع ذلك ، يبدو أن pipenv يتجاهل هذه الإعدادات على مستوى النظام ، لذلك تضطر إلى تعديل إعداد [[source]] config في ملف Pipfile للإشارة إلى خادم devpi الخاص بك. ولكن بعد ذلك ، إذا قمت بنشر Pipfile خارجيًا ، فيجب على المساهمين الخارجيين إزالة إعدادات [[source]] لإنشاء بيئتهم الخاصة بالفعل.

أعتقد أن pipenv يجب أن يحترم فقط الإعدادات العامة من /etc/pip.conf و /usr/lib.../distutils.cfg

@ polski-g

أفترض أنك تتحدث عن استخدام devpi كوكيل تخزين مؤقت لـ PyPi الرسمي

مستودع Nexus ، ولكن نعم ، نفس الفكرة.

ومع ذلك ، يبدو أن pipenv يتجاهل هذه الإعدادات على مستوى النظام

كما ذكر techalchemy ، أعتقد أن pipenv (11.6.0) يستخدم لاحترام pip.conf (homedir أيضًا) ، لكن الإصدار الأخير لا يفعل ذلك - على وجه التحديد ، هناك عنوان URL pypi.org مشفر في مكان ما (التبعية) القرار ، IIRC) التي لا يمكن تجاوزها.

أعتقد أن pipenv يجب أن يحترم فقط الإعدادات العامة من /etc/pip.conf و /usr/lib.../distutils.cfg

متفق عليه - على الرغم من أنني شخصيًا لم أضطر إلى تعديل distutils.cfg في حالة الاستخدام الخاصة بي.

IIRC كان هناك قرار بعدم احترام pip.conf ، لكنك ستحتاج إلى البحث بعمق في أداة تعقب المشكلة للعثور عليها. على أي حال ، فإن السفينة قد أبحرت ، ومع تقارب PyPI على الانتهاء ، من غير المرجح أن يتغير هذا في المستقبل القريب.

أنا واثق تمامًا من أن هذه الميزة سيتم شحنها في الإصدار التالي (والذي سيتم شحنه في اليوم أو اليومين التاليين مع الحظ)

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

https://github.com/pypa/pipenv/blob/master/pipenv/project.py#L573 - # L577

uranusjr طالما أن تكوين الانعكاس يعمل (أي لا يستخدم عنوان URL pypi.org المشفر الذي ذكرته) ، لا أرى أي مشكلة في أن يكون لـ pipenv تكوينه الخاص لهذا الغرض وتجاهل pip.

brettdh هل ستكون قادرًا على تسجيل الخروج من فرعي والتأكد من أنه يلبي احتياجاتك
حالة الاستخدام في بيئتك؟

>

تضمين التغريدة يبدو أن الاختبار الأولي الخاص بي باستخدام الخيار --pypi-mirror ( pipenv install ، pipenv lock ) يعمل بشكل جيد. تركت اقتراحًا صغيرًا على العلاقات العامة.

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

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

لقد سحبت للتو النسخة الأخيرة وما زالت ترميز pypi.org في المصادر. هل الهدف هو أخذ المتغير البيئي أو مرآة pypi ووضع ذلك على أنه الخيار الافتراضي لـ [[المصدر]]؟

تعديل:

حفرت للتو من خلال الكود .. يبدو أن لديك

if PIPENV_TEST_INDEX:
    DEFAULT_SOURCE = {
        u"url": PIPENV_TEST_INDEX,
        u"verify_ssl": True,
        u"name": u"custom",
    }
else:
    DEFAULT_SOURCE = {
        u"url": u"https://pypi.org/simple",
        u"verify_ssl": True,
        u"name": u"pypi",
    }

أعتقد أنك إذا غيرت ذلك إذا كان PIPENV_TEST_INDEX إلى المتغير البيئي PIPENV_PYPI_MIRROR فسيكون ذلك بداية جيدة

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

لا ، يجب ألا يتغير المصدر في ملف Pipfile. الهدف من هذا التغيير
هو السماح للمستخدمين بإلغاء عناوين URL لـ PyPI بنسخة متطابقة ، بدون تغيير
ملف Pipfile.

JacobHenner تعالج كود معالجة النسخة المتطابقة قائمة المصدر وتستبدل عناوين URL pypi.org بمراجع إلى النسخة المتطابقة المحددة.

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

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

أعتقد أن التعليق الأخير كان مخصصًا لـkylecribbs؟

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