<p>تثبيت نقطة - صدام تثبيت قابل للتحرير وتثبيت نقطة لحزم مساحة الاسم</p>

نفس المشكلة هنا :(

لقد قمت بنشر رمز لاختبار هذا الخطأ: http://public.hg.stephane-klein.info/hgwebdir.cgi/test_pip_namespace_bug_3/

جذر المشكلة هنا هو أن setuptools تتضمن طريقتين لجعل حزم مساحة الاسم تعمل: طريقة __init__.py (وهي موثقة وقابلة للاستخدام من قبل البشر) ، وطريقة ملف ...-nspkg.pth ، وهي تستخدم فقط مع --single-version-externally-managed (الذي تستخدمه النقطة). الطريقتان غير متوافقين مع بعضهما البعض.

بعد بعض المناقشات مع mitsuhiko وآخرين على IRC ، يبدو أن أفضل حل (جزئي) لـ pip هو إضافة "pip install -e" نسخة معدلة من ملف setuptools القياسي ... ملف nspkg.pth لكل حزمة مطورة مثبتة . (التعديلات الضرورية هي استخدام مسار تطوير رابط البيض بدلاً من sitedir ، وتخطي التحقق من init .py بالكامل ، لأن حزمة مساحة الاسم المثبَّتة ستحتوي على init .py). هذا يعني أن النقطة ستكون على الأقل متوافقة مع نفسها (ستعمل حزم مساحة الاسم المثبتة بواسطة الأنابيب والمثبتة القابلة للتحرير معًا). لن تكون حزم مساحة الاسم المثبتة بواسطة Pip و setuptools / Distribute-المثبتة متوافقة.

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

أعتقد أن النقطة يجب أن تقتل بطريقة ما الشيء nspkg.pth تمامًا وتثبيت __init__.py . طالما تم تصميم الحزمة نفسها بشكل صحيح (على سبيل المثال ، __init__.py فارغة باستثناء ext_path / expare_namespace) فلن تكون هناك مشكلة. - تم تصميم الإصدار الفردي المُدار خارجيًا مع وضع برامج حزم النظام في الاعتبار ، لكنهم لن يستخدموا النقطة في المقام الأول. لذلك أتساءل عما إذا كانت هناك طريقة ما لتعطيل هذا السلوك تمامًا دون التطفل.

+1 للتبديل بعيدًا عن "- إصدار فردي - مُدار خارجيًا": هذا الخيار غير مخصص لحالات استخدام النقطة على الإطلاق. إذا لم تستطع النقطة القيام بعمل جيد على الأقل في تثبيت الأشياء مثل easy_install ، فما الغرض منها؟

التحول عن --single-version-externally-managed بالكامل لن يحدث ؛ عمليات التثبيت المسطحة هي ميزة. إن الابتعاد عنه في حالة حزم مساحة الاسم فقط هو احتمال أعتبره لتجنب هذه المشكلات. لا يعجبني ، ولكن لا يبدو أن هناك أي خيار رائع ، نظرًا لعدم التوافق المتأصل بين نوعي دعم حزمة مساحة الاسم المضمنة في setuptools / التوزيع.

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

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

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

سأقبل تصحيحًا لتجنب --single-version-externally-managed عند تضمين حزمة مساحة اسم ، والتي أعتقد أنها ستحل هذه المشكلة. ليس لدي حاليًا أي خطط لكتابة هذا التصحيح.

لماذا لا يكون خيارًا يمكننا تمريره إلى pip install لعدم استخدام --single-version-externally-managed ؟ أختبر من خلال التعليق على ذلك في ./pip/req.py:568 وجميع الحزم مثبتة الآن في egg dir ، تمامًا كما يفعل easy_install. في وقت ما أرغب في القيام بذلك إذا استخدمت كل من pip و easy_install بحيث لا يختلط site-packages مع بعض الحزم التي يتم تثبيتها بشكل ثابت والبعض الآخر لا.

لا أرى مشكلة مع خيار --egg لإلغاء الاشتراك في --single-version-externally-managed .

https://github.com/k4ml/pip/commit/93cd6b16207d2eba201a7fc3126624b616f5e6f9

هل يمكن لشخص أن يعلق إذا كنت أسير في الاتجاه الصحيح؟ هذه هي المرة الأولى التي أقوم فيها بالقرصنة على كود البيب ، لذلك يعتمد هذا على لمحة عن الدقائق القليلة في جزء منه ، فقط للحصول على pip install --egg somepackages تثبيت كل شيء في بيضة واحدة

هل يمكن لشخص أن يعلق إذا كنت أسير في الاتجاه الصحيح؟

تبدو جيدة بالنسبة لي ، فقط بحاجة إلى اختبار. معظم الاختبارات عالية المستوى
يجب أن تكون اختبارات التكامل باستخدام ScriptTest سهلة الكتابة بناءً على
الأمثلة الموجودة. في هذه الحالة ، سترغب فقط في اختبار هذا التثبيت
ينتج عن عينة الحزمة ملف .egg ، وليس تثبيتًا مسطحًا ، بتنسيق
حزم الموقع. يجب تثبيت حزمة من نظام الملفات المحلي ،
ليس الشبكة: من المحتمل أن يعمل tests/packages/FSPkg بشكل جيد. مضيفا
اختبار tests/test_basic.py جيد.

شكر!

طلبات السحب - https://github.com/pypa/pip/pull/541

أفكر أيضًا في جعل هذا العلم ممكنًا في pip.conf. ما رأيك في ذلك ؟

أفكر أيضًا في جعل هذا العلم ممكنًا في pip.conf. ما رأيك في ذلك ؟

دعونا نناقش طلب السحب.

طلب السحب المدمج رقم 541 ، والذي يوفر حلاً واحدًا. شكرا @ k4ml!

ملاحظة: من المحتمل إزالة الخيار --egg ، الذي تمت إضافته لإصلاح هذه المشكلة ، دون تقديم حل بديل. انظر المناقشة في # 1749

هذا نص لنسخ هذه المشكلة بالفعل

https://gist.github.com/Ivoz/d9bff05069e0ec53e6ea

أنا لست من أشد المعجبين بحل --egg ، لكن يجب أن يكون هناك حل أقل تعقيدًا لهذا.

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

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

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

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

قدمت مقترحين لإصلاح هذه المشكلة في setuptools https://bitbucket.org/pypa/setuptools/issue/250/develop-and-install-single-version. لمعلوماتك.

وضع

استيراد pkg_resources ؛ pkg_resources.fixup_namespace_packages ('')

في ملف .pth في حزم الموقع يبدو كافيًا لجعل تثبيت pip -e يعمل بشكل صحيح.

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

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

بعد أن أدركت أن pip install -e يقوم بتشغيل setup.py develop للمشروع الذي يجب أن يكون قابلاً للتعديل ، قمت بالتدخل في إجراء setuptools وكتبت ملف * .pth ، والذي "يقدم" حزم مساحة الاسم عند عملية Python يبدأ. هذا يحل المشكلة بالنسبة لنا عند استخدام setuptools 18 و pip 7.1.0.

يمكن العثور على مثال لملف setup.py ، الذي يوضح كيف يمكن تحقيق ذلك ، هنا:
https://gist.github.com/cbrand/a1624ac3e9c81ce45fcb

آمل أن يكون هذا مفيدًا للآخرين أيضًا.

واجهت هذا اليوم أيضًا ، وهو يمنعني من التبديل من buildout إلى virtualenv + pip.

لقد أنشأت عرضًا توضيحيًا صغيرًا يوضح المشكلة. لاختباره ، قم بفك ضغط .tar.gz وتشغيل البرنامج النصي {{run-me}} بداخله. قد يكون مفيدًا عند اختبار الإصلاح.

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

أثناء محاولتي الفهم ، صادفت الحل الذي اقترحه carljm في https://github.com/pypa/pip/issues/3#issuecomment -1659959 ، على سبيل المثال _ لديك "pip install -e" أضف نسخة معدلة من المعيار setuptools ... ملف nspkg.pth لكل حزمة تم تطويرها.

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

لذلك أتساءل ما إذا كان هذا النهج لا يزال يعتبر صالحًا ، وإذا كانت هناك أي محاولة لتنفيذه ، وإذا كان سيتم النظر في تصحيح لذلك؟

إذن ... لا أمل في أن يتم إصلاح هذا في المستقبل القريب؟

بعض التأثيرات الجانبية لـ pkg_resources.get_distribution() تجعل عملية الاستيراد تعمل. اكتشفنا هذا عندما عملت التعليمات البرمجية التي تم تحميل نقاط الدخول بشكل صحيح بينما فشلت قذيفة Python.

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

أنا مندهش من أن هذا الخطأ لا يزال مفتوحًا بدون عمل واضح بعد 5 سنوات.

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

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

كتب براندون جيثب [email protected] :

أنا مندهش من أن هذا الخطأ لا يزال مفتوحًا بدون عمل واضح بعد 5 سنوات.

نعم ، هذا أمر مؤسف.

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

لقد قمت مؤخرًا بتطبيق fixup_namespace_packages ('') الاختراق المذكور أعلاه و
يبدو أنه يعمل: لقد قمت بإنشاء z.pth داخل حزم موقع venv
تحتوي على import pkg_resources; pkg_resources.fixup_namespace_packages('')

يستحق المحاولة ، IMHO.

مجرد نتوء آخر هنا!

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

النهج pip يعمل فقط ، من واقع خبرتي ، إذا تم تثبيت _ كل حزمة_ ، وقابلة للتحرير ، من القرص ، والتي تتعاون في مساحة الاسم. إذا تم تثبيت حزمة واحدة غير قابلة للتحرير عبر النقطة ، فإن كرة الغزل بأكملها تبدأ في الانهيار مع بعض الأعراض المنفرجة جدًا للمستخدمين الجدد. (مثل وحدات وارداتها بشكل متقطع، شيك التعقل العام لاستيراد مساحة الاسم الأم والتحقق namespace.__path___ حددت بسرعة حزمة borked الجاني في الاختبار.) خلط صحيح اللدود الحزم المثبتة ونقية setup.py develop 'د ومع ذلك ، يبدو أن مصادر المصدر (تجنب النقطة) تعمل.

يبدو أيضًا أننا قادرون على الدخول في مواقف غريبة حيث يمكن تثبيت حزمة واحدة لمساحة الاسم بثلاث طرق مختلفة ، وأحيانًا جميعها في وقت واحد. (المكالمات المتكررة إلى pip uninstall ، كل منها يعثر على المزيد من الملفات ، هو أمر مضحك للغاية لرؤية أنه أمر مؤسف.) يبدو أن تثبيت التبعية عند استخدام pip install -e غير متسق أيضًا. في معظم الحالات ، ينتهي بنا الأمر بمساحات أسماء تم فك حزمها بشكل صحيح (مثبتة) ، وملفات pth-link (مثبتة للتحرير) ، وفي إحدى الحالات تمكنا بطريقة ما من الحصول على ملف مضغوط .egg مثبتًا ، على الرغم من zip_safe يجري False على أن حزمة تعتمد وليس .egg التوزيع التي يجري تقديمها على Pypi.

يصل الإحباط من مشكلات مساحة الاسم إلى ذروته بعد المرة الرابعة التي يتم فيها إعادة تشغيل بيئة افتراضية من الصفر. ؛)

ليس حلاً لكني فقط وضعت بعض الملاحظات. عند المزج بين الحزم "القابلة للتحرير" والحزم التي تحتوي على فراغات الأسماء والحزم العادية ، يكون حظي أكبر في buildout + mr.developer.

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

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

هل لا تزال هذه مشكلة في الإصدارات الأحدث من Python مع تطبيق PEP420؟ (اقرأ: هل سيساعد التبديل إلى إصدار أحدث من Python؟)

لقد ساعدني استخدام أسلوب PEP420 بشكل فعال عدة مرات في كتابة الوضع القابل للتحرير.

ومما يؤسف له أنه يأتي مع مواطن الخلل الخاصة: على سبيل المثال، setuptools ' find_packages لا يعتمد عليه ، حتى بلدي أحدث حزم يحتوي على الإختراق التالية:

-    packages=find_packages('src'),
+    packages=['toplevel.child.' + package
+              for package in find_packages('src/toplevel/child/')],

لا يبدو أن أحدًا قد نفذ إضافة a -nspkg.pth لكل حزمة قابلة للتحرير.

تحقق من Setuptools 31 التي تضيف دعمًا لهذه الميزة ، وتتواجد أيضًا مع حزم PEP-420 على Python 3.5+.

بالنسبة لأي شخص فضولي ، إليك قائمة شاملة حول كيفية عمل حزم مساحة الاسم عبر pip install ، pip install -e ، python setup.py install ، و python setup.py develop :

https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md

tl ؛ dr: يمكنك استخدام pip install -e و python setup.py develop طالما تم تثبيت كل حزمة أخرى في مساحة الاسم باستخدام pip .

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

تضمين التغريدة
ما هي إصدارات pip و setuptools التي تم استخدامها للحصول على النتائج على https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md ؟

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

في أمثلة jonparrott ، يمكن python setup.py install مباشرةً (باستثناء حالات فشل PEP 420 في Python 2 ، والتي كانت متوقعة). هذا فشل حتى في الحالات التي لا تتضمن النقطة على الإطلاق (مثل python setup.py install + python setup.py develop ).

كانت هذه التذكرة لمجموعات من pip install . و pip install -e أو python setup.py develop .

يوضح الرسم البياني المنشور بالفعل من قبل jonparrott أن هذه البطاقة قد تم حلها وأن أي مشاكل متبقية هنا هي مشكلة مع python setup.py install وليس مع النقطة.

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

@ piotr-dobrogost يستخدم الاختبار أحدث الإصدارات من كليهما. حتى كتابة هذه السطور ، النقطة 9.0.1 و setuptools 34.3.2.