<p>فشل pip 19.0 في تثبيت الحزم التي تستورد الحزمة المراد تثبيتها من CWD</p>

يبدو أن هذه مشكلة في كيفية قيام برنامج pyinstaller باستيراد نفسه للتثبيت.

قد يكون من الجيد تقديم مشكلة في PyInstaller folks.

نستخدم حاليًا 18.1 ، والترقية إلى الإصدار 19.0 تسبب لنا هذه المشكلة أيضًا. هناك مشكلة ذات صلة في PyInstaller repo ، حيث يرجع ذلك إلى أن النقطة '' ليست في sys.path.

https://github.com/pyinstaller/pyinstaller/issues/2730

أعتقد أن هذا سير عمل شائع جدًا. تضع __version__ = "1.2.3" في foo/__init__.py ثم تفعل import foo في setup.py حتى لا تضطر إلى تحديد الإصدار في مكانين. ويمكن لأي مستخدم للمكتبة فحص الإصدار وفقًا لـ PEP 396 .

# foo/__init__.py
__version__ = "1.2.3"

# setup.py
from setuptools import setup

import foo

setup(..., version=foo.__version__)

أيضًا ، يحدث هذا فقط إذا كان لديك ملف pyproject.toml (و setup.py ). قم بإزالته والتثبيت يعمل بشكل جيد. لذا يبدو أن هناك بعض الاختلافات في السلوك هناك. ربما الطريقة التقليدية تعدل sys.path / PYTHONPATH ؟

آه ، أعتقد أنني فهمت ما يحدث. نظرًا لاستخدام ملف pyproject.toml ، فأنت تخبر النقطة أساسًا أنك تريد استخدام PEP 517/518.

# pyproject.toml
[build-system]
requires = ["setuptools", "wheel"]

ما سبق يخبر النقطة بأنها تحتاج إلى setuptools و wheel لبناء PyInstaller. ولكن في حالة PyInstaller ، فقد حصلت أيضًا على هذا في setup.py :

# setup.py
from PyInstaller import __version__

من منظور PEP 517 ، بصرف النظر عن setuptools و wheel ، فهذا يعني أنه يحتاج إلى إنشاء نفسه. وهو بالطبع غريب بعض الشيء.

# pyproject.toml
[build-system]
requires = ["setuptools", "wheel", "PyInstaller"]

كما هو مذكور في cjerdonek في https://github.com/pypa/pip/issues/6175#issuecomment -456769285 ، هل يمكن لشخص ما التحقق مما إذا كان --no-use-pep517 يصلح ذلك لهم؟

أظن أن سبب هذه المشكلة هو أن بناء العزل أو كود PEP 517 لا يتأكد من أن جذر دليل الحزمة موجود في المسار sys.path ، لأن الباندا لديها نسخة موجودة بجوار setup.py. أتذكر أن هذا حدث في مرحلة ما ، لكنني لا أتذكر ما كان ذلك النقاش. قد يعتبر هذا مشكلة في الواجهة الخلفية لبناء أدوات setuptools بدلاً من النقطة ، أو قد يكون خطأ في آلية عزل النقطة.

[...] هل يمكن لشخص ما التحقق مما إذا كان - no-use-pep517 يصلح هذا لهم؟

يتم تثبيت PyInstaller بشكل جيد باستخدام --no-use-pep517 .

حسنًا ، فهذه بالتأكيد مشكلة في كود PEP 517 الجديد وأنا متأكد تمامًا من أن المشكلة هي أن الدليل الذي يحتوي على جذر المشروع لم تتم إضافته إلى sys.path . ربما سيكون لدى pfmoore فكرة أفضل عما إذا كان ينبغي أن يكون ذلك هو استجابة النقطة أو أدوات الإعداد.

إذا كان هذا يساعد مثالًا آخر على ذلك (عبر apache-airflow هو pip install pendulum==1.4.4 ، لكن pip install --no-use-pep517 pendulum==1.4.4 يعمل.

تتبع المكدس الذي نحصل عليه مشابه:

Collecting pendulum==1.4.4
  Using cached https://files.pythonhosted.org/packages/85/a5/9fc15751f9725923b170ad37d6c61031fc9e941bafd5288ca6ee51233284/pendulum-1.4.4.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  Complete output from command /Users/ash/.virtualenvs/clean-airflow/bin/python3.7 /Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/tmprosed3kj:
  Traceback (most recent call last):
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 207, in <module>
      main()
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 197, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 54, in get_requires_for_build_wheel
      return hook(config_settings)
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 115, in get_requires_for_build_wheel
      return _get_build_requires(config_settings, requirements=['wheel'])
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 101, in _get_build_requires
      _run_setup()
    File "/private/var/folders/lr/9jc9vkgn025fn6jmwm4mv4_w0000gn/T/pip-build-env-g__m0jh6/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 85, in _run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 47, in <module>
      from build import *
    File "/Users/ash/.virtualenvs/clean-airflow/lib/python3.7/site-packages/pip/_vendor/pep517/build.py", line 7, in <module>
      from pip._vendor import pytoml
  ModuleNotFoundError: No module named 'pip'

أيضًا ، لا يعمل تثبيت ما يلي أيضًا مع pip v 19.0 ولكنه سيفعل في حالة استخدام - no-use-pep5517:
البندول == 1.5.0 (AttributeError: الوحدة النمطية 'enum' لا تحتوي على سمة 'IntFlag')
البندول == 1.5.1 (AttributeError: الوحدة النمطية 'enum' لا تحتوي على سمة 'IntFlag')
البندول == 2.0.0 (AttributeError: الوحدة النمطية 'enum' لا تحتوي على سمة 'IntFlag')
البندول == 2.0.1 (AttributeError: الوحدة النمطية 'enum' لا تحتوي على سمة 'IntFlag')
البندول == 2.0.2 (AttributeError: الوحدة النمطية 'enum' لا تحتوي على سمة 'IntFlag')

في حين يتم تثبيت 2.0.3 و 2.0.4 بشكل جيد.

فشل كارتوبي (على الأقل أحدث إصدار له) في التثبيت منذ 19.0 ، وفشل في استيراد الإصدار الموجود بجوار setup.py

هذه أيضًا مشكلة في بعض المشاريع التي أتعامل معها. نستخدم pyproject.toml لتحديد معلمات Python black الخاصة بنا ، ونقوم بعمل مماثل from project.version import __version__ في setup.py.

على الأقل أشعر أنني قادر على تحديد أي عزل للمشروع في pyproject.toml سيكون كافياً. يبدو من غير المعقول بالنسبة لي أن أجعل أي شخص يرغب في تثبيت المشروع يستخدم --no-buid-isolation أو --no-use-pep517

يبدو أن الفشل كان في get_requires_for_build_wheel ، وتعمل الواجهة الخلفية setuptools setup.py للقيام بنوع من الاستبطان لتحديد متطلبات البناء (الكود المحدد هنا ). يبدو هذا الرمز غريبًا بالنسبة لي ، ولا أفهم سبب طلبه. غريزتي الأولية هي أن هذا خطأ في الواجهة الخلفية لـ setuptools يجب معالجته من قبلهم.

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

ملخص:

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

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

أعتقد أنه من الشائع جدًا أن يقوم الأشخاص باستيراد شيء ما من الدليل الحالي إلى setup.py ، ويعاملون الأشياء بشكل عام كما لو أن setup.py موجود في $PWD .

أعتقد أنه من المعقول دفع هذه المسؤولية إلى setuptools ، لأنه على الأرجح المشروع الوحيد الذي يحتاجها حقًا.

نعم ، بالتفكير في هذا أكثر ، أنا متأكد من أنها مسؤولية خلفية setuptools. قبل PEP 517 ، تم تشغيل النقطة setup.py كبرنامج نصي ، لذلك وضعت قواعد Python القياسية دليل البرنامج النصي على sys.path . بموجب PEP 517 ، يتم استبدال استدعاء setup.py باستدعاءات الخطافات الخلفية ، لذلك تحتاج هذه الخطافات إلى الحفاظ على الدلالات. نظرًا لأن setuptools تدير setup.py قيد المعالجة من الخطافات ، فإنها تحتاج إلى إدارة sys.path نفسها. نأمل ألا يكون هذا حلًا كبيرًا لهم. jeanlaroche (أو أي شخص آخر

[...] هل يمكن لشخص ما التحقق مما إذا كان - no-use-pep517 يصلح هذا لهم؟

أستطيع أن أؤكد أن - no-use-pep517 يسمح pip install pandas بالنجاح.

يمكنني أيضًا أن أؤكد أن استخدام --no-use-pep517 يصلح لجميع حزمتي المعطلة

النجاح بالنسبة لي أيضا

pip install pyinstaller --no-use-pep517
Collecting pyinstaller
  Using cached https://files.pythonhosted.org/packages/03/32/0e0de593f129bf1d1e77eed562496d154ef4460fd5cecfd78612ef39a0cc/PyInstaller-3.4.tar.gz
Requirement already satisfied: setuptools in c:\python37\lib\site-packages (from pyinstaller) (39.0.1)
Collecting pefile>=2017.8.1 (from pyinstaller)
  Downloading https://files.pythonhosted.org/packages/ed/cc/157f20038a80b6a9988abc06c11a4959be8305a0d33b6d21a134127092d4/pefile-2018.8.8.tar.gz (62kB)
    100% |████████████████████████████████| 71kB 1.0MB/s
Collecting macholib>=1.8 (from pyinstaller)
  Downloading https://files.pythonhosted.org/packages/41/f1/6d23e1c79d68e41eb592338d90a33af813f98f2b04458aaf0b86908da2d8/macholib-1.11-py2.py3-none-any.whl
Collecting altgraph (from pyinstaller)
  Downloading https://files.pythonhosted.org/packages/0a/cc/646187eac4b797069e2e6b736f14cdef85dbe405c9bfc7803ef36e4f62ef/altgraph-0.16.1-py2.py3-none-any.whl
Collecting pywin32-ctypes (from pyinstaller)
  Using cached https://files.pythonhosted.org/packages/9e/4b/3ab2720f1fa4b4bc924ef1932b842edf10007e4547ea8157b0b9fc78599a/pywin32_ctypes-0.2.0-py2.py3-none-any.whl
Collecting future (from pefile>=2017.8.1->pyinstaller)
  Downloading https://files.pythonhosted.org/packages/90/52/e20466b85000a181e1e144fd8305caf2cf475e2f9674e797b222f8105f5f/future-0.17.1.tar.gz (829kB)
    100% |████████████████████████████████| 829kB 1.6MB/s
Installing collected packages: future, pefile, altgraph, macholib, pywin32-ctypes, pyinstaller
  Running setup.py install for future ... done
  Running setup.py install for pefile ... done
  Running setup.py install for pyinstaller ... done
Successfully installed altgraph-0.16.1 future-0.17.1 macholib-1.11 pefile-2018.8.8 pyinstaller-3.4 pywin32-ctypes-0.2.0

لا أعتقد أن هذا خطأ في pip / setuptools ، من قراءتي لقسم بيئة البناء في PEP 517 ، لا يبدو أنه يجب افتراض أي شيء عن البيئة باستثناء أن التبعيات المعلنة في pyproject.toml متوفرة.

أليس كذلك استيراد الحزمة التي يتم تثبيتها من setup.py ممارسة سيئة؟ هناك طرق أفضل بكثير للحفاظ على إصدار الحزمة في مكان واحد ، على سبيل المثال كما هو موضح في دليل التعبئة هذا من PyPA.

في المناقشة في pypa / setuptools # 1642 ، كنا نأمل أنا و يتوقفون عن الاعتماد على حقيقة أن . موجود في sys.path عند تنفيذ نص بيثون ، وابدأ في نقل الأشخاص إلى دلالات أكثر وضوحًا.

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

هل هذا القرار بشأن جزء pip لا رجوع فيه في هذه المرحلة؟ ربما يمكننا الحصول على pyproject.toml للاشتراك في PEP 518 ، لكن PEP 517 لا يتم تشغيله ما لم تحدد بالفعل الواجهة الخلفية للبناء؟

بصراحة ، إنه وضع صعب في كل مكان ، لكنني أعتقد أنه من الأسهل بالنسبة لـ pip التحذير من هذا الأمر أكثر من setuptools . إذا جعلنا PEP 517 مشتركًا في الوقت الحالي وقلنا أن وجود pyproject.toml سيبدأ في تشغيل PEP 517 بعد 20.0 أو 21.0 ، يمكننا إنشاء دليل ترحيل والبدء في إصدار تحذيرات في pip لهذا الغرض - " build-backend مفقود من pyproject.toml ، تكون على علم أنه بعد إصدار 21.0، وبناء العزلة افتراضية باستخدام setuptools.build_meta ، راجع دليل الهجرة في ..."

أليس كذلك استيراد الحزمة التي يتم تثبيتها من setup.py ممارسة سيئة؟ هناك طرق أفضل بكثير للحفاظ على إصدار الحزمة في مكان واحد ، على سبيل المثال كما هو موضح في دليل التعبئة هذا من PyPA.

لكي نكون منصفين ، يحدد هذا الدليل استيراد الحزمة التي يتم تثبيتها من setup.py كاستراتيجية 6 ، لذا فهي بالتأكيد شائعة إلى حد ما. في هذه المرحلة ، إذا كنا نبتعد عن هذا النوع من الإستراتيجية ، فيجب تحديث تلك الصفحة حتى لا يتم تضمينها بعد الآن.

كان قرار تشغيل PEP 517 بشأن وجود pyproject.toml اختيارًا متعمدًا (ربما كانت المناقشة حول مشكلة تنفيذ PEP 517 أو العلاقات العامة ، لكن ليس لدي الوقت الآن لتحديد موقعها). من الواضح أنه يمكن تغييره في ضوء ما نراه هنا ، لكن لا ينبغي لنا القيام بذلك دون مراعاة الأسباب التي دفعتنا إلى اتخاذ القرار الذي اتخذناه.

لا (لا ينبغي لـ IMO) أن تأخذ وجهة نظر حول ما إذا كان setup.py محقًا في افتراض أن دليل المشروع موجود على sys.path ، لذلك أنا متردد نوعًا ما في تغيير النقطة ببساطة لأن setuptools تريد دفع قيمة افتراضية مختلفة عند استخدام الواجهة الخلفية. بينما أوافق على أن استيراد المشروع الذي يتم بناؤه في setup.py يواجه عددًا من الصعوبات ، فليس الأمر كما لو كان شيئًا أثار التحذيرات حتى الآن ، لذلك افترضت أن الواجهة الخلفية يجب أن تحافظ على هذه الدلالات. بعبارة أخرى ، حتى إذا حذرت النقطة كما تقترح ، فلماذا يقرأ المستخدمون "بناء العزل سيتحول إلى استخدام setuptools.build_meta " على أنه يعني أنك لن تتمكن من استيراد مشروعك من setup.py "؟ يبدو أن حقيقتين لا علاقة لهما بي ...

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

Pip نفسها لا (لا ينبغي لـ IMO) أن تأخذ رأيًا حول ما إذا كان setup.py محقًا في افتراض أن دليل المشروع موجود في sys.path ، لذلك أنا متردد نوعًا ما في تغيير النقطة لمجرد أن setuptools تريد دفع افتراضي مختلف عند استخدام الواجهة الخلفية.

صحيح ، الأمر هو أن pip يفترض أن استدعاء الخطافات setuptools.build_meta هو ويجب أن يكون مكافئًا تمامًا لاستدعاء setup.py . لقد رأينا بالفعل حالات لم يكن الأمر كذلك ، وأعتقد أنه لا يزال يتعين تحديد ما إذا كنا ( setuptools ) نريد أن يكون العقد setuptools.build_meta "هذا يعادل استدعاء python setup.py "أو إذا أردنا بدلاً من ذلك أن يكون" هذه نسخة أكثر إحكامًا ومعزولة من استدعاء setup.py مباشرة ".

بالطبع يمكن أن يقول setuptools "هذا ليس عقد الوظيفة لذا لن نصلحه" و pip يمكن أن يقول ، "كان قرارنا أن يكون الخيار الافتراضي هو PEP 517" و يمكننا القول أن الخطأ موجود في المشروع الآخر ، ولكن ربما يكون التنسيق فكرة جيدة.

بعبارة أخرى ، حتى إذا حذرت النقطة كما تقترح ، فلماذا يقرأ المستخدمون "بناء العزل سيتحول إلى استخدام setuptools.build_meta" على أنه يعني أنك لن تكون قادرًا على استيراد مشروعك من setup.py؟ يبدو أن حقيقتين لا علاقة لهما بي ...

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

يمكننا أيضًا إنشاء خلفية PEP 517 "وهمية" في setuptools مثل setuptools.build_meta_legacy التي فقط chdir s في الدليل الجذر وتستدعي setuptools.build_meta ، بهذه الطريقة يمكن للأشخاص الاشتراك في السلوك القديم فقط إذا احتاجوا إليه قبل أن يبدأ في الانهيار.

أنا شخصياً أتفق مع النهج الحالي بالاعتماد على وجود ملف pyproject.toml. تنبع مشكلات IMO من الأشخاص الذين يستخدمون pyproject.toml لأشياء أخرى غير التغليف.

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

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

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

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

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

بينما لا يحدد PEP 517 أي شيء حول ماهية الخلفية الافتراضية

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

يحتوي Pip حاليًا على مسارين للتثبيت - مسار PEP 517 والمسار القديم setup.py . هذا مصدر مشكلات الصيانة والأخطاء المحتملة. اخترنا أن نجعل PEP 517 هو الوضع الافتراضي إذا كان pyproject.toml موجودًا لضمان استخدام مسار PEP 517 (من غير المحتمل أن تتسرع المشاريع لإضافة build-backend = setuptools.buid_meta ، لذلك بدون السلوك الحالي ، فإن الاحتمالات هي ذلك اختبار كل من كود PEP 517 الخاص بالنقطة والواجهة الخلفية لـ setuptools ، سيبقى بالقرب من الصفر لفترة ممتدة). هناك خيار إلغاء الاشتراك في شكل --no-use-pep517 وجه التحديد لتلبية الحالات (المفترضة النادرة) حيث كانت الواجهة الخلفية setuptools غير مناسبة.

لا أعتقد أن أي شخص يتوقع أن تكون أدوات setuptools ترغب في وجود اختلافات دلالية بين setup.py والواجهة الخلفية ، لذا فإن احتمال أن --no-use-pep517 ستكون مطلوبة لحل الاختلافات الدلالية في كثير من الأحيان بحيث يجب أن تكون كذلك لم يتم حتى النظر في التقصير.

يمكننا أيضًا إنشاء واجهة خلفية "وهمية" PEP 517 في أدوات الإعداد مثل setuptools.build_meta_legacy التي تقوم فقط بتشغيل chdirs في الدليل الجذر واستدعاء setuptools.build_meta ، وبهذه الطريقة يمكن للأشخاص الاشتراك في السلوك القديم فقط إذا احتاجوا إليه قبل أن يبدأ في الانهيار .

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

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

لمشرفي الحزم الذين يتطلعون إلى حل هذه المشكلة للمستخدمين لديك: لقد قمت بنشر رقاقة تنفذ الإصلاح sys.path .

https://pypi.org/project/setuptools-localimport/

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

لقد قمت بنشر رقاقة تنفذ إصلاح sys.path.

هذا رائع! بغض النظر عن الإصلاح النهائي ، هذا مثال رائع حقًا على مرونة نظام الخطاف PEP 517 :-)

لقد أصلحته عن طريق الرجوع إلى إصدار النقطة الخاص بي تحت 19.x ثم حاولت التثبيت وذهبت بنجاح

هناك حالة استخدام ثالثة: ماذا عن الحزم التي توفر الواجهة الخلفية للبنية الخاصة بها؟ على سبيل المثال: يدرج setuptools نفسه wheel كمتطلب بناء:

[build-system]
requires = ["wheel"]
build-backend = "setuptools.build_meta"

هذا بالطبع سيفشل إذا كان كود النقطة الخاص بمعالجة PEP 517 لا يضيف دليل المصدر إلى sys.path .

من PEP 517:

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

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

يبدو لي أن نفس القسم أيضًا يؤكد أن أدوات الإنشاء لا ينبغي أن تتوقع أن يكون دليل المشروع في بيئة الإنشاء sys.path .

كيف يعمل ذلك مع --no-binary :all: ؟

pfmoore البديل

تحرير: شيء من هذا القبيل

project/
    custom_build.py
    src/
        my_package/
            __init__.py
            ...
    pyproject.toml  

[build-system]
requires = []
build-backend = "custom_build"

# Maybe the custom backend specifies metadata like this…
[tool.custom_build.metadata]
name = "my-package"
dependencies = []
packages = ["my_package"]

ربما يكون الحل هو إضافة تكوين اختياري جديد ، للإشارة إلى مكان العثور على الوحدات أثناء الإنشاء؟

[build-system]
requires = []
build-backend = "custom_build"
build-backend-findpath = ["build_systems"]   # Put custom_build.py above in a subdirectory.

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

إذا تم حذف build-system بالكامل ، فسيتم تعيين القسم افتراضيًا على:

requires = ["setuptools", "wheel"]
build-backend = "setuptools.build_meta"
build-backend-findpath = [""]

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

من المزايا الإضافية لهذا الحل أنه يمكن عمل كل شيء في صورة نقطة (وحدة pep517 الموردة ، في الواقع). لا شيء يحتاج إلى تغيير في أدوات الإعداد أو المشاريع المعطلة الحالية.

البديل من الموقف هو أن الحزمة توفر نظام بناء مخصص.

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

في الواقع ، بعد التحقق من ذلك ، يقول PEP 517 صراحة (في القسم الموجود على build-backend ) "عند استيراد مسار الوحدة ، لا ننظر في الدليل الذي يحتوي على شجرة المصدر ، ما لم يكن ذلك في sys.path على أي حال "مما يعني أنه لا يُنصح صراحة بوجود خلفيات خلفية داخل الشجرة. ما إذا كان شخص ما يمكن أن يعمل على حل هذا الأمر باستخدام تعليمات برمجية ملتوية بما فيه الكفاية ، لست متأكدًا (لكنني لا أظن ذلك).

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

TL. دكتور؛ كل ما يمكنني تقديمه هو ذاكرتي للمناقشات في ذلك الوقت - قد يكون من الأفضل البحث في الأرشيف عن الخلفية الفعلية.

لا أعرف ما إذا كان مؤلفو PEP قد اعتبروا ذلك - لا أتذكر أي مناقشة حول هذه المسألة عندما تم تطوير PEP.

لقد بدأت للتو في البحث في الأرشيف ، ويبدو أن هذا السؤال قد نوقش بالفعل بالتفصيل في نهاية العملية (أو على الأقل في داخلها). لا أعرف موقع الويب الأفضل لعرض الأرشيفات ، ولكن إليك نقطة واحدة حيث تبدأ المناقشة في الحديث عن هذا السؤال مرة أخرى (28 يوليو ، 2017):
https://mail.python.org/pipermail/distutils-sig/2017- يوليو/031109.html
https://www.mail-archive.com/[email protected]/msg26624.html

على سبيل المثال ، ينتهي هذا البريد الإلكتروني المحدد بـ-

نظرًا لمقدار المشاكل التي نواجهها مع PEP 517 بالفعل ، فقد يكون من المنطقي أن يكون لديك PEP 517 فقط يفرض عدم وجود الدليل على sys.path ، وإجراء متابعة بسيطة لـ PEP فقط لمسار python.

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

لطيف! شكرا لإيجاد ذلك :-)

لذلك قمت بقراءة مجموعة من رسائل البريد الإلكتروني ، وأعتقد أنه يمكنك على الأقل تخطي ذلك إلى 29 أغسطس ، حيث يبدو أن نيك يقترح وجود إجماع على ترك دليل المصدر _out_ الخاص بـ sys.path:
https://mail.python.org/pipermail/distutils-sig/2017-August/031413.html
(واحدًا تلو الآخر ، أصبح الناس مقتنعين بحجج ناثانيال).

ومع ذلك ، في نفس البريد الإلكتروني المرتبط أعلاه ، يقول Nick ما يلي :)

1. إذا كان حذفها يمثل مشكلة حقيقية ، فمن المحتمل أن نكتشف ذلك قريبًا بما يكفي كجزء من تنفيذ الإعداد.

هذه فقرة كاملة من البريد الإلكتروني:

لذلك أعتقد أننا يمكن أن نعتبر هذا الحل لصالح "يجب على Frontends التأكد من أن الدليل الحالي ليس على sys.path قبل استيراد الواجهة الخلفية المعينة" ، لأن البدء من هناك سيعني زيادة فرصنا في تعلم شيء جديد كجزء من طرح API المقبولة مؤقتًا.

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

شكرا لشباك الارشيف لناcjerdonek. توضيح فهمي الحالي للمشكلة:

1. تفترض الكثير من ملفات العالم الحقيقي setup.py حاليًا أن الدليل الحالي موجود على sys.path عند تشغيلها ، مما يؤدي إلى إنشاء مشكلات غريبة في التمهيد حيث تعامل المشاريع نفسها على أنها تبعية لوقت التثبيت
2. يقول PEP 517 صراحةً أن الواجهات الأمامية للبناء يجب ألا تضيف ضمنيًا الدليل الحالي إلى sys.path (لا يقول أي شيء عن الخلفيات)
3. pip 19.0 pyproject.toml بدون قسم build-system معادلاً لقسم build-system الذي يحدد الواجهة الخلفية setuptools
4. لا تضيف الواجهة الخلفية setuptools PEP 517 حاليًا الدليل الحالي إلى sys.path أيضًا (نظرًا لأن الابتعاد عن النقطة 1 أعلاه يعتبر هدفًا مرغوبًا في المستقبل)
5. يتوفر حلان مؤقتان للمشروعات الحالية بينما يتم تحسين السلوكيات الافتراضية: تثبيت pip إلى أقل من 19.0 ، وتعيين الخيار --no-use-pep517 بشكل صريح. ومع ذلك ، لا يكتشف الأشخاص هؤلاء إلا بعد اكتشافهم لأول مرة أن ترقية pip يكسر بنياتهم.

من منظور وظيفي ، أعتقد أن التغيير الأساسي الذي نريد إدخاله هو أنه في حالة " pyproject.toml بدون قسم build-system " ، ثم الدليل الذي يحتوي على setup.py يجب أن ينتهي به الأمر على sys.path مرة أخرى. هناك طريقتان رئيسيتان للتعامل مع ذلك:

1. احصل على pip للقيام بذلك. هذا له تأثير جانبي مؤسف وهو جعل سلوك الواجهة الأمامية يعتمد ، وبالتالي من المحتمل أن ترى المشاريع الحالية تفشل في التثبيت ما لم تنفذ جميع الواجهات الأمامية نفس الحل
2. احصل على setuptools PEP 517 الخلفية للقيام بذلك ، من خلال فحص pyproject.toml build-system لقسم setup.py في sys.path إذا كان كل من إدخال القسم والمسار مفقودًا. لا تزال هناك حاجة إلى pip في هذه الحالة ، لأنه يجب أن يحدد إصدارًا أدنى من setuptools الذي يعالج بشكل صحيح حالة "no build-system section".

من أجل جعل الأشياء تعمل لصالح المستخدمين النهائيين في أسرع وقت ممكن ، دون أن نغرق أنفسنا في أي زوايا تصميم مؤسفة ، أقترح في الواقع حلًا من 3 خطوات:

1. قم بإصدار pip (19.0.1؟) الآن الذي يضيف الإدخال الإضافي sys.path للحالة "no build-system entry". في هذه المرحلة ، يجب أن تختفي مشكلة التوافق إلى حد كبير للمستخدمين النهائيين.
2. قم بإصدار setuptools يتعامل مع إضافة sys.path إذا لم تقم الواجهة الأمامية بذلك بالفعل.
3. في إصدار لاحق pip ، قم بتغيير حالة "no build-system entry" لإسقاط الغلاف الخاص ، وبدلاً من ذلك قم بتعيين إصدار أدنى أكثر صرامة مقابل setuptools .

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

لقد أنشأت الواجهة الخلفية build_meta_legacy في pypa / setuptools # 1652. أفضّل حقًا أن يتحول pip إلى استخدام setuptools.build_meta_legacy كخلفية افتراضية ، لكنني أعتقد أن إنشاء واجهة خلفية مضمّنة "قديمة" بقدر ما أشعر بالراحة في setuptools . لا أريد أن أعلق إلى أجل غير مسمى دعم "مضاهاة python setup.py install " بالكامل في الواجهة الخلفية الرئيسية لـ setuptools PEP 517.

أنا في حيرة من أمري قليلاً لماذا لا ترغب setuptools في محاكاة تشغيل البرنامج النصي محليًا هنا TBH. يبدو أنه يطالب المستخدمين النهائيين بالارتباك عندما يعمل python setup.py bdist_wheel بشكل صحيح ، لكن pip wheel لا يعمل (بافتراض أنهم قد قاموا بتعيين الواجهة الخلفية للبنية غير القديمة).

ما هو المبرر؟

ما هو المبرر؟

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

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

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

كان الحصول على اتفاق على أن جميع الأدوات يمكن أن تدعم "build sdist" و "build wheel" صعبًا بما يكفي لدرجة أنني لا أتوقع أن يتم تمديد قائمة العمليات القياسية مرة أخرى قريبًا.

فقط كملاحظة ، لا أعتقد أن PEP 517 كان لديه هدف تصميمي يتمثل في إمكانية الوصول إلى جميع أدوات البناء عبر الخطافات.

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

آه ، حسنًا. آسف لسوء الفهم.

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

شكرا لبحثك في المحفوظات cjerdonek!

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

هل هناك أي سبب لعدم تخطي الخطوة 1 المذكورة أعلاه؟

لا. يمكننا رفع الحد الأدنى للإصدار المطلوب بشكل مباشر.

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

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

نظرًا لأن الخلفيات يتم تشغيلها في عملية فرعية (وفي الواقع ، باستخدام المشروع المورّد pep517 ، والذي يضيف مستوى إضافيًا من المراوغة) ، فليس من الواضح على الإطلاق كيف قمنا بتعيين sys.path لـ ربط الخلفية. كحد أدنى ، سنحتاج إلى تضمين PYTHONPATH مما يعني القلق بشأن الحالات التي يكون فيها المستخدم لديه بالفعل PYTHONPATH set ، وكيف يستخدمه رمز العزل.

بشكل أساسي ، تعيين sys.path بالنقطة هو ، كما أظن ، غير تافه بشكل واضح. من غير المحتمل أن يكون لدي وقت للنظر في التفاصيل ، ناهيك عن كتابة التصحيح (والتأكد من اختباره بشكل صحيح!) بنفسي.

أعتقد أن الحصول على خلفية setuptools ثابتة هو أسرع طريقة للتقدم.

تتمثل خطتي طويلة المدى في إهمال جميع الاستدعاءات المباشرة لـ setup.py لصالح الاستدعاء غير المباشر إما من خلال واجهات PEP 517 الأمامية أو ما يعادلها (للأوامر الأخرى).

تضمين التغريدة إجرائي setup.py يجب أن يموت. لا ينبغي أن توجد لأي سبب من الأسباب. لأن هذه "المرونة" مصدر لا نهاية له للألم والانهيارات. من المستحيل ترحيل setup.py وبالتالي كل مشاكل حزم Python.

أود استبدال setup.py بـ package.json وإضافة قسم Python له بدلاً من تنسيق وصف الحزمة الآخر.

على الأقل بعد ذلك يمكنني استخدام محددات الإصدار ==1.x .

techtonik من فضلك اذهب بعيدا. تظل مساهماتك غير البناءة غير مرحب بها في أي مشروع أشارك فيه.

سمح لي العمل على # 6210 بالإجابة على سؤالي الخاص من أعلى حول مدى صعوبة معالجة هذا على المستوى pip : التحدي هو أن المعلومات حول ما إذا كان يجب إدراج دليل المصدر كـ sys.path[0] يحتاج إلى نفق من الكود الذي يقرأ pyproject.toml وصولًا إلى PEP 517 hook caller ، ثم من هناك إلى البرنامج النصي المضمن الفعلي قيد المعالجة.

هذه قابلة للتنفيذ بدون تغييرات معمارية كبيرة (بادئة pip._implicit. على اسم الواجهة الخلفية للبناء للجزء الأول ، و PEP517_SYS_PATH_0 env var للجزء الأخير) ، لكن هذا يعني تعديل pep517 المباع بشكل مؤقت رمز setuptools جاهزًا.

تستند خطتي الانتقالية على افتراض أن الأشخاص سيحتاجون إلى مزيد من الوقت للعمل على آلية الانتقال طويلة الأمد على جانب setuptools - بينما تبدو الخلفية الانتقالية المخصصة لـ

نعم ، أنا أتفق مع هذا. لقد اقترحت هذا فقط في مشاركة مختصرة ، هناك شيئان أود أن أقول أنهما مهمان:

1. الحصول على إصلاح هناك للمستخدمين في أسرع وقت ممكن
2. الحصول على الانتقال الصحيح في المكان.

أنا شخصياً أعتقد أن الشيء الصحيح الذي يجب فعله هو إزالة "وجود pyproject.toml يجعلك تختار منطق PEP 517" حتى يكون لدينا منطق الانتقال في مكانه. بالنظر إلى أن التغييرات التي تم إجراؤها على setuptools لها عواقب على واجهة برمجة التطبيقات التي تواجه الجمهور ، وفي pip سيؤدي ذلك إلى تأخير ما تبين أنه تغيير غير متوافق مع الإصدارات السابقة ، فمن المنطقي بالنسبة لي أن نفذ الإصلاح السريع في pip بينما نراجع الطريق إلى الأمام مقابل setuptools .

مع تشغيل كلا الأسلوبين على جهازي المحلي ، اختبرت كل من # 6210 و # 6212 مقابل المتطلبات الأصلية PyInstaller==3.4 .

• # 6210 عملت حسب الرغبة: https://github.com/pypa/pip/pull/6210#issuecomment -458144828
• # 6212 لا يتصرف كما هو متوقع: https://github.com/pypa/pip/pull/6212#issuecomment -458148519

لا أعرف ما إذا كان الفشل # 6212 يمثل مشكلة في إعداد الاختبار ، أو إذا كانت هناك بالفعل مشكلة أخرى في الإصدار التجريبي من setuptools ، فأنا أعرف فقط أن هناك المزيد من أعمال التكامل التي يتعين القيام بها قبل أن نكون واثقين من هذا الحل ، بينما أنا واثق في # 6210 الآن - الشيء الوحيد الخطأ مع ذلك هو أن انها التوافق الإختراق الرهيبة التي لا نريد pip لدينا لتحمل إلى الأبد.

يبدو أن --no-cache مسؤول عن هذا الفشل assert على # 6212. بدلاً من ذلك ، أعطى الاختبار باستخدام --cache-dir اختبارًا محليًا ناجحًا: https://github.com/pypa/pip/pull/6212#issuecomment -458166386

(سأكون غير متصل بالإنترنت لمدة 18 ساعة تقريبًا للنوم والعمل ، لذلك يجب أن يشعر الناس بالحرية في الركض مع أيهما من # 6210 أو # 6212 منطقيًا في هذه الأثناء)

لقد قمت بتحديث العنوان ليعكس الموقف بشكل أفضل. شكرا ncoghlan على

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

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

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

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

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

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

(تحرير: شكرًا جزيلاً أيضًا لـ pganssle و cjerdonek و pfmoore و pradyunsg و ncoghlan وأي شخص آخر بذل مجموعة من الوقت والجهد في هذا الأمر)

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

فقط للدائرة مرة أخرى إلى هذا - فإن الإعداد الافتراضي الجديد setuptools.build_meta_legacy يحل مشكلة استخدام PEP 517 لكل شيء باستثناء الخلفيات الخلفية PEP 517 ، وهي مشكلة لـ setuptools نفسها. إذا لم نحل ذلك ، فكما يشير @ benoit-pierre في pypa / setuptools # 1644 ، فلن يكون من الممكن للأشخاص استخدام pip install --no-binary :all: لأي مشروع يعتمد على setuptools (أو من المفترض أن يكون أي مزود خلفية PEP 517).

هل يجب أن نناقش ذلك في هذا الموضوع ، أم ننشئ موضوعًا جديدًا لمناقشته؟

هل يجب أن نناقش ذلك في هذا الموضوع ، أم ننشئ موضوعًا جديدًا لمناقشته؟

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

لا أعتقد أن حل المشكلة باستخدام واجهات بناء الخلفية --no-binary :all: أي مكان قريب من الأهمية مثل هذا. إذا كان المستخدم يحدد بالفعل --no-binary :all: ، فيمكنه بسهولة إضافة --no-use-pep517 .

رقم PR # 6229 الجديد:

1. ينفذ الحل المؤقت المقترح من pganssle لجعل قسم build-system في pyproject.toml المتطلبات الأولية للاشتراك تلقائيًا في PEP 517 (تأجيل خيار "any pyproject.toml file "- في إصدار لاحق)
2. يضيف 3 حالات اختبار مخصصة تغطي استيراد حزمة مجاورة من setup.py

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

فأين يترك ذلك setuptools.build_meta_legacy ؟ هل المقترح الآن يتطلب المشاريع التي تحتاج وظيفة "استيراد الحزمة المجاورة" لتحديدها صراحة في pyproject.toml ؟ إذا كان الأمر كذلك ، فإنني أقترح بشدة أن هناك حاجة إلى التوثيق في مكان ما ، إلى جانب حقيقة أن استيراد الحزم المجاورة بدون تلك المواصفات قد تم إهماله وستتم إزالته في النقطة 19.X (نحتاج إلى الاتفاق على ما هو X) ، لا يمكننا القيام بذلك إهمال برمجي (لا أعتقد) ولكن هذا سبب إضافي لتوثيقه بوضوح ، لذلك لا نتهم (مرة أخرى) بإزالة الوظيفة دون إشعار كافٍ.

تحرير: لكن بخلاف ذلك ، شكرًا على العلاقات العامة الجديدة والملخص.

تحرير 2: أرى أنك أغلقت عرض setuptools.build_meta_legacy . لست متأكدًا من أنني أحب ذلك ، لأنه يفقدنا الفرصة لنقول الآن ما هي خطتنا طويلة المدى ، لذا تمديد أي فترة إهمال ، كما ذكرت أعلاه ...

pfmoore لا ، فهذا يعني أن العودة إلى السلوك المطلوب يجب أن تتم تغطيتها من خلال مشكلة جديدة مرتبطة بإزالة الحل البديل # 6163 (ربما عن طريق التحديث إلى setuptools الذي يوفر setuptools.build_meta_legacy ).

تحرير: في الوقت الحالي ، لقد قمت للتو بإعادة فتح # 6212 ، لكنني أعدت تسميتها لتوضيح أنني لا أعتقد أنه يجب علينا انتظار مناقشة build_meta_legacy بالكامل قبل إصلاح أوامر التثبيت الفاشلة حاليًا.

كان اقتراحي في الواقع أن الاشتراك في PEP 517 يحدد build-system.build-backend وليس وجود build-system على الإطلاق ، وأنه من الآن وحتى إصدار 19.1 ، سيضيف setuptools build_meta_legacy و pip يستخدمه كخلفية افتراضية.

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

كان اقتراحي هو أن الاشتراك في PEP 517 هو تحديد build-system.build-backend

... والتي يمكن معالجتها ببساطة عن طريق تعيين use_pep517 = False في الحالة الاحتياطية (بدلاً من تعيينها على has_pyproject وهو ما نقوم به الآن.

في 19.1 ، ربما إذا لم تتمكن النقطة من العثور على setuptools.build_meta_legacy ، فيجب أن تعود إلى مسار الكود القديم

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

ملاحظة: الافتراضي use_pep517 = False هو ما بدأ به # 6229 ، لكنه تسبب في إخفاقات في اختبارات PEP 518.

1. و" build-system.requires ضبط" القضية لديه لاستخدام بناء العزلة، بحيث يمكن تثبيت التبعيات المطلوبة دون التأثير على البيئة الوالدين. أسهل طريقة للقيام بذلك بالنظر إلى بنية الكود الحالية هي تعيين use_pep517 = True في هذه الحالة ، لذلك فعلت ذلك ، وحصلت على حالة الاختبار مرة أخرى.
2. يشير الجدول المفقود [build-system] إلى أن pyproject.toml يتم استخدامه للتو لتخزين الإعدادات في الجدول [tools] ، لذلك يجب أن ينتج عن ذلك use_pep517 = False ليكون حلاً فعالاً للمشكلة التي تم الإبلاغ عنها في الأصل ، لذلك حددت حالة الاختبار هذه على أنها فشل متوقع.
3. هذا يترك حالة "الجدول الفارغ [build-system] " ، والتي أعتقد أنه يمكن حلها بشكل معقول في أي من الاتجاهين. ومع ذلك ، نظرًا لأنني لا أعتقد أن هذه الحالة بالذات ستظهر كثيرًا في الممارسة العملية (لماذا يواجه أي شخص مشكلة إضافة جدول build-system بدون تعيين إما requires أو build-backend ؟) ، اخترت حلها بطريقة تعني أن حالة اختبار PEP 518 المحددة مسبقًا قد نجحت ، بدلاً من إضافة علامة فشل متوقعة ثانية.

لحل 3 في الاتجاه الآخر ، سنحتاج إلى تغيير الخط:

use_pep517 = build_system is not None

بدلا من ذلك:

use_pep517 = build_system is not None and build_system.get('requires', None)

وبهذه الطريقة ، فإن الطلبات غير الفارغة فقط هي التي ستشترك في عزل بناء PEP 517 (وهو ما يعني أيضًا إضافة حالة اختبار رابعة ، نظرًا لأن الحقول الفارغة وغير الفارغة build-system.requires ستتصرف الآن بشكل مختلف).

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

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

techalchemy نعم ، كان الافتراض الأصلي في pip أن setuptools.build_meta يعمل بنفس الطريقة من منظور sys.path الذي يفعله الاستدعاء المباشر لـ setup.py ، وهذا الافتراض ثبت خطأ. بمجرد توفر إصدار setuptools يحتوي على الواجهة الخلفية setuptools.build_meta_legacy المحددة في https://github.com/pypa/setuptools/pull/1652 ، يمكن إكمال # 6212 ، وهذا سيكون طويلاً قرار المدى. ومع ذلك ، لا يوجد وقت وصول متوقع حالي لمثل هذا الإصدار ، لذلك نحتاج إلى مواصلة استكشاف قرارات pip - فقط لاستعادة الدليل المصدر على sys.path للحزم التي ليست صراحة "PEP 517 أصلية ".

في # 6229 ، قمت بتنفيذ اقتراحpganssle بتأجيل اعتماد "PEP 517 افتراضيًا" ، ولكن يبدو أن هذا يسبب مشاكل أكثر مما يحل بسبب تغيير آخر في pip 19: معالجة build-system.requires مرتبط الآن بمعالجة build-system.build-backend ، لذا فإن --no-use-pep517 يعطل PEP 518 أيضًا (مما يتسبب في فشل مجموعة الاختبار ، وقد يتسبب أيضًا في فشل تثبيت العالم الحقيقي إذا كان الإصدار التبعيات غير مثبتة مسبقًا).

في # 6210 ، أقوم بدلاً من ذلك بإصلاح pep517 محليًا لدعم حقن sys.path[0] في العملية الفرعية ، وفعل الشيء نفسه الذي من المتوقع أن يفعله setuptools.build_meta_legacy في المستقبل setutpools الافراج عن build-system.requires ، ودليل المصدر هو sys.path[0] عند تنفيذ setup.py . إنه أيضًا مشابه جدًا لما اقترحته في https://discuss.python.org/t/pep-517-backend-bootstrapping/789/29؟u=ncoghlan و takluyver قد صاغته في https://github.com/ pypa / pep517 / pull / 42 / للتعامل مع الخلفيات الخلفية --no-binary :all:

آسف لكوني AWOL RM. حدثت أشياء لم أتوقعها.

من الواضح أنني أفضل إصلاح جانب setuptools لهذا ولكن # 6210 رائع معي أيضًا - كإصلاح قصير المدى.

أتفق مع techalchemy و pradyunsg - أعتقد أن إصلاح جانب setuptools هو النهج الصحيح هنا. بينما أنا أقدر العمل على محاولة إيجاد حل سريع داخل النقطة ، ألن يتم قضاء هذا الوقت بشكل أفضل في تسريع إصدار جديد من أدوات الإعداد _build_meta_legacy ؟ أنا لم أشاهد ما يحدث في setuptools، لذلك أنا لست واضحا على الإطلاق لماذا هناك مشكلة مع الافراج عن حل سريع في setuptools (وsetuptools تطلق دورات هي وسيلة أسرع من نقطة ل).

أنا موافق على إصلاح جانب النقطة على المدى القصير ، لكن أود توضيح متى يمكننا توقع إصلاح setuptools.

تحية للجميع!

لدي نفس المشكلة:

**Collecting pyinstaller==3.4
  Using cached https://files.pythonhosted.org/packages/
a0cc/PyInstaller-3.4.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  Complete output from command "c:\program files (x86)\
gram files (x86)\microsoft visual studio\shared\python3
requires_for_build_wheel C:\Users\ASUS\AppData\Local\Te
  Traceback (most recent call last):
    File "c:\program files (x86)\microsoft visual studi
process.py", line 207, in <module>
      main()
    File "c:\program files (x86)\microsoft visual studi
process.py", line 197, in main
      json_out['return_val'] = hook(**hook_input['kwarg
    File "c:\program files (x86)\microsoft visual studi
process.py", line 54, in get_requires_for_build_wheel
      return hook(config_settings)
    File "C:\Users\ASUS\AppData\Local\Temp\pip-build-en
, line 115, in get_requires_for_build_wheel
      return _get_build_requires(config_settings, requi
    File "C:\Users\ASUS\AppData\Local\Temp\pip-build-en
, line 101, in _get_build_requires
      _run_setup()
    File "C:\Users\ASUS\AppData\Local\Temp\pip-build-en
, line 85, in _run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 20, in <module>
      from PyInstaller import __version__ as version, H
  ModuleNotFoundError: No module named 'PyInstaller'**

هل يعرف أحد ما إذا تم حل المشكلة؟ او كيف تحلها مؤقتا؟

شكرا لكم جميعا!

@ jce94 ، استخدم النقطة <19 في الوقت الحالي.

altendky شكرا´s للمعلومات!

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

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

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

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

الإصدار الجديد من setuptools ، الإصدار 40.8.0 متاح الآن مع الواجهة الخلفية build_meta:__legacy__ .

شكر! وهل هذا شيء يجب أن نشير إلى استخدام PyInstaller؟ قد كانوا
غير راضٍ تمامًا عن التغييرات ... أي وثائق أو PEP يمكنني تقديمها
معهم لدعم التغييرات؟

في الثلاثاء ، 5 شباط (فبراير) 2019 ، 10:24 كتب بول غانسلي < [email protected] :

الإصدار الجديد من setuptools ، الإصدار 40.8.0 متاح الآن مع
build_meta: __ legacy__ الخلفية.

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

AlmogCohen لا ، هذا ليس شيئًا يجب عليك استخدامه مباشرة ، إنه فقط للاستخدام من قبل الواجهات الأمامية PEP 517. الخطوة التالية هي أن يبدأ pip في استخدام build_meta:__legacy__ كخلفية افتراضية له. هذا ليس قابلاً للتنفيذ من منظور المستخدم النهائي.

أي ETA في الإصدار الجديد من شأنه أن يدمج الإصلاح؟

في غضون ساعات قليلة. :)

راجع المشكلة المثبتة.

تم إصدار النقطة 19.0.2 مع إصلاح لذلك.

أنا غير قادر على تثبيت pyinstaller بأحدث إصدار من النقطة ، حتى عند استخدام --no-use-pep517

pip install pyinstaller --no-cache-dir --no-use-pep517
Collecting pyinstaller
  Downloading https://files.pythonhosted.org/packages/03/32/0e0de593f129bf1d1e77eed562496d154ef4460fd5cecfd78612ef39a0cc/PyInstaller-3.4.tar.gz (3.5MB)
     |████████████████████████████████| 3.5MB 273kB/s
  Installing build dependencies ... done
    ERROR: Complete output from command python setup.py egg_info:
    ERROR: Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\Raffaele\AppData\Local\Temp\pip-install-5e9w2p2c\pyinstaller\setup.py", line 20, in <module>
        from PyInstaller import __version__ as version, HOMEPATH, PLATFORM
    ModuleNotFoundError: No module named 'PyInstaller'
    ----------------------------------------
ERROR: Command "python setup.py egg_info" failed with error code 1 in C:\Users\Raffaele\AppData\Local\Temp\pip-install-5e9w2p2c\pyinstaller\

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