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

بحيث يقتل حد كبير الحلول الممكنة (3) IMO - لا يملك الخلفية مفهوم ما هو بناء في مكان، لذلك لا أستطيع أن أقول ما إذا كان هذا البناء هو آمن ^1.

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

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

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

¹ سيكون من الممكن بالطبع تحديث PEP 517 لتحديد ما يشكل شجرة مصدر "في المكان" بدلاً من بناء "خارج الشجرة" ، لكنني أظن أنه سيكون مفهومًا صعبًا للغاية لتحديده.

أضفت الحلول 4. (غيّر النقطة لتُبنى دائمًا في مكانها) و 5. (غيّر النقطة لتُبنى في مكانها افتراضيًا مع خيار البناء خارج الشجرة).

لدي مشاعر مختلطة فيما يتعلق بالبناء عبر sdist (الحل الأول) للأسباب التالية:

1. قد يكون لبعض المشاريع مسار من العجلة إلى العجلة مكسور ؛ بينما أرى قيمة التحقق من صحة هذا البناء من sdists ، فإن القيام بذلك افتراضيًا الآن سيؤدي بالتأكيد إلى كسر الكثير من تصميمات المستخدم النهائي
2. لا يزال له آثار على الأداء للمشاريع ذات قوائم بيانات كبيرة ، وبسبب استدعاءات العمليات الفرعية الإضافية
3. أنا شخصياً أعتقد أنه لا ينبغي لنا أن نركز كثيرًا على sdists لأنه من الشائع جدًا أن ينشر المشروع القطع الأثرية وأن يشير إلى نظام استضافة الكود المفضل لديهم لإصداراتهم المصدر (على سبيل المثال ، الخلفيات التي تعتمد على وجود تسجيل الخروج من VCS لـ بناء بحاجة للقفز من خلال الأطواق لإنتاج sdist العامل). ويسمح PEP 517 تحديدًا للجهات الخلفية بجمع UnsupportedOperation مقابل build_sdist .

يلخص هذا المنشور عند المناقشة أيضًا الحجج المماثلة.

أوافق على أن الطريق إلى الحل 3. أبعد ما يكون عن الوضوح.

أوافق أيضًا على أنه يجب علينا تجنب الخيارات الإضافية إذا استطعنا.

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

• قم ببناء قائمة في مكانها ، وفك تغليفها في مكان مؤقت ، ثم قم بالبناء من ذلك.

أعتقد أن هذا نهج جيد.

فرص IMO هي أن يتم تشغيل هذا لحزمة واحدة في معظم pip install التشغيل التي تتضمن الدلائل المحلية - الأكثر شيوعًا أتخيل pip install . . من المحتمل أن يتم ذلك كجزء من سير عمل تطوير الحزمة.

إليك ما أعتقد أنه يجب أن يكون هذا السلوك:

• إذا كانت الواجهة الخلفية غير قادرة على إنشاء sdist ، فقم بعمل local-dir -> wheel (in-place)
  
  
  
  • أعتقد أن المسؤولية تقع إلى حد كبير على الواجهة الخلفية للتأكد من أن عجلة local-dir -> عملية غير فعالة في هذه الحالة.
  
  
• إذا كانت الواجهة الخلفية قادرة على إنشاء sdist ، فقم بعمل local-dir -> sdist -> unpacked-sdist -> العجلة.

بعمل local-dir -> sdist -> wheel ، لدينا مجموعة إضافية من المكالمات. ومع ذلك ، أعتقد أنه من المعقول التحقق من صحة أن sdists المتولدين عاقلين ، خاصة أثناء التطوير. يقوم Tox بالفعل بهذا كجزء من سير العمل ، تحقق من البيان لتغطية واجهات setuptools غير الصديقة هنا.

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

فيما يتعلق بالطرح ، أعتقد أننا نرغب في الانتظار ومشاهدة كيف يأتي # 6536. لقد تعلمنا بالتأكيد بعض الأشياء التي يمكن نقلها.

أفضل البناء / التثبيت في مكانه بدون sdist (لذا setup.py install أو setup.py bdist_wheel أو الاتصال بـ build_wheel على الواجهة الخلفية PEP 517 حسب الاقتضاء) مقابل إنشاء sdist وتفريغ وتثبيت من ذاك. الأسباب الخاصة بي هي:

1. يدعم أكبر عدد من المستخدمين من خارج منطقة الجزاء.
   
   
   
   1. افترض أن pip يعمل local-dir -> مثبتًا (عبر إنشاء العجلة في مكانها أو setup.py install ). يمكن للمستخدمين الذين يريدون الانتقال من local-dir -> المثبت تنفيذ pip install local-dir . المستخدمون الراغبون في الانتقال من local-dir -> sdist -> التثبيت أحرار في إنشاء sdist ثم تنفيذ pip install ./path/to/sdist . هناك الكثير من الأدوات البديلة التي يمكنها بناء sdist ، وهذا شيء من المرجح أن يكون لدى المستخدمين بالفعل إلا إذا كانوا يصنعون التوزيعات التي يقومون بتحميلها إلى PyPI يدويًا.
   
   
   2. افترض الآن أن النقطة تقوم بعمل local-dir -> sdist -> مثبتة. المستخدمون الذين يريدون الانتقال من local-dir -> مثبت ليس لديهم خيارات تتضمن pip. يمكن للمستخدمين الذين يريدون الانتقال من local-dir -> sdist -> المثبت تنفيذ pip install local-dir . سيطلب المستخدمون الذين ليس لديهم خيارات من نقطة خيارات للتحكم في السلوك أو سيضطرون إلى العثور على أداة أخرى لم يكونوا بحاجة إليها بطريقة أخرى.
   
   
2. إذا قمنا بتطبيق local-dir -> sdist -> مثبت ، فمن المفترض أننا سنفعل ذلك أيضًا للمتطلبات المستندة إلى VCS؟ إذا كان الأمر كذلك فهذا عمل أكثر. إذا لم يكن الأمر كذلك ، فهذه مسارات إضافية من خلال الكود والانحرافات في طريقة معالجة التثبيت التي يجب أن يتذكرها المستخدمون أو عند تقديم الدعم.
3. أقل قدر من العمل المطلوب تنفيذه. هناك ثلاثة أماكن لتغييرها لتطبيق local-dir -> مثبت ( هنا وهنا وهنا ). بالنسبة لـ local-dir -> sdist -> مثبت ، لا أريد حتى أن أتطرق إلى تنفيذ هذا حتى يتم الانتهاء من # 6607 ، وإلا أعتقد أنه سينتهي به الأمر في الكثير من الأماكن في قاعدة التعليمات البرمجية المشابهة لتنزيل الأداة / فحص التجزئة.
4. أقل قدر من العمل للاختبار منذ IMO ، الاختبارات الحالية كافية لتغطية local-dir -> مسار الكود المثبت. بالنسبة لـ local-dir -> sdist -> المسار المثبت ، نود التحقق من أننا نقوم بالفعل ببناء sdist ، وأن العناصر الاحتياطية تعمل لبناء عجلة مباشرة.
5. أقل قدر من العمل (حسابيًا). كما هو مذكور في مكان آخر ، فإن local-dir -> sdist -> المثبت هو استدعاء إضافي للعملية الفرعية (وهذه العملية الفرعية تقوم بعملها). هذا يعني أيضًا أنه يجب على النقطة فك حزمة sdist (مرحبًا بأجهزة فحص الفيروسات والأقراص البطيئة بخلاف ذلك) قبل القيام ببناء العجلة.

بغض النظر عن النهج ، فإن المشكلة الوحيدة التي أراها عند القيام بالأشياء في مكانها هي أنه بالنسبة إلى إنشاءات setuptools (أعتقد أن هذا ينطبق على الإصدارات القديمة و PEP 517) ، فإننا سننتهي بـ .egg-info في دليل المشروع الذي سوف يخطئ باعتبارها "حزمة مثبتة" عندما يتم استدعاء النقطة مع python -m pip في هذا الدليل. سيتم إصلاح ذلك بواسطة # 4575 والذي من المفترض ألا يتضمن الدليل الحالي في الاستعلام عن الحزم المثبتة لأي نظام.

مع ملاحظة أنني نمت لأتفق على أن فكرة تخطي بناء sdist والقيام مباشرة ببناء داخل الشجرة هي طريقة أفضل تتخذها النقطة افتراضيًا ، ولا تحاول القيام بـ local-dir -> sdist -> wheel.

في Fedora ، عندما نبني حزم Python RPM ، فنحن ديناصورات والطريقة القياسية للقيام بالأشياء هي استخدام python setup.py build . مع PEP 517 أضفنا طريقة "مؤقتة" لاستخدام pip wheel بدلاً من ذلك. ولكن مع وحدات الامتداد لدينا مشكلة في نهج "نقل المصادر إلى tmp ، والبناء من هناك" الذي تستخدمه النقطة لبنائها.

تقوم آلات البناء الخاصة بنا بحقن بعض أعلام المترجم بحيث تحتوي عناصر البناء ( .so وحدات الامتداد في هذه الحالة) على بيانات وصفية حول مصادرها. لاحقًا ، يوجد نص برمجي للقذيفة يمر عبر عناصر الإنشاء ، ويستخرج هذه المعلومات ونسخ المصادر إلى /usr/src/debug ليتم تثبيته عبر *-debugsource RPM خاص. تتوقع mahcinery أن يتم بناء كل شيء داخل شجرة العمل ولا يعمل بشكل جيد عندما يتم بناؤه بالخارج. فيما يلي الأشياء التي يمكن القيام بها (معًا) لتخفيف المشكلة من جانبنا:

1. قم بتعيين متغير البيئة $TMPDIR ليكون في المكان الذي يتوقعه البرنامج النصي RPM (على سبيل المثال export TMPDIR=%{_builddir}/.tmp (وقم بإنشائه))
2. استخدم pip wheel مع الخيار --no-clean للاحتفاظ بالمصادر المنسوخة في $TMPDIR
3. قم بتشغيل بعض شل كونغ فو لإعادة كتابة معلومات "ما هو مصدري" إلى الموقع الصحيح: find %{buildroot} -iname '*.so' -print0 | xargs --no-run-if-empty -0 -n1 /usr/lib/rpm/debugedit -b "%{_builddir}/.tmp/pip-req-build-"* -d "$PWD"
4. (اختياري: تنظيف $TMPDIR يدويًا.)

لا نحب الخطوة الثالثة بشكل خاص لأنها تعتمد على الكثير من تفاصيل التنفيذ:

• /usr/lib/rpm/debugedit API والموقع (والوجود)
• اسم pip-req-build
• الآلية التي بواسطتها يبني النقطة المصادر

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

تقرير المصب: https://bugzilla.redhat.com/show_bug.cgi؟

مع ملاحظة أنني نمت لأتفق على أن فكرة تخطي بناء sdist والقيام مباشرة ببناء داخل الشجرة هي طريقة أفضل تتخذها النقطة افتراضيًا ، ولا تحاول القيام بـ local-dir -> sdist -> wheel.

أصبحت أيضًا أكثر ميلًا لقبول فكرة القيام ببناء عجلة في مكانها. حجوزاتي المتبقية هي:

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

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

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

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

هل من المنطقي تمديد واجهة PEP 517 لتشمل خطافًا "نظيفًا"؟

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

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

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

سأميل إلى تمديد PEP-517 لجعل هذا مطلبًا واضحًا.

سأميل إلى تمديد PEP-517 لجعل هذا مطلبًا واضحًا.

يقول هذا بالفعل:

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

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

عند تجربة t الشكل كحل بديل لـ Fedora ، لقد تعرضنا إلى https://github.com/pypa/pip/issues/7872

نظرًا لأننا قمنا بحل مشكلة ".egg-info in cwd" مع # 7731 والأصدقاء ، فلا داعي للقلق عند البناء في مكانه.

لذلك تم تنفيذ الخيار 4 (دائمًا ما يكون في مكانه الصحيح) في # 7882.

لقد نشرنا الآن (لكل # 7951) إصدارًا تجريبيًا للنقطة ، النقطة 20.1b1. يتضمن هذا الإصدار # 7882 ، والذي قام بتطبيق حل لهذه المشكلة.

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

كما أرحب بالتعليقات الإيجابية على غرار "رائع ، إنه يعمل بشكل أفضل الآن!" أيضًا ، نظرًا لأن أداة تعقب المشكلات عادةً ما تكون مليئة "بالمشكلات". :)

نحن نخطط تمامًا لاختباره في Fedora (لقد خططنا لذلك بالفعل قبل تعليقك) ، ولكن ربما لا يكون الموعد النهائي ليوم الثلاثاء واقعًا.

hroncok هل لديك أي فكرة عن الوقت الذي قد تتمكن فيه Fedora من اختبار هذه التغييرات؟

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

في الواقع ، 20.1b1 يجعل مشاكلنا تختفي.

ملاحظات أكثر عمومية 20.1b1 في https://mail.python.org/archives/list/[email protected]/message/5EAUIYYIRKXEHTAG5GQ7EJHSXGZIW2F7/

يا هلا! شكرًا جزيلاً على تجربة الإصدار التجريبي منhroncok! مقدر جدا! ^> ^

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

manthey أن المناقشة تحت رقم 8168

لقد مرت أكثر من 10 أيام الآن. كانت هناك بعض المشكلات التي أثيرت حول التغيير (كل ما توقعته هو - # 8165 ، # 8168 ، # 8196). كان هناك أيضًا أشخاص ذكروا صراحة أن التغيير يساعدهم.

• إلى جانب مشكلات الأداء ، كان للسلوك السابق (نسخة إلى temp dir) مشكلات تتعلق بالصحة (مرتبط أعلاه) يستحيل إصلاحها بالنقطة دون معرفة السياق التي يمتلكها المتصل فقط (وكملاحظة جانبية ، كان رمز شجرة النسخ هذا مليئًا بالفعل ضمادة للتعامل مع المواقف الغريبة - tmpdir في الشجرة ، المقابس ، إلخ).
• سيظل خيار تنشيط السلوك السابق يحتوي على مشكلات تتعلق بالصحة والأداء.
• سيتضمن الحل الصحيح إنشاء دعم خلفي للتحكم في دليل الإنشاء الذي لا يوجد بالكامل اليوم (على سبيل المثال ، setuptools bdist_wheel لديها --bdist-dir ، لكنها لا تزال تكتب .egg-info في المكان ، راجع أيضًا https://github.com/pypa/setuptools/issues/1816 ، https://github.com/pypa/setuptools/issues/1825). والآن بعد أن أصبحت النقطة تتصرف بشكل صحيح ، ربما يمكن أن تتحول المناقشة لمعرفة ما إذا كانت أدوات الإعداد يمكنها ، على سبيل المثال ، تطوير خيار للقيام ببناء دون لمس دليل المصدر ثم البحث عما إذا كانت هناك حاجة إلى تغيير PEP 517 أم لا للتحكم في هذا الخيار.
• في غضون ذلك ، من المحتمل أن يكون من السهل نسبيًا حل المشكلات التي تم الإبلاغ عنها بواسطة المتصلين (على سبيل المثال عن طريق نسخ أنفسهم إلى دليل مؤقت ، أو عمل كرة تار مؤقتة ، والتي يمكنهم إجراؤها بشكل صحيح بمعرفة كاملة بالسياق).
• أخيرًا ، من الصعب التأكد من البيانات المتوفرة لدينا ، لكن حدسي هو أن هذا التغيير يساعد عددًا أكبر من الأشخاص مما يؤلم.

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

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

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

لقد استخدمت المصطلح "بشكل صحيح" ، لأنه قبل pip wheel <localdir> و pip install <localdir> تم إنشاء عجلة مختلفة عن cd <localdir> ; setup.py bdist_wheel في بعض الحالات: مع اختلاف الملفات المفقودة في وجود ارتباطات رمزية (# 3500) ، أو إصدار مختلف به setuptools_scm (# 7549) ، أو https://github.com/pypa/pip/issues/7555#issuecomment -595180864 ، أو # 6276 ، أو أخطاء واضحة. لا أعتقد أن النقطة 20.1 تولد مثل هذه العجلات / التثبيتات السيئة ، لذلك أعتقد أنها بالفعل أكثر صحة بهذا المعنى.

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

ولا يزال بإمكانها إنتاج عجلات مختلفة عن setup.py sdist && pip install dist/*.tar.gz .

اقتراحي هو إعادة العلاقات العامة وتنفيذ الإصلاح عن طريق التبديل أولاً عبر sdist ثم بناء عجلة من sdist الناتج.

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

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

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

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

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

أيضًا ، يُنشئ setup.py sdist .egg-info في الدليل المحلي ، لذلك ستبقى المشكلات المُبلغ عنها مع دليل المصدر للقراءة فقط أو الإصدارات المتزامنة.

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

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

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

أيضًا ، ينشئ setup.py sdist .egg-info في الدليل المحلي ، لذلك ستبقى المشكلات التي تم الإبلاغ عنها مع dir للقراءة فقط المصدر أو الإصدارات المتزامنة.

أعتقد (على الأقل أن الاختبار السريع يتفق معي) أن setuptools (وليس distutils ) يفعل ذلك ، وهذا السلوك قابل للتكوين لإنشاء dir في مكان آخر. على غرار الخلفيات الأخرى ، يجب أن نكون قادرين على التوصية بهم لعمل جيل جديد نظيف .

FWIW ، لا أعتقد أننا سنحتاج إلى تفريغ دليل sdist من الجيل --egg-info في دليل العمل ، إذا ذهبنا إلى نهج create-sdist-unpack-it-build-wheel ، لأننا نستطيع تفريغ ذلك في دليل مؤقت ، كما نفعل مع generate_metadata .

pradyunsg ألا يتطلب ذلك تغييرًا في setuptools؟ آخر مرة راجعت فيها الأمر sdist لم يكن لديه خيار لتحديد الموقع الأساسي .egg-info ، على عكس egg_info الذي يحتوي على --egg-base الخيار الذي استفدناه في # 7978.

في الواقع! كنت أبحث في الملف الخطأ في setuptools. 🙈 أقف مصححًا.

لماذا كل شيء معقد للغاية في هذا الفضاء؟ :(

$  ls -la
total 8
drwxr-xr-x  3 dstufft  staff   96 May  6 14:26 .
drwxr-xr-x  9 dstufft  staff  288 Apr 28 15:46 ..
-rw-r--r--  1 dstufft  staff   85 Apr 23 16:23 setup.py

$  py setup.py egg_info --egg-base /tmp/foo sdist
/Users/dstufft/.pyenv/versions/3.8.2/lib/python3.8/site-packages/setuptools/dist.py:471: UserWarning: Normalizing '2020.04.23.3' to '2020.4.23.3'
  warnings.warn(
running egg_info
creating /tmp/foo/dstufft.testpkg.egg-info
writing /tmp/foo/dstufft.testpkg.egg-info/PKG-INFO
writing dependency_links to /tmp/foo/dstufft.testpkg.egg-info/dependency_links.txt
writing top-level names to /tmp/foo/dstufft.testpkg.egg-info/top_level.txt
writing manifest file '/tmp/foo/dstufft.testpkg.egg-info/SOURCES.txt'
reading manifest file '/tmp/foo/dstufft.testpkg.egg-info/SOURCES.txt'
writing manifest file '/tmp/foo/dstufft.testpkg.egg-info/SOURCES.txt'
running sdist
warning: sdist: standard file not found: should have one of README, README.rst, README.txt, README.md

running check
warning: Check: missing required meta-data: url

warning: Check: missing meta-data: either (author and author_email) or (maintainer and maintainer_email) must be supplied

creating dstufft.testpkg-2020.4.23.3
copying files to dstufft.testpkg-2020.4.23.3...
copying setup.py -> dstufft.testpkg-2020.4.23.3
Writing dstufft.testpkg-2020.4.23.3/setup.cfg
creating dist
Creating tar archive
removing 'dstufft.testpkg-2020.4.23.3' (and everything under it)

$ ls -la                                        
total 8
drwxr-xr-x  4 dstufft  staff  128 May  6 14:28 .
drwxr-xr-x  9 dstufft  staff  288 Apr 28 15:46 ..
drwxr-xr-x  3 dstufft  staff   96 May  6 14:28 dist
-rw-r--r--  1 dstufft  staff   85 Apr 23 16:23 setup.py

https://github.com/pypa/pip/issues/8165#issuecomment -624669107 يبدو هذا وكأنه عرض جميل يوقف الخلل ، ويمكن القول أنه ليس خطأنا ولكنه أحد أنواع الأخطاء التي جادلت أنها ستحدث أثناء مناقشة PEP 517 عندما إنشاءات في مكانها بشكل افتراضي ظهرت.

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

إذا كانت SCons ، فستتذكر الملفات التي تهتم بها وستحذف الملفات الإضافية في المجلد / البناء من العجلة حتى لو كانت موجودة في نظام الملفات.

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

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

بالطبع مع وجود إشارات كافية للأمر الأساسي setuptools يمكنك معالجة هذا (شيء مثل py setup.py egg_info --egg-base /tmp/foo build --build-base /tmp/foo/build-base bdist_wheel --bdist-dir /tmp/foo/bdist سيفعل ذلك).

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

حاولت اختبار الملصقات لكنني لم أتمكن من الحصول على rsalette للبناء على الإطلاق دون أخطاء.

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

رائع. آسف للأسف تم تحديث إنكونز و rsalette لم.

في الأربعاء ، 6 مايو ، 2020 ، الساعة 4:18 مساءً ، كتب دونالد ستافت:

حاولت اختبار الملصقات لكنني لم أتمكن من الحصول على rsalette للبناء على الإطلاق دون أخطاء.

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرةً ، أو قم بعرضه على GitHub https://github.com/pypa/pip/issues/7555#issuecomment-624867490 ، أو إلغاء الاشتراك https://github.com/notifications/unsubscribe-auth/AABSZERIEDAPUIXCPAKBBUDRQHAXRANCNFSM4KCV5M

آسف للأسف تم تحديث إنكونز و rsalette لم.

هل هناك تحويلة C جيدة تستخدم الملاحق التي يتم تحديثها؟ لقد اخترت للتو rsalette لأنها كانت الأولى في القائمة ولم أشعر بالرغبة في تصحيحها ، وسعدت بتجربة شيء آخر.

المشكلة الوحيدة مع rsalette هي أنه لا ينبغي أن يمر ROOT_IS_PURELIB إلى البيئة في SConstruct. لا يحتوي على امتداد C. cryptacular بخير.

# 8165 (تعليق)

بهذا ، أعتقد أنني أوافق على أنه ينبغي لنا التراجع عن هذا التغيير.

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

أنا أيضًا أصوت للعودة ومتابعة https://discuss.python.org/t/proposal-adding-a-persistent-cache-directory-to-pep-517-hooks/2303/15 كحل لهذا (من شأنه أن السماح للخلفيات بالبناء غير في مكانها ، لذا لا تعرض مثل هذه المشكلات). شارك في هذا الموضوع أيضًا إذا كنت توافق على الاقتراح هناك.

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

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

حسنًا! أعتقد أن الإجماع العام هو العودة وإعادة التقييم. سوف أقوم بتقديم PR لهذا الغرض. :)

شارك في هذا الموضوع أيضًا إذا كنت توافق على الاقتراح هناك.

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

أسقطت للتو بضع نقاط كبيرة من النص في https://github.com/pypa/pip/issues/8165#issuecomment -625401463. سأبتعد اليوم الآن ... انتهى بي الأمر بالإحباط قليلاً أثناء كتابة الملاحظات الشخصية في النهاية. الانتهاء في # 5599 وقراءة تعليقات المستخدم السلبية بالتأكيد لم يساعد.

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

1. قم ببناء قائمة في مكانها ، وفك تغليفها في مكان مؤقت ، ثم قم بالبناء من ذلك.

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

1. أضف خيار النقطة للبناء في مكانه.

أفضل ما أحبه على المدى القصير ، لأن الحل 4 لم ينجح. هل من السابق لأوانه إضافة ذلك في النقطة 20.1.1؟

1. قم بتحديث PEP 517 بنوع من الآلية للسماح للنهايات الخلفية بالتواصل مع الواجهات الأمامية إذا كانت "آمنة" للبنيات الموضعية.

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

1. تغيير النقطة لتبني دائمًا في مكانها.

لذلك يعتبر هذا واحدًا مزعجًا للغاية وسنعود في 20.1.1.

1. غيّر النقطة لتبني في مكانها افتراضيًا مع خيار البناء خارج الشجرة.

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

أنا حقًا لا أحب خيارات CLI ، لا سيما تلك المشابهة. ماذا لو أدرجت حزمتين على خوادمي المحلية وأحتاج إلى بناء واحدة في مكانها وواحدة لا؟ إذا قدمنا ​​خيارًا للقيام بواحد أو الآخر ، فسينتهي الأمر بالحزم الحالية التي لا يمكن بناؤها إلا مع واحدة أو أخرى.

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

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

لما أعنيه ، لدينا بعض "المسارات" التي يمكن أن تمر بها عمليات التثبيت:

1. VCS -> Sdist -> عجلة -> مثبتة
2. VCS -> عجلة -> مثبتة
3. VCS -> مثبت (قديم)

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

يمكننا اعتبار أنه يتم تحميل sdist أو عجلة إلى PyPI وتثبيتها من ذلك إلى أن تكون جزءًا من نفس "المسار" ، فأنت تقوم بإيقافه مؤقتًا وإنهائه على كمبيوتر آخر.

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

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

كميزة إضافية ، يمكن أن يكون هذا أيضًا بمثابة وظيفة إجبارية للمساعدة في ضمان بقاء المسار السعيد سعيدًا.

في الغالب أتفق مع dstufft ، وعلى وجه الخصوص أوافق على أنه لا يجب النظر إلى نهج build-from-sdist على أنه "محاولة التحقق من صحة قوائم sdists" ولكن "كل شيء يتبع" شجرة المصدر -> sdist -> عجلة -> تثبيت المسار (فقط بعض الأشياء تتخطى بعض الخطوات الأولية) ".

ومع ذلك ، أريد أن أتناول نقطة واحدة:

ماذا لو أدرجت حزمتين على خوادمي المحلية وأحتاج إلى بناء واحدة في مكانها وواحدة لا؟

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

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

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

إذا أخذ المحلل الجديد ما تم تثبيته بالفعل في الاعتبار ، فسيكون pip install foo bar و pip install foo && pip install bar متساويين تقريبًا ولا يهم على الإطلاق ، ولكن إذا لم يكن الأمر كذلك (ونفس الشيء صحيح تقريبًا الآن) إذا كان كلا المشروعين يعتمدان على "البريد العشوائي" ولكن foo مطلوب <2 والشريط مطلوب> 1 ، فسنحصل على تثبيت غير صالح.

هذا ظل رغم ذلك :)

(لست متأكدًا مما إذا كان عمل المحلل الجديد سيغير ذلك؟)

المدخلات مرحب بها على # 7744. :)

1. تغيير النقطة لتبني دائمًا في مكانها.

لذلك يعتبر هذا واحدًا مزعجًا للغاية وسنعود في 20.1.1.

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

1. أضف خيار النقطة للبناء في مكانه.

dstufftpfmoore أرى هذا النوع من الخيارات كآلية اشتراك حتى نتمكن تدريجياً من دفع المستخدمين نحو الإنشاءات في مكانها بهدف جعلها الخيار الافتراضي في وقت ما. انطلاقا من هذا التعليق: https://github.com/pypa/pip/issues/8165#issuecomment -625501216

سوف أقوم بتقديم PR لهذا الغرض. :)

8221 هو عليه.

تم إصدار 20.1.1 ، متضمنًا التغييرات التي تم إرجاعها.

في Fedora ، عندما نبني حزم Python RPM ، فنحن ديناصورات والطريقة القياسية للقيام بالأشياء هي استخدام python setup.py build . مع PEP 517 أضفنا طريقة "مؤقتة" لاستخدام pip wheel بدلاً من ذلك. ولكن مع وحدات الامتداد لدينا مشكلة في نهج "نقل المصادر إلى tmp ، والبناء من هناك" الذي تستخدمه النقطة لبنائها.

تقوم آلات البناء الخاصة بنا بحقن بعض أعلام المترجم بحيث تحتوي عناصر البناء ( .so وحدات الامتداد في هذه الحالة) على بيانات وصفية حول مصادرها. لاحقًا ، يوجد نص برمجي للقذيفة يمر عبر عناصر الإنشاء ، ويستخرج هذه المعلومات ونسخ المصادر إلى /usr/src/debug ليتم تثبيته عبر *-debugsource RPM خاص. تتوقع mahcinery أن يتم بناء كل شيء داخل شجرة العمل ولا يعمل بشكل جيد عندما يتم بناؤه بالخارج. فيما يلي الأشياء التي يمكن القيام بها (معًا) لتخفيف المشكلة من جانبنا:

1. set the `$TMPDIR` environment variable to have it within the place where the RPM script expects it (i.e. `export TMPDIR=%{_builddir}/.tmp` (and create it))

2. use `pip wheel` with the `--no-clean` option to keep the copied sources in `$TMPDIR`

3. run some shell kung fu to rewrite the "what is my source" information to the correct location: `find %{buildroot} -iname '*.so' -print0 | xargs --no-run-if-empty -0 -n1 /usr/lib/rpm/debugedit -b "%{_builddir}/.tmp/pip-req-build-"* -d "$PWD"`

4. (Optional: clean `$TMPDIR` manually.)

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

تم كسر الإنشاءات التكرارية باستخدام النقطة بشكل فعال اليوم ، وهي خسارة كبيرة للمجموعات التي لديها قدر كبير من كود Python في شكل امتداد C ، لذلك لجأت إلى استدعاء الإنشاء بـ setup.py .

يحتاج pip إلى أمر build والنتيجة النهائية للأمر build يجب أن تكون قابلة للتمرير إلى جانب الأوامر الفرعية الأخرى ، مثل wheel ، install ، إلخ.

في الوقت الحالي ، يعامل pip install أنه build و install ، وهو _ليس _ ما يريده بعض الأشخاص الذين يقومون ببناء العناصر الثنائية وتخزينها مؤقتًا ، وتثبيت الثنائيات فوق القراءة - يتصاعد فقط ، إلخ.

أتمنى حقًا أن تكون هناك طريقة لاستخدام setup.py لإنشاء الثنائيات ، ثم pip install لهم دون اللجوء إلى إنشاء bdist ، لكن هذا لا يبدو ممكنًا اليوم ، نظرًا لأن pip و distutils / setuptools لا يتفقان على مكان العثور على القطع الأثرية الثنائية.

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

لست متأكدًا من أنني أتابع - أنت تقول أنك تريد طريقة لاستخدام الثنائيات ولكن لا تريد استخدام تنسيقات التوزيع الثنائية الموجودة بالفعل. لماذا هذا؟

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

لست متأكدًا من أنني أتابع - أنت تقول أنك تريد طريقة لاستخدام الثنائيات ولكن لا تريد استخدام تنسيقات التوزيع الثنائية الموجودة بالفعل. لماذا هذا؟

تنسيقات bdist محدودة للغاية. يتعين على مجموعتي أن تلجأ إلى تنسيق غبي ، مثل tar ، ثم تفريغها حرفيًا (لا يدعم أي من BSDs ، دبيان غير مدعوم ، إلخ).

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

لقد جربت أيضًا egg و zip ، لكنهم يفتقرون إلى البيانات الوصفية اللازمة للتثبيت باستخدام URI file:// .

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

قادمًا من https://github.com/pypa/pip/issues/2195#issuecomment -664728481 أستطيع أن أقول إنني أكثر من سعيد لإعادة تنفيذ # 7882 خلف --use-feature=in-tree-build .

يا هلا! تبدو كخطة!

لنقم أيضًا بتحديث docstring --build هذه المرة. ؛)

قادمة من # 2195 (تعليق) أستطيع أن أقول إنني أكثر من سعيد لإعادة فعل # 7882 خلف --use-feature = in-tree-build.

من الغريب إذا كان من المعقول أن يكون لديك خيار in-tree-build في pyproject.toml ؟ سيكون هذا أمرًا رائعًا لحل # 6276 دون الحاجة إلى عمل نص برمجي أو makefile لالتفاف النقطة. (لا يعني ذلك أن هذه مشكلة كبيرة بشكل خاص.)

لديك خيار بناء داخل شجرة معين في pyproject.toml

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

راجع للشغل ، لن أكون قادرًا على تنفيذ هذا في الوقت المناسب لـ 20.3 ، لكن ما زلت عازمًا على القيام بذلك ، وآمل في 20.4.

sbidoul لقد كتبت تصحيحًا للمساعدة في الحصول على هذه الميزة - راجع # 9091.