<p>تثبيت نقطة للدليل بطيء للغاية</p>

يقوم بعمل نسخة من الدليل بالكامل ، بما في ذلك .git . ربما لا ينبغي أن تفعل ذلك ، لا.

$ du -sh pip
263M    pip

$ du -sk * .cache .git .tox .travis | sort -nr | head -n 5
181860  .tox
34836   tests
31700   .git
9212    pip
2852    build

لقد حاولت تجاوز 3 -v 's ( time pip install -vvv --no-install ~/dev/git-repos/pip ) - ولم يسفر ذلك عن أي معلومات أخرى.

عند المرور عبر pdb ، تتباطأ الأمور عندما أصل إلى:

> /Users/marca/dev/git-repos/pip/pip/req/req_set.py(365)prepare_files()
-> unpack_url(

ونعم ،

> /Users/marca/dev/git-repos/pip/pip/download.py(635)unpack_file_url()
-> shutil.copytree(link_path, location, symlinks=True)

$ time pip install --no-install ~/dev/git-repos/pip
DEPRECATION: --no-install and --no-download are deprecated. See https://github.com/pypa/pip/issues/906.
Processing /Users/marca/dev/git-repos/pip
  2014-12-15 15:23:34.630794: Copying tree; link_path = '/Users/marca/dev/git-repos/pip'; location = '/var/folders/gw/w0clrs515zx9x_55zgtpv4mm0000gp/T/pip-D6etc4-build'
  2014-12-15 15:23:57.418679: DONE copying tree; link_path = '/Users/marca/dev/git-repos/pip'; location = '/var/folders/gw/w0clrs515zx9x_55zgtpv4mm0000gp/T/pip-D6etc4-build'
  Requirement already satisfied (use --upgrade to upgrade): pip==6.0.dev1 from file:///Users/marca/dev/git-repos/pip in /Users/marca/dev/git-repos/pip
pip install --no-install ~/dev/git-repos/pip  2.75s user 5.03s system 32% cpu 24.168 total
>>> elapsed time 24s

بعض المناقشات في https://github.com/pypa/pip/issues/2196

أصبح الأمر أسرع الآن بعد أن تم دمج https://github.com/pypa/pip/pull/2196 .

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

$ time pip install --no-install ~/dev/git-repos/pip
DEPRECATION: --no-install and --no-download are deprecated. See https://github.com/pypa/pip/issues/906.
Processing /Users/marca/dev/git-repos/pip
  Requirement already satisfied (use --upgrade to upgrade): pip==6.1.0.dev0 from file:///Users/marca/dev/git-repos/pip in /Users/marca/dev/git-repos/pip
pip install --no-install ~/dev/git-repos/pip  3.67s user 8.12s system 7% cpu 2:45.83 total
>>> elapsed time 2m46s

عذرًا ، ما يقرب من 3 دقائق.

ربما يرجع ذلك في الغالب إلى هذا:

$ du -sh .tox
177M    .tox

الدليل .tox هو 177 مليون من إجمالي 270 pip لكل دليل

يرجى الاطلاع على https://github.com/pypa/pip/pull/2535 ، والذي يسرع unpack_file_url خلال بناء sdist وتفريغه.

يجب إعادة فتح هذه المشكلة ، لأن العلاقات العامة المدمجة لم تفعل شيئًا (انظر gh-3219).

أي تقدم لهذه القضية؟

لا ، ولا يبدو أن الحل النهائي سيصل في أي وقت قريب. يجب قبول PEP 516 أو PEP 517 قبل اتخاذ قرار بشأن ما إذا كان إنشاء sdist أولاً أمرًا صحيحًا (أنا شخصياً لا أعتقد ذلك).

يلخص PEP 516 ذلك على النحو التالي:

Being able to create new sdists from existing source trees isn't a thing pip does today,
and while there is a PR to do that as part of building from source, it is contentious and
lacks consensus.

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

مشكلة مشابهة إلى حد ما ما يجب فعله عند التثبيت من bare repo (بدلاً من توزيع المصدر أو يجب أن أقول الحزمة المنشورة) في npm - قم بتشغيل prepublish لحزم git url

rgommers ما رأيك بإضافة ملف .pipignore لسرد الملفات والأدلة ليتم تجاهلها مثل .gitignore بدلاً من ترميز بعض أسماء الملفات / الدليل مثل .git و .tox ؟

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

إذا كان npm يحتوي عليه ، فيجب أن يكون جيدًا :) - https://docs.npmjs.com/misc/developers#keeping -files-out-of-your-package

يؤدي هذا أيضًا إلى كسر أشياء مثل setuptools_scm بشكل فعال حتى أكثر من ذلك ^ ^ - تثبيت نقطة يجعل نسخة مجلد تكسر الأشياء الصعبة بالفعل

ما علاقة setuptools_scm بها؟ يجب تشغيلها على ريبو صالح وليس أي نوع من حزم المصدر .

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

قم بتضمين .pipignore ضمنيًا .git و .hg وما إلى ذلك مع وجود .pipignore فارغ يمنع هذا.

@ piotr-dobrogost ، سيتعطل تثبيت النقطة من الريبو المصدر في ظروف مختلفة حيث لا تنسخ النقطة سياقًا كافيًا - على سبيل المثال pypa / setuptools_scm # 138

فعلنا سابقا تجاهل الدلائل مثل .git وكذا وكسرت أشياء مثل PBR وكان لتراجع عن التغيير.

dstufft لا يزال يكسر الأشياء إذا كان أحدهم في

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

يجب أن يفعل pbr شيئًا غير معقول تمامًا إذا سقط بدون وجود .git dir ، لكن حسنًا ....

أتساءل ما إذا كان هناك أي تقدم في هذا؟ ليست فقط مجلدات .git أو أي مجلدات .${scm} مزعجة ، بل أسوأ بكثير إذا قام الأشخاص بتضمين .vagrant/ مع المصدر.

إن الحصول على .pipignore قابل للتخصيص سيساعد حقًا في تخفيف الألم.

لنقطة بيانات أخرى ؛ لدينا مزيج من Python و Javascript في بعض المشاريع ، حيث نستخدم Sphinx لتوثيق مشاريع Javascript الخاصة بنا. لذلك ، تقوم النقطة أيضًا بنسخ دليل كبير جدًا node_modules ، والذي يمكن أن يكون بطيئًا بشكل مؤلم.

لذلك سنصوت لخيار .pipignore حيث توضح حالة الاستخدام أن القيم المشفرة لن تكون بالضرورة كافية لجميع أنواع المشاريع.

يحتفظ الأشخاص بجميع أنواع القمامة في الشجرة خارج ملف SCM.

لدي بعض عمليات المحاكاة الكبيرة (16 جيجابايت +) التي تنتجها الكود الذي احتفظ به في نفس الدليل مع كود مصدر الحزمة (كطريقة لتتبع المشاريع المختلفة).

pip install . نسخها إلى my / tmp. نفدت مساحة القسم الضعيف بالفعل وتفشل النقطة بسبب خطأ في مساحة القرص.

إذا لم يكن من المفترض استخدام sdist ، وقام .pipignore بتوسيع الواجهة ، فماذا عن إعادة استخدام الكود لتحليل ملف MANIFEST.in / MANIFEST؟ يجب أن يكون قد وصف جميع الملفات اللازمة للتثبيت.

يبدو أن الحل الجيد هو استخدام تثبيت قابل للتعديل ( pip install -e $DIR ).

يبدو أن الحل الجيد هو استخدام تثبيت قابل للتحرير (تثبيت نقطي -e $ DIR).

باستثناء الاختبار ، هذا لا يختبر ما سيستخدمه المستخدم الذي يقوم بتثبيت الحزمة من pypi. (على سبيل المثال ، ستظل الحزم والوحدات التي لم يتم تعبئتها متوفرة)

آمل أن يكون هذا قد تم ذكره من قبل في هذا الموضوع.

قد يكون الحل الأفضل هو بناء sdist أو عجلة مباشرة باستخدام setup.py وتثبيت الأداة التي تم إنشاؤها باستخدام النقطة. بهذه الطريقة ، لن تقوم النقطة بعمل نسخ الدليل (لأنها حصلت على ملف للتثبيت منه) وهذه هي نفس النتيجة تمامًا كما تفعل مع pip install . (اعتبارًا من النقطة 9) ، مطروحًا منه نسخة الدليل.

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

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

@ andre-merzky من فضلك اهدأ.

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

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

pfmoore آسف على النغمة ، والإحباط كان يتحدث ... لقد

ركض في هذا أيضًا:

(env) $ find node_modules/ | wc -l
140287
(env) $ time pip install .
Processing /path/to/myproject
Installing collected packages: myproject
  Running setup.py install for myproject ... done
Successfully installed myproject-1.0

real    4m35.598s
user    0m6.928s
sys 0m7.992s

بعد إعادة التعيين:

(env) $ mv node_modules/ ../
(env) $ time pip install .
Processing /path/to/myproject
Installing collected packages: myproject
  Running setup.py install for myproject ... done
Successfully installed myproject-1.0

real    0m0.899s
user    0m0.496s
sys 0m0.120s

أين هو أحدث تقرير عن ملف تعريف المشكلة؟

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

هل هذا الدليل في الذاكرة؟

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

هل هو على الأقل في /tmp أو /dev/shm ؟ https://stackoverflow.com/questions/9745281/tmp-vs-dev-shm-for-temp-file-storage-on-linux هل يمكنه اكتشاف عدم استخدام tmpfs ويقترح إنشاء واحد؟

إنه في /tmp . يعتمد ذلك على stdlib tempfile .

سيؤدي تنفيذ PEP 517 إلى حل هذه المشكلة.

أواجه هذا الأمر مع أحدث إصدار للمطور من النقطة - اعتقدت أنه تمت إضافة دعم PEP 517 في النقطة 19 ، فهل يجب أن يستمر هذا الأمر؟

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

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

نواجه هذا https://github.com/pypa/pip/issues/2195#issuecomment -351258913 اليوم أيضًا. ما زال يحدث.

(venv) (venv) pip --version
pip 19.1.1 from /application/venv/lib/python2.7/site-packages/pip (python 2.7)

سيؤدي تنفيذ PEP 517 إلى حل هذه المشكلة.

الراوي: لم يفعل.

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

إصلاح هذا يتطلب التثبيت عبر sdist

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

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

باعتباري شخصًا مهتمًا بالبناء الداخلي وبالتالي لم يعجبه "يجب دائمًا السير عبر طريق sdist": لقد عقدت السلام مع "go sdist route" منذ وقت طويل.

هذه المشكلة مؤلمة جدًا إذا واجهتها ، و "نسخ كل شيء افتراضيًا" لا معنى له. لذا +10 لدغة الرصاصة.

إصلاح هذا يتطلب التثبيت عبر sdist

لقد افترضت ، بشكل غير صحيح ، أننا سنقوم بالتبديل باستخدام PEP 517.

أنا أتفق معك كليا هنا بالرغم من ذلك.

كان بإمكاننا إجراء IIRC ، لكن المناقشات التي كان من الممكن أن تثيرها حول ما إذا كان التثبيت عبر sdist كان مقبولاً كان أكثر من اللازم لإضافته في ذلك الوقت - وبما أن التثبيت عن طريق النسخ وبناء العجلة كان لا يزال خيارًا ، فقد اتخذت أقل إجهادًا مسار :-)

ما زلت أفضل التبديل إلى البناء عبر sdist ، لكن ليس لدي الوقت الآن للقيام بذلك بنفسي.

الحل البديل: استخدم نسخة ضحلة (قم بتغيير العمق ليناسب):

cd d:\code
git clone --depth=100 https://github.com/PROJECT/PROJECT.git d:/code/shallow-PROJECT
move d:\code\PROJECT d:\code\PROJECT-bloated
move d:\code\shallow-PROJECT d:\code\PROJECT

لتكرار وتلخيص:

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

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

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

أوه ، وكحل بديل لهذا ، تمت إضافته في # 6770 ، ستستبعد النقطة 19.3 الدلائل .nox و .tox عند النسخ. يجب أن يقلل هذا من الوقت الذي تستغرقه هذه التثبيتات لعدد لا بأس به من المستخدمين.

هذا لا يحل مشكلة الدلائل الكبيرة .git أو build - هذا هو الأسلوب الذي أوضحته في تعليقي أعلاه. :)

هذا لا يحل مشكلة الدلائل الكبيرة .git أو build - هذا هو الأسلوب الذي أوضحته في تعليقي أعلاه. :)

أعلم أن هناك بعض الأدوات التي تعتمد على .git ، ولكن هل يتم نسخ أي شخص يعتمد على build ؟ سيكون من الجيد إضافته إلى المتجاهلين ، وسعداء بإرسال PR إذا كنت توافق.

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

نعم ، ألق نظرة على المشكلات المرتبطة مثل # 7555.

لا تزال هذه المشكلة قائمة ، لأن الدليل الذي أقوم بالتثبيت منه ربما يحتوي على 10 ميغابايت من كود Python ، ولكن بعد ذلك الكثير من ملفات بيانات json و .git .

يجب حل ذلك عن طريق # 7882 (إنشاء أدلة محلية في المكان).

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

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

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

سأقول إنه أفضل بكثير.

قديم: noglob pip3 install . 3.76s user 2.51s system 12% cpu 50.245 total

الجديد: noglob pip3 install . 3.40s user 0.70s system 42% cpu 9.764 total

يعمل بشكل رائع / أسرع بالنسبة لي! : +1:

» pip --version
pip 20.0.2 
» time pip install .
noglob pip install .  8.03s user 18.47s system 25% cpu 1:44.84 total

» pip --version
pip 20.1b1 
» time pip install .
noglob pip install .  3.69s user 0.31s system 92% cpu 4.307 total

أقل من دقيقتين إلى 4 ثوانٍ ، شكرًا جزيلاً لك!

أشكركم على التقارير الإيجابيةPythonCoderASastrofrogklamann! :)

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

آسف للاضطراب الذي سوف يسببه هذا.

لسوء الحظ ، كان هناك عدد من المشكلات المتعلقة بتنفيذ عمليات الإنشاء في المكان

pradyunsg شكرا على التحديث. بعض التعليقات على المصطلحات (لا تتردد في تجاهلها ، لمعلوماتك فقط): هذه الجملة ، بالإضافة إلى gh-7555 ، أربكتني لأن pip لا يبني في مكانه. ما قصدته دائمًا الإصدارات الموضعية هو python setup.py build_ext --inplace (أو python setup.py develop ).

هنا قمت بتغيير المعنى إلى: "بناء بدون نسخ إلى tmpdir". لا تزال وحدات الامتداد لا ينتهي بها الأمر في مكانها ، بل ينتهي بها الأمر في build/ dir والذي عادة ما يتم تنظيفه بسهولة. سيكون من الجيد أن تكون أكثر وضوحًا في مثال gh-7555.

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

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

وما زلت غير متأكد من كيفية تطبيق هذه المصطلحات خارج setuptools

بالنسبة لأدوات مثل CMake و scikit-build ، أعتقد أنها تعني نفس الشيء: في الواقع ، في المكان ، تقع الثنائيات بجوار المصادر.

من ناحية أخرى ، تم اختراع "التثبيتات القابلة للتحرير" (على ما أعتقد) هنا ، وتعني kinda "في المكان الذي تعرف النقطة به".

على الرغم من الارتجاع ، لست متأكدًا مما - تم قبول الاقتراحات بامتنان

ربما مجرد "بناء محلي" (مقابل "نسخة إلى tmpdir وبناء" الحالية)؟

من ناحية أخرى ، تم اختراع "التثبيتات القابلة للتحرير" (على ما أعتقد) هنا ، وتعني kinda "في المكان الذي تعرف النقطة به".

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

يمكنك تجربة "بناء داخل الشجرة" (مشابه لـ "في الشجرة PEP 517 backend") أو "بناء في مصدر dir"

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

أحاول التفاف رأسي حول الحلول البديلة لذلك ، حيث لا يكون التثبيت القابل للتحرير خيارًا. هل هنالك أي؟

يمكن أن يكون الحل هو بناء عجلة (باستخدام الواجهة الخلفية للبناء مباشرة) ثم توجيه النقطة لتثبيتها

لماذا لا تكون الميزة اختيارية فلا تسبب مشاكل ولكن يمكن تفعيلها بواسطة وسيطة أو شيء مشابه؟

يمكن. كان سبب التراجع عن التغيير هو أنه لم يكن لدينا أي إلغاء أو فترة زمنية للحصول على تعليقات على التغيير. لدينا علامات جديدة للمساعدة في تسهيل ذلك (--use-feature و --deprecated-feature) ، ولكن يجب على شخص ما إعادة تطبيق / إعادة تقديم الوظيفة في هذا السياق الآن.

بشكل عام ، أعتقد أن ما نريد القيام به هنا هو:

• أضف --use-feature = in-tree-build كاشتراك في.
• قم بتبديل الإعداد الافتراضي في إصدار لاحق w / a --deprecated-feature = out-of-tree-build كخيار إلغاء الاشتراك + دفع مستخدمي --use-feature = in-tree-build لإسقاطها.
• قم بإسقاط كلا الخيارين في إصدار لاحق.

يمكن أن يكون الحل هو بناء عجلة (باستخدام الواجهة الخلفية للبناء مباشرة) ثم توجيه النقطة لتثبيتها

كنت أفكر بدون خطوة بناء إضافية. لكني أعتقد أنه لم يكن يجب أن أعتقد أبدًا أن بايثون يمكن أن تفلت من دون معادلات Makefile من البداية.