4799 هو المكان الذي يحدث فيه الكثير من النقاش. كان الدافع وراءه في الغالب:

1. لقد فهمت أن المانع الوحيد المعلق لدعم PEP 518 هو # 4764 (عبر https://github.com/pypa/pip/pull/4144#issuecomment-302711736)
2. ثم جاء # 4799 ، ونظرت إليه لأرى ما إذا كان بإمكاني أن أفهم بعض الأعمال الجارية التي كان يقوم بها xoviat .
3. خلال ذلك ، برز رقم 4647 باعتباره مانع تحرير قائلاً إن دعم PEP 518 قد تم كسره.

عندما بدأت في محاولة فهم ما قالتهxoviat في # 4799 ، أصبح من الواضح أن لدينا بعض المشكلات حول البناء التكراري لبيئات البناء (يحتاج X إلى Y للبناء ، و Y يحتاج Z ، ...) على الرغم من أنني ' لا يزال من غير الواضح ما إذا كانت هذه أخطاء في التنفيذ أو مشكلات أعمق في التصميم أو حالات زاوية سيئة يمكننا تأجيلها دون الكثير من المشكلات.

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

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

شكرا لملخص مفيد جداpfmoore.

ncoghlandstufftxoviat هل يمكننا طرح المناقشة هنا من فضلك؟ القيام بذلك في علاقات عامة مغلقة يبدو غريبًا بالنسبة لي. ._.

أَكِيدْ.

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

في الواقع ، أنت بدون إذن ، لذا اسمحوا لي أن أكتب ملخصًا:

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

سأحدد "نطاق" كائن ما كنوع من العمر. إنها المدة التي يوجد فيها الكائن. في الوقت الحالي ، نطاق PEP 518 في pip هو WheelBuilder . تم إعداد بيئة PEP 518 مقابل bdist_wheel ، ثم يتم تشغيل bdist_wheel داخل تلك البيئة ، ثم يتم هدم البيئة.

إذن ما هي المشكلة في ذلك؟ تكمن المشكلة في أن نطاق بيئة PEP 518 يجب أن يكون مساويًا أو أكبر من نطاق جميع المكالمات إلى setup.py . بشكل أكثر تحديدًا ، يحتاج إلى تغليف كائن موجود طوال مدة مكالمات setup.py . هذا الكائن هو Requirement .

أول قرار واضح ستواجهه هو: ما يجب أن يكون له إشارة إلى BuildEnvironment ، و Requirement مكان جيد كأي مكان. في الواقع ، إنه أفضل مكان IMHO لوضع المرجع لأنه يتم استدعاء setup.py إذا وفقط إذا كان Requirement موجودًا.

المشكلة التالية التي قد تواجهها هي: كيف نقوم بتثبيت متطلبات BuildEnvironment ؟ يمكننا فقط الدفع إلى pip . وهذا هو القرار الذي اتخذه المنفذ الأصلي. ولكن هناك مشكلة في ذلك: pip ليس لديه طريقة لمعرفة عدد مكالمات shell التي يقوم بها لأن كل pip يمكنه الاتصال بنفسه مرة أخرى. في الواقع ، يمكن أن تؤدي الحزمة الخبيثة ذات التبعيات الدائرية إلى تعطل جهاز كمبيوتر شخص ما إذا نتج الكثير من العمليات على pip .

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

إن قصف طفل لنفسك بدون نوع من فئة المدير التي يمكن أن تقتل الأطفال عندما يضغط المستخدم على ctrl + C ليس خطأً فحسب ، بل إنه ضار ، خاصةً عندما لا تعرف عدد العمليات التي أنتجتها. أنا شخصياً لا أعرف ما إذا كان الأطفال يموتون في التنفيذ الحالي (قد يكون هذا هو FUD) ، ولكن إذا لم يفعلوا ، فإن التنفيذ الحالي IMHO خاطئ (بصرف النظر عن المخاوف الأخرى).

فيما يلي بعض الحلول الممكنة لهذه المشكلة:

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

2. الحل المناسب ، الذي أود تنفيذه بعد PEP 517 ، هو الحصول على فئة BuildEnvironmentManager تمت تهيئتها مباشرة في الأمر install . سيكون BuildEnvironmentManager مرجعًا لجميع العناصر الموجودة هناك ( RequirementPreparer ، WheelBuilder ، إلخ) ، وسيكون لها طريقة واحدة: get_build_environment(requirement_set) . يمكنك بعد ذلك تنفيذ طريقة على RequirementPreparer وهذا شيء مثل set_build_environment_manager ، والذي يمكن استخدامه بعد ذلك للحصول على بيئات بناء. يمكن لـ BuildEnvironmentManager اكتشاف استخدامات متعددة لنفس البيئة (الأكثر شيوعًا ['setuptools', 'wheel'] ) وتوفير نفس البيئة إذا لزم الأمر عدة مرات حتى لا تحتاج إلى إنشائها ( شائع جدًا في البداية مع وجود مشاريع لا تحتوي pyproject.toml ). من الناحية المثالية ، سيكون هناك أيضًا بعض تصميمات OOP لمحاولة إزالة المراجع الدائرية (ليست تافهة).

xoviat على الرغم من أنه قد لا يغطي حالة الخبث المتعمد ، فهل أنا محق في التفكير في أن ذاكرة التخزين المؤقت للبناء (التي تم استخدامها حتى عندما تم تحديد --no-binary :all: ) مع القدرة على تتبع ليس فقط البنيات المكتملة ، ولكن أيضًا في - التقدم ، هل ستكون كافية لضمان إنهاء دورات الاعتماد على البناء؟ سيكون هذا متغيرًا من اقتراحك الأول (حد متعدد العمليات على عدد استدعاءات النقطة المتزامنة) ، ولكن تمت إعادة صياغته على النحو التالي:

1. يُسمح بعملية واحدة فقط على الجهاز لبناء نفس الحزمة في نفس الوقت
2. هناك "معرّف بناء" من المستوى الأعلى يمرره النقطة إلى أي بنى فرعية تولدها (على سبيل المثال ، PID لعملية المستوى الأعلى مقترنة باسم الحزمة التي يتم بناؤها)
3. إذا كانت ذاكرة التخزين المؤقت للبناء تشير إلى أن شيئًا ما يتم إنشاؤه بواسطة معرف بناء مختلف ، فانتظر حتى ينتهي هذا الإصدار
4. إذا كانت ذاكرة التخزين المؤقت للبناء تشير إلى أن شيئًا ما تم إنشاؤه بالفعل لنفس معرّف الإصدار ، فقم بالإنقاذ بخطأ يُبلغ عن التبعية الدائرية ، ويشير إلى أن --binary <name> سيكون مطلوبًا حتى يعمل الإصدار

سيحتاج pip أيضًا إلى تنفيذ اقتراحpfmoore بإعفاء setuptools & wheel من المنطق الافتراضي للحاجة إلى كل من setuptools و wheel كاعتماديات بناء ، وإلا فإن الحقن الضمني لتبعية البناء سيؤدي بطبيعته إلى تشغيل منطق اكتشاف التبعية الدائري.

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

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

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

لم أكن قد نظرت بالفعل إلى كود # 4144 من قبل. لقد فعلت للتو ولا أريد حقًا أن يكون ذلك للشحن.

تنفيذ PEP 518 بشكل صحيح تمامًا واختراق شيء ما معًا.

بصراحة ، أعتقد أن هذا يعود إلى هذا. يعد تنفيذ PEP 518 بشكل كامل وصحيح مهمة من شأنها / قد تؤخر النقطة 10 بت (عادل) إذا ذهبنا بهذه الطريقة.

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

ما رأيك؟

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

يعد تنفيذ PEP 518 بشكل كامل وصحيح مهمة من شأنها / قد تؤخر النقطة 10 بت (عادل) إذا ذهبنا بهذه الطريقة.

شكرا لتأكيد ذلك - كان هذا خوفي.

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

لذلك علينا أن نفعل شيئًا ، ويبدو أن الخيارات هي:

1. اقتلع كل ما لدينا لدعم PEP 518 في الوقت الحالي.
2. رتب ما لدينا وشحن الدعم الجزئي.
3. نفذ PEP 518 بالكامل قبل أن نحرر النقطة 10.

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

اقتراحك لـ (2) ، أن نشحن إصدارًا من PEP 518 يدعم العجلات فقط باعتبارها تبعيات للبناء (ما زلنا بحاجة إلى إصلاح # 4647 ، حيث أن إظهار ذلك يستخدم تبعية بناء تمثل عجلة) يبدو معقولاً ، بمعنى أنه من العملي بالنسبة لنا التنفيذ. حجزي الرئيسي هو أنه ليس لدي أي فكرة عن مدى إشكالية هذا التقييد للأشخاص الذين يرغبون في استخدام PEP 518.

لذلك أعتقد أني أشعر أننا عالقون في كل ما نفعله ، لكن الدعم الجزئي الذي يغطي العجلات فقط لأن تبعيات البناء هي الخيار الأفضل من بين الكثير السيء :-(

مؤلفو PEP (في https://github.com/pypa/pip/pull/4799#issuecomment-338331267 و https://github.com/pypa/pip/pull/4799#issuecomment-338332575 ردًا على سؤالي في https://github.com/pypa/pip/pull/4799#issuecomment-338325354) كان واضحًا تمامًا أن دعم PEP الكامل يتطلب بناء أي تبعيات بناء ، على الرغم من ذلك ، لذلك يجب أن يكون مجرد فجوة مؤقتة.

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

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

أنا أكثر دراية بالتوزيعات عندما يتعلق الأمر بمنظور "بناء كل شيء من المصدر" ، ونحن بالتأكيد نفصل عملية "bootstrapping the buildroot" عن عمليات إنشاء الحزم العادية. يعد التمهيد التلقائي الكامل من المصدر أمرًا صعبًا ، حيث ينتهي بك الأمر إلى القيام بأشياء مثل تمهيد مترجم C الخاص بك.

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

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

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

أعتقد أن الحل الوسط الآمن هنا هو طلب تبعيات البناء لتكون متاحة كعجلات.

في الواقع هذا بالضبط ما يفعله # 4799. إذا كنت ترغب في ذلك ، يمكنني استعادة هذا الفرع ومن ثم يمكنك تفرع منه وإرساله باعتباره PR.

هناك شيئان على جانب التنفيذ للأشياء (2) لا يزالان قائمين - كما أشار xoviat أعلاه:

1. معرفة كيفية إنشاء العملية الفرعية (الحجج وآخرون)
   أعتقد أنه يجب أن يكون ممكنًا.

2. إصدارات الحزمة التي سيتم تثبيتها.
   من المحتمل أن يتم ذلك في نفس العملية الأصلية على الرغم من أنني لست متأكدًا من كيفية حدوث ذلك بالضبط نظرًا لحقيقة أن كود المحلل الحالي لا يزال متشابكًا مع الكود في pip._internal.operations.prepare . سأبحث في هذا في وقت ما هذا الأسبوع.

لست متأكدًا من سيكون لديه الوقت للقيام بذلك.

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

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

لم تذكر (1) ، ولست متأكدًا مما إذا كان ذلك لأنك اعتقدت أنه ليس لدينا دعم PEP 518 في مكانه ، أو ما إذا كنت تفترض أن دعمه لم يكن خيارًا.

افترضت أن التراجع ليس خيارًا.

الآن بعد أن فكرت في الأمر - ما مدى أهمية شحن PEP 518 في النقطة 10؟ أشعر أنه إذا كان من الممكن تأجيله إلى الإصدار الرئيسي التالي ، فسيكون ذلك (بخلاف كونه الطريق السهل للخروج من هذا الموقف) مباشرًا ويمكن أن يصل كلاهما 517 + 518 في إصدار واحد كبير. هذا يبدو نظيفًا بما يكفي لدرجة أنني لن أكون الشخص الذي يقول أن هذا ليس هو السبيل للذهاب.

dstufftxavfernandez الأفكار ؟

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

إذا كنت ترغب في ذلك ، يمكنني استعادة هذا الفرع ومن ثم يمكنك تفرع منه وإرساله باعتباره PR.

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

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

لقد أجرينا هذه المناقشة بالضبط باستثناء أنك ربما لم تكن على علم بذلك. هذا الموقف هو الوضع X. استدعاء egg_info قبل إعداد بيئة البناء هو الموقف Y (# 4799).

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

أعتقد أن هذا يعني أن # 4799 عاد إلى الطاولة إذن؟ طالما أنه يجتاز جميع الاختبارات ويفعل ما يدعي القيام به؟

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

xoviat لدي بعض الأسئلة. سيكون من الرائع أن تجيب عليهم قبل إجراء علاقات عامة جديدة. :)

• كيف ستحدد الحزم التي يتم تثبيتها؟
• هل ستقتصر على تبعيات البناء الثنائية فقط؟

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

rgommers ، هل ستكون بخير مع PEP 518 الذي يدعم فقط تبعيات البناء المتاحة كعجلات إذا كانت في النقطة التالية؟

كيف ستحدد الحزم التي يتم تثبيتها؟

تحصل العملية الفرعية على قائمة المتطلبات تمامًا كما هو محدد. بهذه الطريقة يمر عبر المحلل.

هل ستقتصر على تبعيات البناء الثنائية فقط؟

نعم هذا في الواقع سبب فشل الاختبار. الاعتماد على البناء في الاختبار ليس عجلة.

الآن بعد أن فكرت في الأمر - ما مدى أهمية شحن PEP 518 في النقطة 10؟ أشعر أنه إذا كان من الممكن تأجيله إلى الإصدار الرئيسي التالي ، فسيكون ذلك (بخلاف كونه الطريق السهل للخروج من هذا الموقف) مباشرًا ويمكن أن يصل كلاهما 517 + 518 في إصدار واحد كبير. هذا يبدو نظيفًا بما يكفي لدرجة أنني لن أكون الشخص الذي يقول أن هذا ليس هو السبيل للذهاب.

ما هو شعورنا فيما إذا كنا سنجعل أي شخص لديه الوقت للقيام بـ PEPs 517 و 518 للنقطة 11؟ لست متفائلا. يبدو لي أن كلاهما جزء كبير من العمل ، ولدينا أيضًا عمل محلل مستمر أيضًا. على الرغم من أنني لا أؤيد تعليق النقطة 10 لفترة أطول من اللازم ، إلا أنني غير مرتاح بنفس القدر لترك جميع خطط الميزات الرئيسية لدينا تنحرف بينما نصدر سلسلة من الإصدارات الثانوية بشكل أساسي.

بعبارة أخرى ، فإن قول "دعنا نذهب لإصدار النقطة 10" أدى إلى عودة النشاط في عمل PEP 518. إذا أزلنا ذلك من النقطة 10 ، فسأركز على تجهيز الأشياء للإصدار ، وأعتقد أنه من المحتمل أن يفقد PEP 518 الزخم مرة أخرى. ما الذي يدفع الأشياء إلى النشاط مرة أخرى؟ يعملxoviat على التنفيذ ، لكنه واجه مشاكل في محاولة إقناع أي منا الباقين بفهم المشكلات التي كان يعاني منها حتى الآن. لا أريد أن أتركه يعمل بدون أي تعليقات مرة أخرى.

ما يمكننا القيام به هو إصدار "pip 9.1" فقط بالإصلاحات الإضافية التي لدينا جاهزة ، واحتفظ برقم الإصدار "pip 10" لتنفيذ (واحدة على الأقل) من ميزات التذكرة الثلاث الكبيرة الموجودة في طور الإعداد. ولكن إذا فعلنا ذلك ، أود أن أحاول [1] الالتزام بإصدار النقطة 10 في الربع الأول من 2018. وسأكون موافقًا على ذلك كنهج. ولكن هل يشعر أي شخص بما قد ينطوي عليه التراجع عن الدعم الجزئي الذي نتمتع به حاليًا؟ أو في توثيق ما لدينا وما هي حدوده (حتى لا يحاول الناس استخدامه بافتراض أنه مكتمل ، قم بإبلاغ الأخطاء وإثارة المشكلات التي يتعين علينا الرد عليها بـ "هذه الميزة لم تكتمل بعد ، آسف ولكن انتظر النقطة 10 ")؟ هل نقوم فقط بتبادل جزء كبير من العمل مقابل جزء آخر؟

[1] إلى الحد الذي يمكننا فيه الالتزام بأي شيء بموارد تطوعية محدودة للغاية كما هو متاح لدينا.

لقد عملت مع الكثير من المشاريع العلمية لذا فمن الممكن أن أكون متحيزًا

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

ما يمكننا القيام به هو إصدار "pip 9.1" فقط بالإصلاحات الإضافية التي لدينا جاهزة ، واحتفظ برقم الإصدار "pip 10" لتنفيذ (واحدة على الأقل) من ميزات التذكرة الثلاث الكبيرة الموجودة في طور الإعداد.

أنا حقا أحب هذا. +1 للنقطة 9.1.0 بدلاً من 10.0.0 للنقطة

أود أن أحاول [1] الالتزام بإصدار النقطة 10 في الربع الأول من عام 2018. وسأكون موافقًا على ذلك كنهج.

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

أظن أنه من المحتمل أن يفقد PEP 518 الزخم مرة أخرى.

سأفعل ما بوسعي للتأكد من أنه ليس كذلك. نأمل أن ترغب xoviat في ذلك أيضًا. :)

هل يشعر أي شخص بما يمكن أن ينطوي عليه التراجع عن الدعم الجزئي الذي نتمتع به حاليًا؟

لن أمانع في إلقاء نظرة على هذا غدًا. نظرًا لأن dstufft كان هو الشخص الذي تمت مراجعته في # 4144 ، أعتقد أن مدخلاته في هذا الأمر ستكون ذات قيمة.

ملاحظة - لا أريد فعل أي شيء جذري مثل دعم الأشياء دون موافقة @ dstufft و xavfernandez - لذلك دعونا نرى ما سيقولونه أيضًا.

لا يملك dstufft وقتًا كافيًا في اليوم. يجب عليه أيضًا التأكد من عدم تعطل المستودع.

دعونا نرى ما سيقولونه أيضًا.

نعم من فضلك. :)

من منظور UX: التصدي الشامل لهجوم "ثقة الثقة" أمر مؤلم حقًا [1] ، وستجد أن الكثير من الأشخاص الذين يقولون "أنا أجمع كل شيء من المصدر" لا يفعلون ذلك في الواقع - في مكان ما من عمليتهم هناك ستكون خطوة تمهيدية حيث يثقون في برنامج ثنائي يقدمه شخص آخر (على سبيل المثال ، بيئة وقت التشغيل وبناء سلسلة أدوات من مزود نظام التشغيل الخاص بهم) ، أو من جيل سابق من النظام الأساسي الخاص بهم (على سبيل المثال ، buildroots للإصدارات الجديدة من Fedora و تم تصنيف RHEL من الإصدارات السابقة من Fedora و RHEL ، فهي لا تبدأ تمامًا من نقطة الصفر). حتى توزيعة Linux القائمة على المصدر مثل Gentoo تبدأ بمثبت لمنحك بيئة بناء عمل مع Linux kernel و C compiler وبرامج تشغيل الأجهزة وما إلى ذلك.

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

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

pip install --no-binary :all: --no-implicit-builddeps -r build-requirements.txt
pip install --no-binary :all: --no-implicit-builddeps -r requirements.txt

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

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

[1] https://www.schneier.com/blog/archives/2006/01/countering_trus.html

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

class BuildEnvironmentManager(Thread):
    '''Has references to literally everything (cache, resolver, etc.)'''
    def run(self):
        while True:
            requirement_list, future = self.build_environment_queue.get()

            # install the requirements using all of the things
            # that we have

            # then put the build environment in the future
            future.put(BuildEnvironment())

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

class Future(Queue):
    pass

class BuildEnvironmentQueue(object):
    def __init__(self):
        self._queue = Queue()

    def request_build_environment(self, requirement_list):
        f = Future()
        self._queue.put((requirement_list, f))
        return f.get()

    def get():
        return self._queue.get()

وفي العمليات / تحضير.

# This call will put the thread to sleep until we have a build environment
# with the requirements installed
self.build_environment_queue.request_build_environment(requirement_list)

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

الإجابة على سؤالي الخاص حول queue.Queue المستند إلى النهج: من الأفضل تجنب الاعتماد على concurrent.futures ، لأن استخدام ذلك سيتطلب البائع https://pypi.org/project/futures/ في Python 2.7.

بدون معرفة قاعدة الكود pip جيدًا ، فإن فكرة دمج إدارة بيئة البناء في مكان واحد لا تزال تبدو خيارًا جذابًا.

concurrent.futures غير مطلوب لهذا الأسلوب. Future مجرد غلاف وصفي أكثر.

فقط الأساسي المطلوب هو قائمة الانتظار: https://docs.python.org/2/library/queue.html

أعتقد أنه يمكننا فقط نقل هذه السطور إلى BuildEnvironmentManager .

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

حسنًا ، يوجد كل نظام تشغيل غير [Windows ، macOS ، Linux] ، IIRC لا يغطيها manylinux1 .

rgommers ، هل ستكون بخير مع PEP 518 الذي يدعم فقط تبعيات البناء المتاحة كعجلات إذا كانت في النقطة التالية؟

ليس مكالمتي ، لكنني سأكون سعيدًا بأي خطوة إلى الأمام هنا. يعد دعم PEP 518 اختياريًا على أي حال ، لذا فهو لا يعمل إلا عند توفر العجلات (يغطي> 90٪ من الحالات التي قد أقولها) في النقطة 10 لا يزال يمثل تحسنًا كبيرًا.

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

ولكن هل يشعر أي شخص بما قد ينطوي عليه التراجع عن الدعم الجزئي الذي نتمتع به حاليًا؟

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

+1 للنقطة 9.1.0 بدلاً من 10.0.0 للنقطة

لقد حصلت أخيرًا على الوقت لقراءة مؤشر ترابط Distutils-sig بشكل صحيح وإلقاء نظرة على العلاقات العامة والمناقشات ذات الصلة (# 4351 ، # 4144 ، # 4799 ومجموعة أخرى). أعتقد الآن منذ أن أعلنا عن النقطة 10 ؛ هذا ما يجب أن نفعله ، مع دعم PEP 518 الجزئي - رقم 9.1.0.

رقم الإصدار هذا والعمر ليتزامن

المشكله. :(

ncoghlan ربما تراجع هذا التعليق تحت الرادار - https://github.com/pypa/pip/pull/4799#issuecomment -338416543

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

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

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

لا يشمل بناء حلقات التبعية ،

لن يحدث ذلك مع تبعيات البناء الثنائية فقط؟

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

اه صحيح. شكرا! :)

أنا أؤيد النقطة 10 مع تنفيذ جزئي لـ PEP 518 يقتصر على تبعيات بناء ثنائي فقط (أو متوفرة بالفعل في ذاكرة التخزين المؤقت لعجلة الأنابيب) إذا كان هذا هو كل ما نتمكن من تضمينه.

لم أقرأ الموضوع بالكامل حتى الآن ، لكني أريد فقط أن أشير إلى أن أحد الآثار الجانبية للحد من تبعيات البناء الثنائي هو أنه من المستحيل أن يكون لديك تبعية C في أقسام البناء الخاصة بك في كثير من الحالات. نعم ، لدينا عجلات ثنائية على أنظمة التشغيل Windows و macOS وبعض إصدارات Linux ، لكننا لا نستخدم:

• أي نظام Linux لا يستخدم glibc (يعتبر Alpine Linux داخل Docker نظامًا شائعًا).
• أي نظام تشغيل * nix ليس Linux ، مثل FreeBSD وما إلى ذلك.

هذا يعني أن أي مشروع يعتمد على CFFI على سبيل المثال لن يكون قادرًا على استخدام PEP 518 أو سيكون غير قابل للتثبيت على تلك الأنظمة الأساسية.

ربما تم طرح هذا بالفعل! سأقرأ هذا الموضوع لاحقًا.

dstufft هذا صحيح. لكن ما نقترحه هو أن استخدام ذاكرة التخزين المؤقت للنقطة يعد خيارًا. لذا يمكنك فقط pip wheel أو pip install تبعيات البناء أولاً ثم يتم تخزينها في ذاكرة التخزين المؤقت.

ربما تم طرح هذا بالفعل!

لا. :)

هذا يعني أن أي مشروع يعتمد على CFFI على سبيل المثال لن يكون قادرًا على استخدام PEP 518 أو سيكون غير قابل للتثبيت على تلك الأنظمة الأساسية.

بالفعل. :-(

الطريقة التي يتم بها حل هذا الأمر في رأسي هي أنه يمكننا جعل سلوك PEP 518 ممكّنًا - إذا كان هناك ملف pyproject.toml ، فإننا نستخدم بيئة العزل + البناء وإلا فإننا نعود إلى السلوك الحالي لاستخدام setup.py .

سأقرأ هذا الموضوع لاحقًا.

افعل من فضلك. :)

كان لدي نفس التعليق مثل دونالد. ما أفهمه من هذا الخيط هو أن النظام الثنائي فقط مؤقت لأنه لا يوجد وقت لتنفيذه للنقطة 10. هل هذا صحيح؟

إذا تم اقتراحه كقرار دائم بدلاً من ذلك ، فعندئذٍ -1 بالطبع.

كان لدي نفس التعليق مثل دونالد. ما أفهمه من هذا الخيط هو أن النظام الثنائي فقط مؤقت لأنه لا يوجد وقت لتنفيذه للنقطة 10. هل هذا صحيح؟

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

الطريقة حول هذا في رأسي هي أنه يمكننا جعل سلوك PEP 518 ممكّنًا - إذا كان هناك ملف pyproject.toml ، فإننا نستخدم العزل + بيئة البناء وإلا فإننا نعود إلى السلوك الحالي لاستخدام setup.py.

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

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

Error: build dependency X is not in the pip cache. Run "pip install X" before installing Y.

تلخيص وجهة نظري الخاصة:

1. أرى "عدم وجود دعم ضمني لبناء التبعيات" كقيود مؤقتة في النقطة 10 لجعل فئات معينة من المشكلات (مثل إنشاء حلقات التبعية) مستحيلة مواجهتها في أول تكرار تم إصداره للميزة. يمكن أن تسمح التكرارات المستقبلية لدعم الواجهة الخلفية للبناء القابل للتوصيل ببناء المصدر الضمني لبناء التبعيات ، مع وضع التدابير المناسبة في مكانها الصحيح لتجنب المشكلات الجديدة التي تظهر بمجرد السماح بذلك.
2. يعد إصدار الأمر python -m pip wheel X Y Z ذي الصلة في رسالة خطأ دون تشغيل الإنشاء ضمنيًا حلاً مناسبًا في الوقت الحالي ، لأنه يضمن عدم تمكن النقطة من تفجير آلة بدون قصد.
3. من المحتمل ألا تكون الإنشاءات المعزولة هي الإعداد الافتراضي حتى الآن ، إلا إذا كانت العجلة المحددة التي يتم إنشاؤها تحتوي على ملف pyproject.toml ، أو كانت الإنشاءات المعزولة مطلوبة صراحةً من سطر الأوامر. هذه مشكلة توافق عكسي ، لأن المشاريع الحالية ستتوقع السلوك غير المعزول. بمجرد توفر البنيات المعزولة لإصدار أو اثنين ، وتم حل أي مشكلات متعلقة بقابلية الاستخدام ، يمكن أن تصبح الخيار الافتراضي بشكل عام (ربما مع خيار سطر أوامر لتحديد بيئة إنشاء معينة لاستخدامها بدلاً من إنشاء معزولة ضمنيًا واحد)

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

هذه مشكلة توافق عكسي ، لأن المشاريع الحالية ستتوقع السلوك غير المعزول.

معظم الناس لديهم نصوص CI تعمل على pip install X ثم تقوم بتشغيل pip install Y . ستحتاج هذه المشاريع إلى إضافة pypproject.toml . لكن إضافة pyproject.toml ليس بالكثير من العمل ، ويمكننا إضافة علامة سطر أوامر لتعطيل عزل البناء إذا لزم الأمر.

على الأقل يجب أن نطلق تحذيرًا إذا لم يكن للمشروع pyproject.toml في النقطة 10 (والذي يبدو أنه لن يحظى بدعم PEP 517 على أي حال).

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

بقدر ما يذهب PEP 517 ، لا يمكنك الاعتماد على PEP 517 كناشر حزمة دون إضافة ملف pyproject.toml ، لذلك لا بأس إذا لم تحصل المشاريع فقط على دعم PEP 517 setup.py بشكل افتراضي.

هل سيكون على ما يرام مع البصق تحذير؟

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

تم تصميم PEP 518 و 517 عن عمد بحيث لا يتسببان في أي تعطيل للمشاريع الحالية حيث استمر جميع الناشرين المعنيين بالاعتماد فقط على أدوات الإعداد.

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

كان لدي نفس التعليق مثل دونالد. ما أفهمه من هذا الخيط هو أن النظام الثنائي فقط مؤقت لأنه لا يوجد وقت لتنفيذه للنقطة 10. هل هذا صحيح؟

نعم. بالضبط.

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

+1

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

أتفق مع ملخص نيك و ...

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

لا. لا أعتقد أن تنفيذ PEP 518 بهذه الطريقة به أي حواجز طرق رئيسية ؛ لقد قدمت تعليقًا قصيرًا عبر https://github.com/pypa/pip/pull/4799#issuecomment -339219397 حول كيفية تنفيذ ذلك ضمن النقطة.

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

قد يعني وضع ملف pyproject.toml في الأرشيف أن الحزمة تشترك في المعيار الأحدث ومستعدًا لاختبار دعم السلوك الجديد - المرور عبر بيئة الإنشاء مع العزلة والبناء الثنائي فقط - التبعيات (في الوقت الحالي).

لا. لا أعتقد أن تنفيذ PEP 518 بهذه الطريقة به أي حواجز طرق رئيسية ؛

مناقشة PEP 517 هنا. اسف لخلط الامور.

سيتعين علينا إجراء الاختبارات مرتين للتحقق من كلا مساري الكود. آه حسنًا ، ربما تم تأجيل PEP 517.

المنظمة البحرية الدولية ،

1. تحذير إذا كان المشروع لا يحتوي على pyproject.toml يبدو وكأنه فكرة سيئة للغاية. بعد كل شيء ، 99٪ من المشاريع على PyPI لا تحتوي حاليًا على pyproject.toml ، ولا يمكننا إرسال تحذيرات للمستخدمين النهائيين بعدم قدرتهم على فعل أي شيء حيال ذلك (بخلاف الإبلاغ عن المشكلة للمشروع (المشاريع) ). هل فاتني شيء؟
2. لا أعتقد أن عزل البناء قد تم ذكره على الإطلاق في PEP 518. إنها ميزة إضافية أرادت PEP تضمينها لبعض الوقت الآن ، لكنها غير مرتبطة بدعم PEP 518 ، باستثناء الحقيقة المصادفة أن نفس العلاقات العامة نفذت كلاهما (AFAIR). لذا ، إذا كان بناء العزلة هو ما يعطينا مشكلات هنا ، فأنا موافق على وجود PEP 518 فقط في البداية ، وإضافة العزلة كمرحلة 2. سأترك هذا القرار للأشخاص الذين ينفذون الأشياء ، على الرغم من ذلك.

هل فاتني شيء؟

لا.

أنا موافق على وجود PEP 518 فقط في البداية ، وإضافة العزلة كمرحلة 2.

أعتقد أنه يجب علينا القيام بـ PEP 518 وبناء العزلة معًا ، لأنها طريقة لطيفة لجعل الأشخاص يتحولون إلى بنى معزولة.

بينما لا تتطلب PEP 518 ولا PEP 517 تصميمات معزولة ، يوصي PEP 517 بها لأسباب سليمة:

بدون ذاكرة تخزين مؤقت ثنائية محلية ، تكون بيئات البناء المعزولة غير عملية ، ولكن بمجرد أن يكون لديك واحدة من هذه (كما هو الحال الآن pip ) ، فهي أكثر جدوى ، حيث:

1. في معظم عمليات التثبيت ، لن تحتاج حتى إلى إنشاء مصدر في المقام الأول
2. عندما تحتاج إلى إنشاء مصدر ، فعادة ما تقوم بإعداد بيئة الإنشاء من ذاكرة التخزين المؤقت

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

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

لذلك ، أريد تأكيد بعض الأشياء قبل الشروع في كتابة الكود:

• دعم PEP 517 ليس مانعًا للنقطة 10
• PEP 518 في النقطة 10
  
  
  
  • الاشتراك عبر pyproject.toml
  
  
  • يدعم فقط تبعيات البناء الثنائية فقط
  
  
  • يبني معزولة
  
  

لا يمكن أن يكون PEP 517 مانعًا للنقطة 10 لأنه ليس جاهزًا بعد ، ولا يوجد مسار واضح للمضي قدمًا في هذه المرحلة (هناك مسار للمضي قدمًا ولكنه غير واضح).

لدي تعليق وسؤال ردًا على تعليق xoviat هنا يلخص تحديات التنفيذ وكذلك بعد قراءة هذا الموضوع بسرعة.

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

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

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

ثانيًا ، ما الذي تشتريه عملية الدفع مقابل استدعاء دالة النقطة من داخل بايثون؟

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

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

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

لكن هذا لا يجيب على سؤال لماذا تشتري الوقت. ما الذي يجعل من الصعب إنشاء وظيفة API داخلية تقوم بنفس الشيء؟

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

لكن هذا لا يجيب على سؤال لماذا تشتري الوقت. ما الذي يجعل من الصعب إنشاء وظيفة API داخلية تقوم بنفس الشيء؟

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

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

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

هذا لا يعني أنك بحاجة إلى استدعاء pip بالرغم من ذلك ، يمكنك إنشاء واجهة برمجة تطبيقات تسلسل البيانات عبر CLI واستدعاء python -c "from pip._internals import coolapithing; coolapithing(sys.stdin.read())" وقراءة المزيد من البيانات خارج stdout. سيكون من الممكن تحويل الحل التكراري لنقاط الاتصال الخاصة بالنقاط التي تستدعي النقاط عن طريق تحويلها إلى مكدس باستخدام واجهة برمجة التطبيقات (نظرًا لأنه يمكن أيضًا وصف كل العودية على أنها مكدس) ، فأنت تقوم بشكل أساسي بإنشاء واجهة برمجة تطبيقات خاصة يتم استدعاؤه كعملية.

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

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

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

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

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

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

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

تعجبني فكرة dstufft للتحويل إلى نهج تكراري / قائم على التكديس والتحول إلى وظيفة النقطة الداخلية باستخدام النمط python -c "from pip._internals import coolapithing; coolapithing(sys.stdin.read())" . يبدو أن هذا يبدو أبسط بناءً على المناقشة ، فضلاً عن أنه قوي.

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

نظرت / فكرت أكثر قليلاً في تحويل النهج العودي إلى نهج تكراري. ساعدني عمل xoviat الجزئي على PEP 518 (PR # 4799) في العثور على نقطة التكرار (التي ربما يكون البعض منكم على دراية بها بالفعل). إنه في تعليقه على الكود:

# TODO: Use single process with recursion handling

حيث تستدعي بعد ذلك pip install ... .

فكرتي هي أنه يبدو أنه يمكن حل هذا من خلال متغير pip install (لتتبعيات البناء) بشيء مثل التغيير التالي:

• إذا لم يتطلب التثبيت أي عمليات تثبيت فرعية ، فقم بالتثبيت.
• بخلاف ذلك ، ارجع بقائمة (ربما جزئية) بالتثبيتات الفرعية المطلوبة (على سبيل المثال ، عن طريق كتابة المعلومات إلى ملف متفق عليه إذا كانت الكتابة إلى stdout لا تعمل بالفعل).

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

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

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

لقد حان شيء ما. إذا أراد أي شخص آخر التقاط هذا ، فليس لدي
مسائل. :)

كما أنني أحب فكرة dstufft .

في الأحد ، 29 أكتوبر 2017 ، 08:47 كتب xoviat ، [email protected] :

cjerdonek https://github.com/cjerdonek لا أرى أي مشكلة في
تلك الفكرة. لكن في النهاية يحتاج شخص ما إلى تنفيذه (أعتقد
pradyunsg https://github.com/pradyunsg كان يعمل على شيء ما
في نهاية هذا الأسبوع؟) وكما هو الحال دائمًا ، قد يتم اكتشاف المزيد من الصعوبات بعد ذلك.

-
أنت تتلقى هذا لأنه تم ذكرك.

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

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

/ pingncoghlanpfmoorexavfernandez _

نعم من فضلك. أي شيء لدفع هذا إلى الأمام.

هل هناك أي شخص يمكنه تلخيص موقفنا مع PEP 517 و PEP 518 فيما يتعلق بإصدار النقطة 10؟ على وجه التحديد:

1. هل السيد حاليا في حالة يمكن إطلاقها؟ آخر ما سمعته ، تم كسر دعم PEP 518 (هناك مشكلة واحدة على الأقل في مانع التحرير مفتوحة تتعلق بـ PEP 518 - # 4647).
2. هل من المحتمل أن يكون لدينا تنفيذ PEP 517 و / أو PEP 518 في نطاق زمني يجعل من المعقول تأخير النقطة 10 حتى تصبح متاحة؟
3. بافتراض أننا نصلح الأشياء في (1) ، هل نريد إصدار النقطة 10 بدون PEP 517/518؟ أصدرنا رسالة بريد إلكتروني تنبيهية حول الإصدار ، حتى يعرف الناس أنه قادم. وهناك بعض الإصلاحات المهمة بشكل معقول (على سبيل المثال ، إصلاحات الترميز لنظام التشغيل Windows) والتي سيكون من الجيد إصدارها.

شعوري هو أننا ننتظر حاصرات الإصدار ، لكننا لسنا قريبين بدرجة كافية من دعم PEP 517/518 لحظر النقطة 10 عليها. لكن لا أعتقد أن أي شخص يعمل على # 4647 إلا كجزء من تنفيذ PEP 518.

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

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

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

يذكرني هذا أيضًا أنه من المحتمل أن أقوم بإصلاح الأمور بحيث لا يكون flit شرطًا للبناء في حد ذاته.

الاعتذار عن التنفيذ الأولي نصف المخبوز والذي قد يكون بمثابة قنبلة شوكة ،

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

هل السيد حاليا في حالة يمكن إطلاقها؟

IIUC ، يمكنه تفجير نظام حتى الآن ؛ هل هذا صحيح؟ إذا كان الأمر كذلك ، أعتقد أنه ليس كذلك.

هل من المحتمل أن يكون لدينا تنفيذ PEP 517 و / أو PEP 518 في نطاق زمني يجعل من المعقول تأخير النقطة 10 حتى تصبح متاحة؟

أعتقد أن الحل السهل (قصير المدى) سيكون مجرد تقييد العجلات لبناء التبعيات. سأحاول أخذ طعنة فيه في وقت ما الأسبوع المقبل. إذا لم يتحقق ذلك ، فسأكون بخير إذا أزلنا دعم PEP 518 الحالي من السيد وقطع 10.0.0 من ذلك.

لا أعتقد أن أي شخص يعمل على # 4647 إلا كجزء من تنفيذ PEP 518.

أعتقد أنك تقصد ، التنفيذ الكامل لـ PEP 518 مع تبعيات بناء المصدر المسموح بها؟

أوه ، وحول # 4647 - يقول وصف xoviat أعلاه ، الإصلاح الذي قد يتطلب تغيير / نقل الكود وملكية / رؤية الكائنات (على وجه التحديد BuildEnvironment ) ، وهو أمر غير تافه.

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

https://github.com/pypa/pip/blob/fc6b2c192088737f81259b6446f627f20ce46443/src/pip/_internal/wheel.py#L696

ل:

finder.format_control = FormatControl(set(), set([':all:']))

يوجد في الحقل الثاني مجموعة من الحزم للبحث عنها فقط كثنائيات ، مع حالة خاصة لـ ':all:' لتعني جميع الحزم.

نعم. لكن هذا وحده لن يعالج # 4647. أيضا ، لا شيء من هذا الرمز يذهب
من خلال محلل.

يوم السبت ، 2 ديسمبر 2017 الساعة 01:23 كتب Thomas Kluyver [email protected] :

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

https://github.com/pypa/pip/blob/fc6b2c192088737f81259b6446f627f20ce46443/src/pip/_internal/wheel.py#L696

ل:

finder.format_control = FormatControl (set ()، set ([': all:']))

الحقل الثاني هناك مجموعة من الحزم للبحث عنها فقط كثنائيات ، مع
حالة خاصة لـ ": all:" تعني جميع الحزم.

-
أنت تتلقى هذا لأنه تم ذكرك.

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

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

إذا أراد شخص ما تولي مسؤولية العلاقات العامة الأصلية ("إصلاح مشكلات PEP 518") ،
لا ينبغي أن يكون من الصعب تغييرها بحيث لا تكون عزلة البناء كذلك
ممكّن بدون pyproject.toml. السبب الأصلي لعدم دمجها
أنه أسقط دعم تثبيت التبعيات من المصدر بامتداد
PEP 518. ومع ذلك ، الآن بعد أن بدأ الناس يدركون أن PEP 518 قد يكون
ليس في النقطة 10 على الإطلاق ، فقد يكونون أكثر قابلية لقبول ذلك السعر العام. أنا
شخصيا ليس لدي الوقت لمناصرته ، لكن هذا لا ينبغي أن يوقف الآخرين
من المضي قدمًا ، حيث لن يتطلب الأمر سوى بضعة أسطر من التغييرات
(بصرف النظر عن xfailing في اختبار PEP 518).

في الواقع ، وخلافًا لتقديري الأفضل ، فأنا على استعداد لتنفيذ كل من PEP 517 و 518 قريبًا إذا وافق مطورو النقاط على شروطي:

1. التبعيات ستكون فقط من العجلات في البداية
2. سيكون للنقطة خلفية بنية داخلية في البداية ، على الرغم من إزالتها في النهاية

ليس لدي مشاكل مع 1 ؛ ليس لدي أي تفضيل لأي من الطريقتين.

في يوم الأحد ، 3 ديسمبر 2017 الساعة 02:36 ، كتب xoviat [email protected] :

في الواقع ، ضد حكمي الأفضل ، أنا على استعداد لتنفيذ كلا PEP
517 و 518 قريبًا إذا وافق مطورو النقاط على الشروط الخاصة بي:

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

-
أنت تتلقى هذا لأنه تم ذكرك.

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

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

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

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

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

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

في الأحد ، 3 ديسمبر 2017 ، الساعة 23:37 ، كتب xoviat ، [email protected] :

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

-
أنت تتلقى هذا لأنه تم ذكرك.

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

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

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

متفق عليه إعادة النغمة. نقطتي هي ببساطة أنني لن أدمج التغيير [1] ، لذا فإن وجهة نظري ليست مهمة حقًا هنا.

[1] من الواضح ، أنا أقول ذلك بدون رؤية التنفيذ ، لذلك آمل أن يكون من الواضح أن أسبابي لا تتعلق بالمخاوف المتعلقة بجودة الكود - يتعلق الأمر بعدم وجود الوقت الكافي لضمان فهمي للكود جيدًا بما يكفي أن تكون على استعداد للاندماج ، بشكل أساسي.

xoviat ما هي خطط التنفيذ الخاصة بك فيما يتعلق بالنهج التكراري مقابل الأسلوب التكراري الذي ناقشناه أعلاه؟

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

الشرط الأول يلغي مشكلة العودية بأكملها.

للتوضيح أيضًا ، هل تقول أنك ستستكمل أولاً تنفيذًا جزئيًا لـ PEP 517 و 518 يمكن دمجهما ، متبوعًا بتطبيق كامل يمكن دمجه؟

ما أقوله هو أنني سوف أكمل تنفيذًا جزئيًا سيعمل على 95٪ من حالات الاستخدام ؛ على وجه التحديد في الحالة التي يكون فيها التبعيات لها عجلات (شائعة جدًا الآن) وأنت على العديد من منصات Linux / windows / OSX (الغالبية العظمى من المستخدمين).

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

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

[1] https://github.com/btc1/bitcoin/pull/11#issuecomment -313843216

سأغلق هذه المشكلة الآن - لدينا دعم أولي لـ PEP 518 في النقطة 10 والذي يدعم العجلات فقط باعتبارها تبعيات بناء. سأفتح قضية جديدة للمناقشة حول الدعم الكامل وآخر لدعم PEP 517 (نقلاً من هنا حسب الاقتضاء).

شكرًا ncoghlanrgommerscjerdonek على رؤيتك ومساعدتك هنا. شكرًا takluyver على التنفيذ الأولي لـ PEP 518. شكرًا xoviat ( who'sghost الآن) لكل المساعدة في تنفيذ هذه التغييرات. شكرًا @ benoit-pierre على مساعدتك في تحسين الدعم الحالي.

ملاحظة: التعليق رقم 100! : تادا:

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