<p>पाइप 19.0 उन पैकेजों को स्थापित करने में विफल रहता है जो CWD से पैकेज के लिए आयात किए जाते हैं</p>

यह या तो कैसे स्थापना के लिए खुद को आयात कर रहा है के साथ एक मुद्दा हो रहा है।

PyInstaller के लोगों पर एक समस्या दर्ज करना एक अच्छा विचार हो सकता है।

वर्तमान में हम 18.1 का उपयोग करते हैं, और 19.0 में अपग्रेड करने से हमारे लिए यह समस्या होती है। PyInstaller repo पर एक संबंधित मुद्दा है, जहां ऐसा इसलिए है क्योंकि pip '' 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"]

उपरोक्त पाइप बताता है कि PyInstaller के निर्माण के लिए इसे setuptools और wheel आवश्यकता है। लेकिन 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 उनके लिए यह तय करता है?

मुझे संदेह है कि इस मुद्दे का कारण अलगाव है या पीईपी 517 कोड यह सुनिश्चित नहीं कर रहा है कि पैकेज निर्देशिका की जड़ sys.path पर है, क्योंकि पांडा के पास सेटअप वर्चस्व के बगल में एक वर्जन-थ्रीडी है। मुझे कुछ बिंदु पर यह याद आ रहा है, लेकिन मुझे अपने सिर के ऊपर से याद नहीं है कि यह चर्चा क्या थी। इसे सेटपूल के साथ पाइप के बजाय बैकएंड के निर्माण के साथ एक समस्या माना जा सकता है, या यह पाइप के अलगाव तंत्र की गलती हो सकती है।

[...] क्या कोई जाँच कर सकता है कि क्या - उपयोग- 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'

इसके अलावा निम्नलिखित की स्थापना भी पाइप वी 19.0 के साथ काम नहीं करती है, लेकिन अगर -no-use-pep5517 का उपयोग कर रही है:
पेंडुलम == 1.5.0 (गुणसमूह: मॉड्यूल 'एनम' में कोई विशेषता नहीं है 'IntFlag')
पेंडुलम == 1.5.1 (गुणसमूह: मॉड्यूल 'एनम' में कोई विशेषता नहीं है 'IntFlag')
पेंडुलम == 2.0.0 (गुणसमूह: मॉड्यूल 'एनम' में कोई विशेषता नहीं है 'IntFlag')
पेंडुलम == 2.0.1 (गुणसमूह: मॉड्यूल 'एनम' में कोई विशेषता नहीं है 'IntFlag')
पेंडुलम == 2.0.2 (गुणसमूह: मॉड्यूल 'एनम' में कोई विशेषता नहीं है 'IntFlag')

जबकि 2.0.3 और 2.0.4 ठीक है।

कार्टोपी (कम से कम उनकी नवीनतम रिलीज) भी 19.0 के बाद से स्थापित करने में विफल रहती है, इसके संस्करण के लिए आयात करने में विफल रहा है कि सेटअप के बगल में है

यह कुछ परियोजनाओं के साथ भी एक मुद्दा है, जिनसे मैं निपटता हूं। हम अपने python काले मापदंडों को परिभाषित करने के लिए एक pyproject.toml का उपयोग करते हैं, और हमारे setup.py में समान from project.version import __version__ करते हैं।

बहुत कम से कम मुझे लगता है कि pyproject.toml में कोई परियोजना अलगाव को परिभाषित करने में सक्षम होने के लिए पर्याप्त होगा। मेरे लिए --no-buid-isolation या --no-use-pep517 का उपयोग करने के लिए प्रोजेक्ट स्थापित करने के इच्छुक किसी भी व्यक्ति को यह अनुचित लगता है

असफलता get_requires_for_build_wheel में प्रतीत होती है, और सेट-अप बैकेंड्स का निर्माण आवश्यकताओं को निर्धारित करने के लिए कुछ प्रकार के आत्मनिरीक्षण करने के लिए setup.py चलता है (विशिष्ट कोड यहाँ है )। यह कोड मुझे अजीब लगता है, और मुझे समझ नहीं आता कि इसकी आवश्यकता क्यों है। मेरी प्रारंभिक वृत्ति यह है कि यह सेटटॉप्स बैकेंड में एक बग है जिसे उनके द्वारा संबोधित किया जाना चाहिए।

PEP 517 में यह नहीं बताया गया है कि फ्रंट को एक ऐसे वातावरण में हुक चलाना चाहिए जो बिल्ड डायरेक्टरी को sys.path जोड़ता है, और एक संभावित चिंता यह है कि अगर हमने ऐसा किया, तो यह अलगाव को तोड़ सकता है (यदि बिल्ड निर्देशिका में 19 की प्रतिलिपि शामिल है कुछ आवश्यक लेकिन निर्दिष्ट पैकेज नहीं, उदाहरण के लिए)। इसलिए मेरी प्राथमिकता बिल्ड डायरेक्टरी को sys.path जोड़ना नहीं होगा। लेकिन ऐसा करना समीचीन हो सकता है यदि यह इस प्रतिगमन के लिए एक त्वरित समाधान प्रदान करता है। मुझे नहीं लगता कि परियोजनाओं को इस पर भरोसा करना चाहिए, हालांकि।

सारांश:

1. यह एक बैकएंड मुद्दे के रूप में समीक्षा के लिए सेटप्टूल को सूचित किया जाना चाहिए। मैं इसे सेटटॉपूल बैकेंड में तय करने पर विचार करूंगा (संभवत: उनके द्वारा बिल्ट डायरेक्टरी को sys.path जोड़कर) आदर्श संकल्प के रूप में।
2. अगर सेटटॉप्स ऐसा नहीं करते हैं, तो पाइप बिल्ड डायरेक्टरी को sys.path डायरेक्ट डायरेक्टरी में जोड़ सकता है, लेकिन मुझे नहीं लगता कि PEP 517 को लगता है कि फ्रंटेंड की जिम्मेदारी है।
3. निर्माण निर्देशिका की आवश्यकता होती है पर हुक करने के लिए दिखाई दे सकता है sys.path कम से कम एक पीईपी स्पष्टीकरण की आवश्यकता होगी।

मुझे नहीं लगता कि पीईपी 517 के विकसित होने पर इस परिदृश्य पर विचार किया गया था। हो सकता है क्योंकि यह सेट-विशिष्ट-(या बल्कि, बैकेंड के लिए विशिष्ट है जो निर्माण के भाग के रूप में मनमाने ढंग से पायथन कोड चलाते हैं)।

मुझे लगता है कि लोगों के लिए वर्तमान निर्देशिका से setup.py में कुछ आयात करना आम बात है, और आम तौर पर चीजों का व्यवहार करते हैं जैसे कि setup.py $PWD ।

मुझे लगता है कि इस जिम्मेदारी को setuptools पर धकेलना उचित है, क्योंकि यह शायद एकमात्र परियोजना है जिसे वास्तव में इसकी आवश्यकता है।

हां, इस बारे में कुछ और सोचना, मुझे यकीन है कि यह एक असफलता की जिम्मेदारी है। प्री-पीईपी 517, पाइप स्क्रिप्ट के रूप में setup.py भागा, इसलिए मानक पायथन नियमों ने स्क्रिप्ट निर्देशिका को sys.path । PEP 517 के तहत, setup.py के आह्वान को बैकएंड हुक के लिए कॉल के साथ बदल दिया जाता है, इसलिए उन हुक को शब्दार्थ को संरक्षित करने की आवश्यकता होती है। क्योंकि सेप्टुपूल हुक से setup.py -इन-प्रोसेस चलाता है, इसे sys.path स्वयं प्रबंधित करने की आवश्यकता होती है। उम्मीद है, यह उनके लिए कोई बड़ी बात नहीं है। @jeanlaroche (या कोई अन्य व्यक्ति इस मुद्दे को मार रहा है) क्या आप इस थ्रेड पर वापस लौटने का जिक्र करते हुए, सेटपूलर ट्रैकर पर एक मुद्दा उठा सकते हैं?

[...] क्या कोई जाँच कर सकता है कि क्या - उपयोग- 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

मुझे नहीं लगता कि यह पीईपी 517 के बिल्ड एनवायरनमेंट सेक्शन के पिप / सेटप्टॉल्स में एक बग है, ऐसा लगता है कि पर्यावरण के बारे में कुछ भी ऐसा नहीं माना जाना चाहिए सिवाय इसके कि pyproject.toml में घोषित निर्भरताएं उपलब्ध हों।

यह भी setup.py से स्थापित किए जा रहे पैकेज का आयात नहीं कर रहा है एक बुरा अभ्यास है? एक स्थान पर पैकेज संस्करण को बनाए रखने के बहुत बेहतर तरीके हैं, जैसे कि PyPA के इस पैकेजिंग गाइड में वर्णित है।

Pypa / setuptools # 1642 में चर्चा में, @ururusjr और मैं दोनों यह उम्मीद कर रहे थे कि लोगों को इस तथ्य पर भरोसा करने से रोकने का अवसर मिल सकता है कि . sys.path जब आप एक पर अमल करते हैं पाइथन लिपि, और लोगों को अधिक स्पष्ट शब्दार्थ में स्थानांतरित करना शुरू करें।

यहाँ मुख्य समस्या यह है कि pyproject.toml की उपस्थिति लोगों को PEP 518 और PEP 517 दोनों में पसंद कर रही है, इसलिए भले ही आपने बिल्ड बैकेंड निर्दिष्ट नहीं किया हो, आप अचानक नए शब्दार्थ प्राप्त कर रहे हैं।

क्या इस बिंदु पर pip का हिस्सा अपरिवर्तनीय है? हो सकता है कि आपके पास PE pyproject.toml 518 में

ईमानदारी से, यह चारों ओर एक कठिन स्थिति है, लेकिन मुझे लगता है pip लिए इस बारे में चेतावनी देना आसान है, क्योंकि यह setuptools । यदि हम अभी के लिए PEP 517 ऑप्ट-इन बनाते हैं और कहते हैं कि pyproject.toml का अस्तित्व 20.0 या 21.0 के बाद PEP 517 को ट्रिगर करना शुरू कर देगा, तो हम एक माइग्रेशन गाइड बना सकते हैं और pip में चेतावनी देना शुरू कर सकते हैं। उस प्रभाव के लिए build-backend pyproject.toml से गायब है, ध्यान रखें कि 21.0 संस्करण के बाद, अलगाव setuptools.build_meta का उपयोग करने के लिए डिफ़ॉल्ट होगा, पर माइग्रेशन गाइड देखें ..."

setup.py से स्थापित किए जा रहे पैकेज को भी आयात नहीं कर रहा है क्या यह एक बुरा अभ्यास है? एक स्थान पर पैकेज संस्करण को बनाए रखने के बहुत बेहतर तरीके हैं, जैसे कि PyPA के इस पैकेजिंग गाइड में वर्णित है।

निष्पक्ष होने के लिए, यह गाइड setup.py से स्थापित होने वाले पैकेज को आयात करने को परिभाषित करता है, इसलिए यह निश्चित रूप से कुछ सामान्य है। इस बिंदु पर, यदि हम उस तरह की रणनीति से दूर जा रहे हैं, तो उस पृष्ठ को अपडेट किया जाना चाहिए ताकि वह उसमें शामिल न हो।

pyproject.toml के अस्तित्व पर PEP 517 को ट्रिगर करने का निर्णय एक जानबूझकर विकल्प था (चर्चा संभवतः PEP 517 कार्यान्वयन मुद्दे या PR पर थी, लेकिन मेरे पास इसे खोजने के लिए अभी समय नहीं है)। जाहिर है कि यहां जो कुछ भी हम देखते हैं, उसके प्रकाश में इसे बदला जा सकता है, लेकिन हमने जो निर्णय किया, उसके कारणों पर विचार किए बिना हमें ऐसा नहीं करना चाहिए।

पिप खुद ( setup.py sys.path इतना हो गए हैं, इसलिए मैं बस पाइप बदलने के लिए कुछ हद तक अनिच्छुक हूँ क्योंकि जब बैकएंड का उपयोग किया जाता है, तो सेटप्टूल एक अलग डिफ़ॉल्ट को पुश करना चाहते हैं। जबकि मैं मानता हूं कि setup.py में बनाई जा रही परियोजना में कई प्रकार की कठिनाइयाँ हैं, यह ऐसा नहीं है कि यह कुछ ऐसा है जिसने अब तक चेतावनी दी है, इसलिए मैंने माना कि बैकेंड को उस शब्दार्थ को बनाए रखना चाहिए। इसे दूसरे तरीके से रखने के लिए, भले ही पाइप आपको चेतावनी देता हो, भले ही उपयोगकर्ता "बिल्ड आइसोलेशन" setuptools.build_meta "का उपयोग करने के लिए डिफ़ॉल्ट रूप से पढ़ेंगे" का अर्थ है कि आप अपने प्रोजेक्ट को setup.py से आयात नहीं कर पाएंगे।

व्यक्तिगत रूप से, मैं pyproject.toml फ़ाइल के अस्तित्व पर भरोसा करने के वर्तमान दृष्टिकोण से सहमत हूं। IMO पैकेजिंग के अलावा अन्य चीजों के लिए pyproject.toml का उपयोग करने वाले लोगों से उपजा है। इसलिए सही तरीका यह है कि कॉन्फ़िगरेशन के लिए दूसरा तरीका पेश करने के लिए गैर-पैकेजिंग टूल को धकेल दिया जाए, इसलिए लोग यह चुन सकते हैं कि pyproject.toml का उपयोग करना है या नहीं।

पिप स्वयं (नहीं, IMO) इस बारे में कोई विचार करता है कि क्या सेटअप थिंकहोम यह मानने के लिए सही है कि प्रोजेक्ट डायरेक्टरी sys.path पर है, इसलिए मैं पाइप बदलने के लिए कुछ हद तक अनिच्छुक हूं क्योंकि सेटपूल एक धक्का देना चाहते हैं बैकएंड का उपयोग करने पर अलग डिफ़ॉल्ट।

सच है, यह सिर्फ pip धारणा है कि setuptools.build_meta हुक का आह्वान कर रहा है और setup.py को कॉल करने के लिए पूरी तरह से बराबर होना चाहिए। हमने पहले से ही ऐसे मामलों को देखा है जहां यह नहीं है, और मुझे लगता है कि यह अभी भी स्थापित होना है कि क्या हम ( setuptools ) setuptools.build_meta का अनुबंध चाहते हैं "यह python setup.py को कॉल करने के बराबर है setup.py सीधे

बेशक setuptools "यह कह सकते हैं कि यह फ़ंक्शन का अनुबंध नहीं है इसलिए हम इसे ठीक करने नहीं जा रहे हैं" और pip यह कह सकते हैं, "हमारा निर्णय यह था कि यह PEP 517 के लिए चूक गया" और हम दोनों कह सकते हैं कि बग दूसरी परियोजना में है, लेकिन शायद समन्वय करना एक अच्छा विचार है।

यदि आप सुझाव देते हैं कि पाइप ने चेतावनी दी है, तो भी इसे दूसरे तरीके से रखने के लिए, उपयोगकर्ता "सेट आइसोलेशन का उपयोग करने के लिए डिफ़ॉल्ट रूप से सेटअपूलोसिवबिल्टी_मेटा" का उपयोग करने के लिए डिफ़ॉल्ट रूप से क्यों पढ़ेंगे "यह मानकर कि आप सेटअप प्रोजेक्ट से अपना प्रोजेक्ट आयात नहीं कर पाएंगे"? दो तथ्य मुझे असंबंधित लगते हैं ...

वे संबंधित हो सकते हैं या नहीं भी हो सकते हैं, लेकिन शब्दार्थों में अन्य परिवर्तन भी हो सकते हैं। इस तरह की चेतावनी का कहना है, "कृपया इस बारे में स्पष्ट रहें कि आप इस निर्माण को कैसे करना चाहते हैं, क्योंकि जल्द ही हम आपको एक ऐसी चीज़ चुनने जा रहे हैं जो आपके निर्माण को तोड़ सकती है।" प्रोजेक्ट बिल्ड बैकेंड को अपने pyproject.toml समय से आगे जोड़ सकते हैं और जो भी हो सकता है किसी भी प्रकार के टूटने को ठीक कर सकते हैं।

हम संभवतः setuptools जैसे setuptools.build_meta_legacy एक "डमी" PEP बैकएंड भी बना सकते हैं जो रूट डायरेक्टरी में chdir s है और setuptools.build_meta , उस तरह से लोग पुराने व्यवहार का चयन तभी कर सकते हैं, जब उन्हें इससे पहले कि वह टूटना शुरू हो जाए।

व्यक्तिगत रूप से, मैं pyproject.toml फ़ाइल के अस्तित्व पर भरोसा करने के वर्तमान दृष्टिकोण से सहमत हूं। IMO पैकेजिंग के अलावा अन्य चीजों के लिए pyproject.toml का उपयोग करने वाले लोगों से उपजा है।

मुझे लगता है कि हमें PEP 517 और PEP 518 को अलग करने की आवश्यकता है। PEP के लिए "डिफ़ॉल्ट मान" क्या है, जबकि PEP 517 डिफ़ॉल्ट बैकएंड के बारे में कुछ भी निर्दिष्ट नहीं करता है।

मुझे याद है कि पूरे " pyproject.toml के अस्तित्व में आप अलगाव पैदा करने के लिए" का विरोध नहीं कर रहे हैं, लेकिन व्यवहार में इसे देखकर, मुझे यह विचार भी पसंद नहीं है कि मेरे अलग-अलग बिल्ड की निर्भरता को निर्दिष्ट करना भी पसंद करेगा। मुझे setuptools.build_meta ।

शायद समाधान अंतर को विभाजित करने के लिए है और बैकएंड को एक अनिर्दिष्ट setuptools.build_meta_legacy (जो setup.py के शब्दार्थ को बनाए रखने का प्रयास करता है) के लिए है। इस तरह से हमें कम से कम यह बताने का एक तरीका होगा कि क्या उपयोगकर्ता ने नए शब्दार्थ का उपयोग करने के लिए एक सकारात्मक विकल्प बनाया है या यदि वे इसके बारे में नहीं सोचते हैं।

एक चेतावनी संदेश के साथ एक build_meta_legacy मेरे लिए एक उचित समाधान की तरह लगता है। चेतावनी को बहुत महत्वपूर्ण बनाने के लिए बेहतर है (उदाहरण के लिए स्थापना के दौरान और उपयोगकर्ताओं को इसे बनाए रखने के लिए बग के रूप में दर्ज करने के लिए प्रोत्साहित करें), स्पष्ट निर्देशों के साथ कि माइग्रेशन कैसे किया जाना चाहिए।

मुझे यह भी ध्यान देना चाहिए कि पाइप का इरादा (यह "कॉर्पोरेट" पाइप है ;-) - मेरा क्या मतलब है कि पाइप देवों ने इस पर थोड़ी चर्चा की और एक आम सहमति पर पहुंच गए कि यह एक उचित विचार की तरह लग रहा था, लेकिन यह अभी तक एक ठोस योजना नहीं है। और यह वास्तव में इसके लिए कोड लिखने वाले किसी व्यक्ति पर निर्भर करता है) यह है कि हम पीईपी 517 के माध्यम से सभी परियोजनाओं को पारित करने के लिए जल्दी से स्विच करते हैं, और setup.py माध्यम से अपने विरासत कोड पथ को छोड़ते हैं। सेटपूल को बैकप में केवल 21.0 (ऊपर से सुझाई गई रिलीज का उपयोग करने के लिए) बनाने से कम से कम 2 साल का अतिरिक्त धक्का लगता है।

जबकि PEP 517 डिफ़ॉल्ट बैकएंड के बारे में कुछ भी निर्दिष्ट नहीं करता है

सच। लेकिन कुछ बिंदु पर, पिप setuptools के विशेष मामले समर्थन छोड़ देंगे। आखिरकार, पीईपी 517 के पूरे बिंदु (हमारे लिए, कम से कम), बैकएंड से फ्रंटेंड को कम करने और सभी बैकेंड को एक समान पायदान पर रखने के लिए है। इसलिए जब भी हम ऐसा करते हैं, तो हमें या तो त्रुटि होती है अगर कोई बैकएंड नहीं है, या एक डिफ़ॉल्ट चुनें (और हम सेटिंग कारणों से डिफ़ॉल्ट के लिए जाएंगे, विरासत के कारणों के लिए)। यहां बहस तब होती है जब हम ऐसा करते हैं, यदि नहीं।

इंस्टॉल के लिए पिप में वर्तमान में 2 कोड पथ हैं - PEP 517 पथ, और विरासत setup.py पथ। यह रखरखाव के मुद्दों और संभावित बगों का एक स्रोत है। हमने PEP 517 को डिफ़ॉल्ट बनाने का विकल्प चुना, अगर pyproject.toml PEP 517 पथ का उपयोग सुनिश्चित करने के लिए मौजूद था (यह संभावना नहीं है कि परियोजनाएं build-backend = setuptools.buid_meta जोड़ने के लिए जल्दबाजी करेंगी, इसलिए वर्तमान व्यवहार के बिना, ऑड्स यह है कि) पाइप के पीईपी 517 कोड, और सेटप्टूल के बैकेंड दोनों का परीक्षण, विस्तारित अवधि के लिए शून्य के पास रहेगा)। वहाँ --no-use-pep517 के रूप में एक ऑप्ट-आउट होता है, (दुर्लभ माना जाता है) मामलों को पूरा करने के लिए, जहां सेटपुल्स बैकेंड अनुपयुक्त था।

मुझे नहीं लगता है कि किसी को भी अनुमान है कि सेप्टोलूल setup.py और बैकएंड के बीच सिमेंटिक अंतर रखना चाहते हैं, इसलिए संभावना है कि सिमेंटिक अंतर के चारों ओर काम करने के लिए --no-use-pep517 आवश्यकता होगी ताकि यह अक्सर होना चाहिए डिफ़ॉल्ट पर भी कभी विचार नहीं किया गया था।

हम संभवतः "गुप्त" पीईपी 517 बैकेंड में सेटपूलसूलसबिल्ट_इंटा_मेटा जैसे सेटपूल में भी बना सकते हैं, जो रूट डायरेक्टरी में सिर्फ चिर्रिर करते हैं और सेटपूलुलेसिबिल्ट_मेटा को आमंत्रित करते हैं, इस तरह लोग पुराने व्यवहार का चयन तभी कर सकते हैं जब उन्हें इससे पहले कि वे इसे तोड़ना शुरू करें। ।

यह एक उचित समाधान हो सकता है। लेकिन यह कम से कम आंशिक रूप से प्रलेखित होना होगा - कम से कम, पाइप दस्तावेज होगा कि यह डिफ़ॉल्ट मान था जिसे हम मान लेंगे। क्या सेटपॉइंट्स ने बैकेंड को अनिर्धारित छोड़ने के लिए चुना, क्या उनकी पसंद मुझे लगता है।

मुझे यकीन नहीं है कि कोई और सैद्धांतिक चर्चा कितनी उपयोगी है। मुझे नहीं लगता कि मेरे पास जोड़ने के लिए कुछ और है, निश्चित रूप से। मेरा सुझाव है कि यदि कोई इसे आगे ले जाना चाहता है, तो सबसे अच्छा तरीका यह होगा कि आप एक पीआर को डिफ़ॉल्ट रूप से बदल दें, और चर्चा करें कि क्या हम इसे स्वीकार करना चाहते हैं।

अपने उपयोगकर्ताओं के लिए इस समस्या को हल करने के लिए देख रहे पैकेज अनुचर के लिए: मैंने एक शिम प्रकाशित किया है जो sys.path फिक्स लागू करता है।

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

उम्मीद है कि यह एक स्टॉपगैप के रूप में काम कर सकता है, इसलिए हम विचार कर सकते हैं कि इसे कैसे हल किया जाए, या अनावश्यक रूप से पाइप 19.0 को अपनाना धीमा कर दिया जाए (जिसमें पीईपी 517 की तुलना में बहुत अधिक अच्छाई हो)।

मैंने एक शिम प्रकाशित किया है जो sys.path को ठीक करता है।

वह तो कमाल है! अंतिम फिक्स के बावजूद, यह PEP 517 हुक सिस्टम के लचीलेपन का एक बहुत अच्छा उदाहरण है :-)

मैंने इसे 19.x के तहत अपने पाइप संस्करण को डाउनग्रेड करके ठीक किया, फिर मैंने स्थापित करने का प्रयास किया और सफलतापूर्वक चला गया

तीसरा उपयोग मामला है: उन पैकेजों के बारे में जो अपने स्वयं के बिल्ड बैकेंड प्रदान कर रहे हैं? उदाहरण के लिए: setuptools केवल एक आवश्यकता के रूप में wheel सूची देते हैं:

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

यदि पीईपी 517 को संभालने के लिए पाइप का कोड sys.path के स्रोत निर्देशिका को नहीं जोड़ता है, तो यह निश्चित रूप से विफल हो जाएगा।

PEP 517 से:

मॉड्यूल पथ को आयात करते समय, हम स्रोत ट्री से युक्त निर्देशिका में नहीं देखते हैं, जब तक कि वैसे भी sys.path पर नहीं होगा (उदाहरण के लिए यह PYTHONPATH में निर्दिष्ट है)। हालाँकि कुछ स्थितियों में पायथन स्वचालित रूप से कार्यशील निर्देशिका को sys.path में जोड़ता है, बैकएंड को हल करने का कोड इससे प्रभावित नहीं होना चाहिए।

यह बहुत स्पष्ट रूप से (मेरे लिए) कहता है कि परियोजनाओं को build-backend हल करते समय अपनी स्वयं की प्रोजेक्ट निर्देशिका को देखने में सक्षम होने की उम्मीद नहीं करनी चाहिए - इसलिए setuptools को खुद को requires IMO में जोड़ने की आवश्यकता है। और हां, मैं समझता हूं कि ऐसा करना परिपत्र है। लेकिन बैकएंड का निर्माण करें जो स्वयं का निर्माण करते हैं वैसे भी उनके स्वभाव से काफी परिपत्र हैं - वे निश्चित रूप से सामान्य मामला नहीं हैं।

यही खंड मुझे इस बात की पुष्टि करने के लिए भी प्रतीत होता है कि बिल्ड टूल्स को प्रोजेक्ट डायरेक्टरी को बिल्ड एनवायरनमेंट के sys.path में होने की उम्मीद नहीं करनी चाहिए।

वह --no-binary :all: साथ कैसे काम करेगा?

@pfmoore स्थिति का एक प्रकार यह है कि एक पैकेज एक कस्टम बिल्ड सिस्टम की आपूर्ति करता है। बिल्ड सिस्टम स्थापित नहीं है (और bdist का हिस्सा नहीं है), लेकिन sdist के साथ आपूर्ति की, शायद कुछ बिल्ड प्रक्रिया को cusomise करने के लिए। क्या यह एक वैध उपयोग मामला है, या अनुरक्षक को कस्टम निर्माण प्रणाली को एक अलग पैकेज के रूप में प्रकाशित करना चाहिए?

संपादित करें: कुछ इस तरह

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 517 स्पष्ट रूप से कहता है ( build-backend पर अनुभाग में) "जब मॉड्यूल पथ का आयात करते हैं, तो हम स्रोत ट्री से युक्त निर्देशिका में नहीं देखते हैं, जब तक कि यह sys.path पर नहीं होगा। "जो मेरा मतलब है कि यह स्पष्ट रूप से इन-ट्री बैकेंड के लिए हतोत्साहित है। क्या कोई पर्याप्त रूप से कुटिल कोड के साथ इसके आसपास काम कर सकता है, मुझे यकीन नहीं है (लेकिन मुझे संदेह नहीं है)।

जब हम PEP 517 विकसित करते हैं तो अपेक्षित उपयोग का मामला यह था कि बैकएंड्स को PyPI (या एक कस्टम इंडेक्स) पर पहियों के रूप में भेज दिया जाएगा, जिसे बिल्ड वातावरण में डाउनलोड और इंस्टॉल किया जाएगा। कैसे बैकेंड का निर्माण किया गया क्षेत्र से बाहर स्पष्ट था - मेरी व्यक्तिगत धारणा थी कि वे पीईपी 517 तंत्र का उपयोग नहीं होगा, बल्कि एक निचले स्तर कमांड (प्रयोग करेंगे setup.py bdist_wheel या flit build , उदाहरण के लिए ) का है। एक पीईपी 517 बैकएंड का उपयोग करके अपने आप को बनाने के लिए जटिल रूप से बहुत दूर एक कदम की तरह लग रहा था। इसे पाइप में PEP 518 के कार्यान्वयन के हिस्से के रूप में माना जाता था (यदि एक बैकड को एक sdist के रूप में भेज दिया जाता है, और खुद को बनाने के लिए खुद का उपयोग करने के लिए एक संभावित कांटा बम का उपयोग होता है, तो इससे पहले कि हम भी समर्थन का समर्थन कर सकते हैं ताकि हम बैकेंड को पहियों पर वितरित नहीं कर सकें ) लेकिन केवल PyPI से बैकएंड डाउनलोड करने के संदर्भ में।

tl; डॉ; उस समय की चर्चाओं को याद करते हुए मैं यह पेशकश कर सकता हूं - आप वास्तविक पृष्ठभूमि के लिए अभिलेखागार की बेहतर खोज कर सकते हैं।

मुझे नहीं पता कि पीईपी के लेखकों ने इस पर विचार किया - मुझे इस बात की कोई चर्चा याद नहीं है कि पीईपी को कब विकसित किया गया था।

मैंने अभी-अभी अभिलेखागार को देखना शुरू किया है, और ऐसा प्रतीत होता है कि यह प्रश्न वास्तव में प्रक्रिया के अंत (या कम से कम इसमें अच्छी तरह से) की ओर विस्तार से चर्चा की गई थी। मैं अभिलेखों को देखने के लिए कौन सी वेबसाइट सर्वश्रेष्ठ नहीं हूं, लेकिन यहां एक बिंदु पर चर्चा फिर से इस सवाल पर शुरू होती है (28 जुलाई, 2017):
https://mail.python.org/pipermail/distutils-sig/2017-July/031109.html
https://www.mail-archive.com/[email protected]/msg26624.html

उदाहरण के लिए, यह विशेष ईमेल-- के साथ समाप्त होता है

यह देखते हुए कि PEP 517 के साथ हम पहले से ही कितना परेशान हैं, यह PEP 517 के लिए अधिक अर्थपूर्ण हो सकता है बस यह आज्ञा देना चाहिए कि निर्देशिका sys.path पर नहीं है, और केवल पायथन-पथ के लिए थोड़ा अनुवर्ती PEP करें।

अगर मैं अंतिम फैसला सुनाता हूं तो मैं आपको बता दूंगा, लेकिन मैं दूसरों को खुद के लिए पढ़ने के लिए प्रोत्साहित करता हूं।

अच्छा लगा! कि खोजने के लिए धन्यवाद :-)

इसलिए मैंने ईमेल का एक गुच्छा स्किम किया, और मुझे लगता है कि आप कम से कम 29 अगस्त को आगे छोड़ सकते हैं, जहां निक ने सुझाव दिया है कि सोर्स डायरेक्टरी _out_ of sys.path छोड़ने पर आम सहमति है:
https://mail.python.org/pipermail/distutils-sig/2017-August/031413.html
(एक-एक करके, लोग नथानिएल के तर्कों के कायल हो रहे थे।)

हालाँकि, ऊपर दिए गए इसी ईमेल में, निक निम्नलिखित कहता है :)

1. यदि इसे छोड़ना वास्तव में एक समस्या है, तो हम सेटअप सेटअप बैकएंड को लागू करने के हिस्से के रूप में जल्द ही पता लगा लेंगे

यहाँ ईमेल से एक पूर्ण पैराग्राफ है:

इसलिए मुझे लगता है कि हम इसे "डेमोंड्स को यह सुनिश्चित करना चाहिए कि वर्तमान निर्देशिका को सुनिश्चित करना चाहिए कि निर्दिष्ट निर्देशिका sys.path पर निर्दिष्ट बैकएंड को आयात करने से पहले नहीं है ", जैसा कि वहाँ शुरू होगा, इसका मतलब है कि हम प्रारंभिक के भाग के रूप में कुछ नया सीखने की अपनी संभावनाओं को अधिकतम करेंगे। अनंतिम रूप से स्वीकृत एपीआई का रोलआउट।

मुझे अभी तक नहीं पता है कि बाद में ऐसे ईमेल हैं जो इस सारांश को बदलते हैं, लेकिन इस विषय पर बहुत सारे ईमेल नहीं हैं।

हमारे लिए अभिलेखागार को फँसाने के लिए धन्यवाद @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 अभी भी आवश्यक है, क्योंकि इसमें सेटप्टूल का एक न्यूनतम संस्करण निर्दिष्ट करना है जो "नहीं build-system अनुभाग" मामले को सही ढंग से संभालता है।

अंत में उपयोगकर्ताओं के लिए काम करने के लिए जितनी जल्दी हो सके, किसी भी दुर्भाग्यपूर्ण डिजाइन के कोनों में खुद को चित्रित किए बिना, मैं वास्तव में एक 3 कदम प्रस्ताव का प्रस्ताव करूंगा:

1. एक नया pip रिलीज़ (19.0.1?) करें जो अब " build-system प्रविष्टि" के मामले में अतिरिक्त sys.path प्रविष्टि को जोड़ता है। इस बिंदु पर, संगतता समस्या को मुख्य रूप से अंतिम उपयोगकर्ताओं के लिए दूर जाना चाहिए।
2. एक नया setuptools रिलीज़ करें जो sys.path को संभालता है यदि सामने वाला अंत पहले से ऐसा नहीं करता है।
3. बाद के pip रिलीज में, विशेष आवरण को छोड़ने के लिए "नो build-system एंट्री" मामले को बदलें, और इसके बजाय setuptools लिए एक सख्त न्यूनतम संस्करण सेट करें।

यह प्रस्ताव इस तथ्य पर आधारित है कि मुझे लगता है कि setuptools PEP 517 बैकएंड setup.py बैकवर्ड संगतता मुद्दों को संभालने के लिए "सही" जगह है, लेकिन मुझे यह भी लगता है कि pip ट्विटिंग करना निकट अवधि में सीधे तौर पर बहुत सरल परिवर्तन होने की संभावना है, और यह एक ऐसा परिवर्तन है जिसमें समस्या होगी जबकि अधिक वास्तुशिल्प रूप से बेहतर निर्धारण पर काम किया जाता है।

मैंने pypa / setuptools # 1652 में build_meta_legacy बैकेंड बनाया है। मैं वास्तव में इसे पसंद करूंगा अगर pip डिफ़ॉल्ट बैकएंड के रूप में setuptools.build_meta_legacy का उपयोग करने के लिए स्विच हो जाए, लेकिन मुझे लगता है कि एक अंतर्निहित "विरासत शिम" बैकएंड के बारे में है जहां तक ​​मैं आराम से जा रहा हूं। setuptools । मैं मुख्य setuptools PEP 517 बैकेंड में पूर्ण रूप से " python setup.py install इम्यूलेशन" का समर्थन नहीं करना चाहता।

मैं थोड़ा उलझन में हूं कि सेटटॉपूल स्क्रिप्ट को मूल रूप से यहां टीबीएच चलाने का अनुकरण क्यों नहीं करना चाहते हैं। ऐसा लगता है कि यह अंत उपयोगकर्ताओं को भ्रमित करने के लिए कह रहा है जब python setup.py bdist_wheel सही ढंग से काम करता है, लेकिन pip wheel (यह मानते हुए कि वे गैर विरासत के बैकएंड पर सेट नहीं हैं)।

औचित्य क्या है?

औचित्य क्या है?

मेरी लंबी अवधि की योजना पीईपी 517 फ्रंटेंड या कुछ समान (अन्य आदेशों के लिए) द्वारा अप्रत्यक्ष आह्वान के पक्ष में setup.py सभी प्रत्यक्ष आह्वान को हटाना है। यदि हम एक "सभी अलग-थलग वातावरण" की दुनिया में जा रहे हैं, तो मैं setuptools कमांड के इनोवेशंस को python setup.py के साथ संगत रखने के लिए मजबूर नहीं होना चाहता, इसी वजह से PEP 517 ने विशेष रूप से कहा है कि फ्रंटेंड्स को ऐसा नहीं करना चाहिए - इसमें बिल्ड आइसोलेशन को तोड़ने और आमतौर पर अवांछनीय स्थितियों को बनाने की क्षमता है।

मुझे लगता है कि एक विरोधी पैटर्न के हिस्से के अलावा इसकी आवश्यकता होना काफी दुर्लभ है। इसके लिए किसी की वैध आवश्यकता बहुत आसानी से अपनी सेटअप स्क्रिप्ट में sys.path का हेरफेर कर सकती है।

एक नोट के रूप में, मुझे नहीं लगता कि PEP 517 कभी भी एक डिजाइन लक्ष्य के रूप में था कि सभी बिल्ड टूल एक्सेस हुक के माध्यम से संभव होगा। उदाहरण के लिए, flit के पास flit build आदेशों का अपना सेट है, और इसका कोई इरादा नहीं है कि मैं उन लोगों को पदावनत करने के लिए जागरूक हूं। इसलिए यह संभव है कि आप किनारे के मामलों का पता लगा सकें जहां पीईपी 517 के पीछे का उद्देश्य उपकरण-विशिष्ट आदेशों का उपयोग करने की आवश्यकता थी। एक स्पष्ट उदाहरण स्वयं बैकएंड का निर्माण कर रहा है (जैसा कि मैंने ऊपर उल्लेख किया है), लेकिन अन्य मामले (वर्तमान में मानकीकृत नहीं हैं, हालांकि भविष्य के पीईपी हुक जोड़ सकते हैं) जैसे संपादन योग्य इंस्टॉल्स और इन-प्लेस बिल्ड (पिछले पुर्ज़ों से आर्टेक्टैक्ट्स का पुन: उपयोग करना) मौजूद हैं।

समझौता करना कि सभी उपकरण "बिल्ड एसडीडिस्ट" का समर्थन कर सकते हैं और "बिल्ड व्हील" काफी कठिन था कि मैं जल्द ही होने वाले मानक संचालन की सूची का विस्तार करने का अनुमान नहीं लगाता।

एक नोट के रूप में, मुझे नहीं लगता कि PEP 517 कभी भी एक डिजाइन लक्ष्य के रूप में था कि सभी बिल्ड टूल एक्सेस हुक के माध्यम से संभव होगा।

यह वह नहीं है जो मैंने सुझाया था, और यह थोड़ा विषयांतर है। मेरे मुद्दा यह है कि समस्याओं कि आवश्यक हो पीईपी 518 भी अधिक आम तौर पर सभी के लिए मौजूद था setup.py आदेश, और उन सबसे अच्छा लोगों को जागृत से दूर जाने से हल कर रहे हैं setup.py सब पर। इस तरह से ऐसा करने के लिए कोई मानक आवश्यक नहीं है flit को subcommands को जोड़ने के लिए PEP की आवश्यकता नहीं है।

आह अच्छा। गलतफहमी के लिए खेद है।

@ncoghlan का प्रस्तावित संक्रमण मुझे अच्छा लग रहा है। यदि किसी के पास कोई समस्या नहीं है, तो इसके साथ आगे बढ़ें।

अभिलेखागार @cjerdonek खोदने के लिए धन्यवाद!

यह देखते हुए कि पहले से ही एक पीआर है जो इसे सेटप्टूल (विरासत बैकेंड की शुरूआत के माध्यम से) में ठीक करता है। क्या उपरोक्त में चरण 1 को छोड़ने का कोई कारण नहीं है? हम अलग-अलग बिल्ड वातावरण में सेटटॉपूल स्थापित कर रहे हैं, इसलिए बहुत हाल के संस्करण के आधार पर एक मुद्दा नहीं होना चाहिए।

क्या उपरोक्त में चरण 1 को छोड़ने का कोई कारण नहीं है?

नहीं। हम सीधे वर्तमान न्यूनतम आवश्यक संस्करण को टक्कर दे सकते हैं।

मेरी संक्रमण योजना इस धारणा पर आधारित है कि लोगों को setuptools साइड @pganssle की समर्पित संक्रमणकालीन बैकेंड उस मोर्चे पर आशाजनक दिखती है, मैं सुनिश्चित नहीं है कि यह यथास्थिति को छोड़ने के लिए समझ में आता है, जबकि उस बदलाव की समीक्षा की जा रही है।

उस ने कहा, मैं pip कार्यों में PEP 517 के कार्यान्वयन के विवरण से परिचित नहीं हूं, इसलिए मेरी यह धारणा कि सामने के अंत में मुद्दे के आसपास काम करना गलत होगा।

क्योंकि बैकएंड एक सबप्रोसेस में चलाए जाते हैं (और वास्तव में, प्रतिशोधित pep517 प्रोजेक्ट का उपयोग करते हुए, जो अप्रत्यक्ष रूप से एक अतिरिक्त स्तर जोड़ता है) यह मेरे लिए बिल्कुल भी स्पष्ट नहीं है कि हम sys.path कैसे सेट करेंगे एक बैकेंड हुक। कम से कम हमें PYTHONPATH शामिल करने की आवश्यकता होगी, जिसका अर्थ उन मामलों के बारे में चिंता करना है जहां उपयोगकर्ता के पास पहले से ही PYTHONPATH सेट है, और अलगाव कोड इसका उपयोग कैसे करता है।

अनिवार्य रूप से, पाइप में sys.path सेट करना, मुझे संदेह है, विशिष्ट रूप से गैर-तुच्छ। मुझे विवरणों को देखने के लिए समय की संभावना नहीं है, बहुत कम एक पैच लिखें (और यह सुनिश्चित करें कि यह ठीक से परीक्षण किया गया है!)।

मुझे लगता है कि फिक्स्ड सेटप्टूल बैकेंड प्राप्त करना सबसे तेज़ तरीका है।

मेरी दीर्घकालिक योजना PEP 517 के लिए अप्रत्यक्ष मंगलाचरण या कुछ समान (अन्य आदेशों के लिए) के द्वारा अप्रत्यक्ष आहरण के पक्ष में सभी प्रत्यक्ष आह्वान को हटाने की है।

@pgansle ouch। प्रक्रियात्मक setup.py को मरना होगा। यह किसी भी कारण से मौजूद नहीं होना चाहिए। क्योंकि यह "लचीलापन" दर्द और टूटने का एक अंतहीन स्रोत है। पाइथन पैकेजिंग के साथ setup.py और इसलिए सभी समस्याओं को स्थानांतरित करना असंभव है।

मैं setup.py package.json setup.py साथ प्रतिस्थापित करूंगा और अभी तक एक और पैकेज विवरण प्रारूप के बजाय इसके लिए Python अनुभाग जोड़ें।

कम से कम तब मैं ==1.x संस्करण विनिर्देशक का उपयोग कर सकता हूं।

@techtonik कृपया चले जाओ। आपके गैर-रचनात्मक योगदान में किसी भी परियोजना में मैं एक प्रतिभागी हूं

# 6210 पर काम करने से मुझे ऊपर से अपने खुद के सवाल का जवाब देना होगा कि pip स्तर पर इसे संबोधित करना कितना कठिन होगा: चुनौती यह है कि स्रोत निर्देशिका को sys.path[0] रूप में सम्मिलित किया जाना चाहिए या नहीं। pyproject.toml पढ़ता है, और फिर वहां से वास्तविक प्रक्रिया आवरण स्क्रिप्ट में।

वे प्रमुख वास्तु परिवर्तनों के बिना (प्रथम भाग के लिए बिल्ड बैकएंड नाम पर एक pip._implicit. उपसर्ग, और बाद के लिए PEP517_SYS_PATH_0 env var) के लिए उल्लेखनीय हैं, लेकिन इसका मतलब अस्थायी रूप से प्रतिशोधी pep517 को संशोधित करना है। setuptools में उचित फिक्स तैयार न हो जाए।

मेरी संक्रमण योजना इस धारणा पर आधारित है कि लोगों को सेटपूलों की ओर लंबे समय तक रहने वाले संक्रमण तंत्र को काम करने के लिए अधिक समय की आवश्यकता होगी- @pganssle के समर्पित संक्रमणकालीन बैकेंड उस मोर्चे पर आशाजनक दिखते हैं, मुझे यकीन नहीं है कि यह समझ में आता है यथास्थिति को छोड़ने के लिए उस परिवर्तन की समीक्षा की जा रही है।

हां, मैं इससे सहमत हूं। मैंने सिर्फ एक डिस्टुटिल पोस्ट में यह सुझाव दिया, दो चीजें हैं जो मैं कहूंगा कि वे महत्वपूर्ण हैं:

1. उपयोगकर्ताओं ASAP के लिए वहाँ एक ठीक हो रही है
2. सही संक्रमण हो रहा है।

मैं व्यक्तिगत रूप से सोचता हूं कि "pyproject.toml का अस्तित्व आपको PEP 517 में आता है" तर्क को हटाने के लिए, जब तक कि हमारे पास संक्रमण तर्क नहीं है। यह देखते हुए कि setuptools के बदलावों का सार्वजनिक रूप से सामना करने वाले API के लिए परिणाम है और pip यह केवल एक पिछड़े-असंगत परिवर्तन के रूप में जो बदल गया है, उसमें देरी होगी, यह मेरे लिए समझ में आता है। pip में त्वरित सुधार करते हुए हम setuptools लिए आगे की राह की समीक्षा कर रहे हैं।

मेरे स्थानीय मशीन पर दोनों दृष्टिकोणों के साथ, मैंने मूल समस्याग्रस्त PyInstaller==3.4 आवश्यकता के विरुद्ध # 6210 और # 6212 दोनों का परीक्षण किया।

• # 6210 वांछित के रूप में काम किया: https://github.com/pypa/pip/pull/6210#issuecomment -458144828
• # 6212 अपेक्षा के अनुरूप व्यवहार नहीं कर रहा है: https://github.com/pypa/pip/pull/6212#issuecomment -458148519

मुझे नहीं पता कि # 6212 विफलता एक परीक्षण सेटअप समस्या है, या अगर वहाँ वास्तव में एक और समस्या है पूर्व-विमोचन में, मुझे केवल इतना पता है कि इससे पहले कि हम उस समाधान में आश्वस्त हो सकते हैं आगे एकीकरण कार्य किया जाना है, जबकि मुझे अब # 6210 पर भरोसा है - केवल इसके साथ गलत बात यह है कि यह एक भयानक संगतता हैक है जिसे हम हमेशा के लिए ले जाने के लिए pip नहीं चाहते हैं।

ऐसा लगता है कि --no-cache उस assert विफल होने के लिए जिम्मेदार है। --cache-dir साथ परीक्षण करने के बजाय एक सफल स्थानीय परीक्षण दिया गया: https://github.com/pypa/pip/pull/6212#issuecomment -458166386

(मैं नींद और काम के लिए ~ 18 घंटे के लिए ऑफ़लाइन होने जा रहा हूं, इसलिए लोगों को # 6210 या # 6212 जो भी इस बीच समझ में आता है) के साथ स्वतंत्र महसूस करना चाहिए

मैंने स्थिति को बेहतर ढंग से दर्शाने के लिए शीर्षक को अपडेट किया है। PRs के लिए धन्यवाद

मॉडरेशन नोट: मैंने आगे भी गैर-उत्पादक टिप्पणियों (और उन पर प्रतिक्रियाएं) को "ऑफ टॉपिक" के रूप में छिपाया है, और भविष्य में उन लाइनों के साथ किसी भी टिप्पणी के लिए ऐसा करेगा। अगर किसी को मॉडरेशन के बारे में चर्चा करनी है, तो एक नया मुद्दा दर्ज करें या मुझे ईमेल पर पिंग करें; यह धागा आपके पास मॉडरेशन के साथ किसी भी मुद्दे को लाने के लिए सही जगह नहीं है।

मैंने भी आगे बढ़कर इसे पिन किया है, डुप्लिकेट बनाने वाले लोगों से बचने और स्पष्ट रूप से संकेत देने के लिए कि हम इस बारे में जानते हैं।

यहां तक ​​कि अगर हम pep517 ऑप्ट-इन बनाते हैं, तो यह एक व्यवहार परिवर्तन है जिसकी घोषणा नहीं की गई थी और इसलिए वे पुस्तकालयों को तोड़ देंगे _ यदि वे पहले से ही in_ ( PyInstaller , उदाहरण के लिए)। उस स्थिति में जहां कोई लाइब्रेरी pep517 को ऑप्ट-इन घोषित करती है, _and_ स्थानीय रूप से उन चीजों का आयात करती है, जो sys.path पर मिलने की उम्मीद करती हैं, पाइप द्वारा बनाई जा रही कोई धारणा नहीं है (क्योंकि लाइब्रेरी स्पष्ट है) लेकिन लाइब्रेरी है अभी भी अचानक टूट गया।

उस स्थिति में, मुझे वास्तव में सेटटॉप्स में cwd शामिल करने के अलावा कोई विकल्प नहीं दिखता है, क्योंकि यह सिर्फ टूट गया है। जब तक प्रस्ताव लोगों को वापस जाने के लिए और pep517 और पाइप 19 के बीच में कटौती की गई रिलीज़ को ठीक करने के लिए नहीं कहता है, जब तक कि किसी भी उपयोगकर्ता के उन संस्करणों को सख्ती से पिन किया जाता है, तो अचानक स्थापित होने से रोका जा सकता है, मुझे वास्तव में लगता है कि हमें प्रभाव पर विचार करना चाहिए उपयोगकर्ता के अनुभव पर इन फैसलों की। इस चर्चा और वर्तमान प्रस्तावों के आधार पर इन पुस्तकालयों में से कुछ पाइप + सेटप्टूल के नए संस्करणों के साथ स्थापित करने योग्य नहीं होंगे, जब तक कि डिफ़ॉल्ट रूप से pep517 बिल्ड स्पष्ट रूप से अक्षम न हों।

यह बहुत ही प्रभावशाली है यदि आप सिर्फ उस टूलिंग के साथ एक पैकेज को स्थापित करने की कोशिश कर रहे हैं जो आपको अजगर द्वारा प्रदान किया गया है, लेकिन वास्तव में यह कुछ बेतरतीब ढंग से चीजों को स्थापित नहीं कर सकता है। मैं यह कहता हूं कि एक पल के लिए तकनीकी पहलुओं का ध्यान आकर्षित करना और अंत उपयोगकर्ता पर प्रभाव डालना जो टूलींग, पारिस्थितिकी तंत्र, पुस्तकालयों या स्वयं भाषा से निराश हो सकता है, क्योंकि अचानक (और हाँ, केवल इसके तहत) विशिष्ट परिस्थितियां), वे चीजें जो अभी ठीक से स्थापित हो सकती थीं, अब स्थापित नहीं की जा सकतीं। मुझे वास्तव में लगता है कि हमें इस अंतर को लागू होने वाले किसी भी समाधान में बंद कर देना चाहिए।

हम वर्तमान में पिपेनव में विफल प्रतिष्ठानों को संभालने के लिए एक विफलता स्टैक का उपयोग करते हैं और इन परिवर्तनों के परिणामस्वरूप विफलताओं को संभालने के लिए उपलब्ध होने पर मैं --no-use-pep517 जोड़ रहा हूं। मुझे यकीन नहीं है कि यह औसत उपयोगकर्ता के लिए सहज होगा, क्योंकि यह शायद यह भी तुरंत स्पष्ट नहीं है कि समस्या का कारण क्या है। मैं यह कहना चाहता हूं कि हमारे पास वर्कअराउंड है, लेकिन उपयोगकर्ताओं को इस पर थोड़ा सा काम करने में मदद करने के लिए इस अंतर को बंद करने की कोशिश करना महत्वपूर्ण है।

(संपादित करें: pganssle, cjerdonek, pfmoore, pradyunsg, ncoghlan, और बाकी सभी जो इस समय और प्रयास के एक समूह में डाल रहे हैं, के लिए भी बड़ा धन्यवाद

जब हम PEP 517 विकसित करते हैं तो अपेक्षित उपयोग का मामला यह था कि बैकएंड्स को PyPI (या एक कस्टम इंडेक्स) पर पहियों के रूप में भेजा जाएगा, जिसे बिल्ड वातावरण में डाउनलोड और इंस्टॉल किया जाएगा। बैकएंड का निर्माण स्पष्ट रूप से दायरे से बाहर हो गया था - मेरी व्यक्तिगत धारणा यह थी कि वे PEP 517 तंत्र का उपयोग नहीं करेंगे, बल्कि निम्न-स्तरीय कमांड (setup.py bdist_wheel या फ़्लिट बिल्ड, उदाहरण के लिए) का उपयोग करेंगे। एक पीईपी 517 बैकएंड का उपयोग करके अपने आप को बनाने के लिए जटिल रूप से बहुत दूर एक कदम की तरह लग रहा था। इसे पाइप में PEP 518 के कार्यान्वयन के हिस्से के रूप में माना जाता था (यदि एक बैकड को एक sdist के रूप में भेज दिया जाता है, और खुद को बनाने के लिए खुद का उपयोग करने के लिए एक संभावित कांटा बम का उपयोग होता है, तो इससे पहले कि हम भी समर्थन का समर्थन कर सकते हैं ताकि हम बैकेंड को पहियों पर वितरित नहीं कर सकें ) लेकिन केवल PyPI से बैकएंड डाउनलोड करने के संदर्भ में।

बस इसे वापस सर्कल करने के लिए - नया setuptools.build_meta_legacy डिफ़ॉल्ट पीईपी 517 बैकेंड को छोड़कर सब कुछ के लिए पीईपी 517 का उपयोग करने के लिए समस्या को हल करता है, जो setuptools लिए एक समस्या है। यदि हम इसका समाधान नहीं करते हैं, तो @ benoit- पियरे पीपा / सेटप्टूल # 1644 में बताते हैं, लोगों के लिए pip install --no-binary :all: का उपयोग किसी भी परियोजना के लिए संभव नहीं होगा जो setuptools पर निर्भर करता है (या संभवतः किसी पीईपी 517 बैकेंड प्रदाता)।

क्या हमें इस सूत्र में चर्चा करनी चाहिए या इस पर चर्चा करने के लिए एक नया सूत्र बनाना चाहिए?

क्या हमें इस सूत्र में चर्चा करनी चाहिए या इस पर चर्चा करने के लिए एक नया सूत्र बनाना चाहिए?

मैं उसे अलग कर दूंगा। मेरी तात्कालिक भावना यह है कि समस्या यह है कि --no-binary :all: के महत्वपूर्ण अनपेक्षित परिणाम यहां हैं (एक परियोजना की उपस्थिति में उस ध्वज का उपयोग करने के प्रभाव के समान, जो केवल पहियों को वितरित करता है, एसडीएस को नहीं) और मुझे पसंद है इस धागे से --no-binary :all: आगे विचलित करने की सलाह देने के लिए (उदाहरण के लिए) में digressions से बचने के लिए।

मुझे नहीं लगता कि --no-binary :all: बिल्डिंग बैकेंड्स के साथ इस मुद्दे को ठीक करना कहीं भी उतना ही महत्वपूर्ण है जितना कि यह। यदि कोई उपयोगकर्ता पहले से ही --no-binary :all: निर्दिष्ट कर रहा है, तो वे अपेक्षाकृत आसानी से --no-use-pep517 जोड़ सकते हैं।

नया PR # 6229 जो:

1. इम्प्लीमेंट्स @pganssle ने पीईपी 517 में "स्वचालित रूप से" किसी भी pyproject.toml फ़ाइल का चयन करते हुए "ऑप्ट- करने के लिए pyproject.toml की प्रारंभिक आवश्यकता को build-system सेक्शन बनाने का अंतरिम सुझाव दिया है। बाद में रिलीज में)
2. setup.py से एक आसन्न पैकेज आयात करते हुए 3 समर्पित परीक्षण मामलों को जोड़ता है

मैं उस एक के पक्ष में अन्य 2 पीआर को बंद करने जा रहा हूं, क्योंकि यह न्यूनतम फिक्स है जिसे अंत उपयोगकर्ताओं के लिए फिर से काम करने वाली चीजें मिलनी चाहिए, और # 6210 या # 6212 जैसे एक नए सेटपूल रिलीज की तरह किसी भी भयानक हैक की आवश्यकता नहीं है

तो वह setuptools.build_meta_legacy कहाँ छोड़ता है? क्या प्रस्ताव को अब उन परियोजनाओं की आवश्यकता है जो "आयात आसन्न पैकेज" कार्यक्षमता की आवश्यकता को स्पष्ट रूप से pyproject.toml में निर्दिष्ट करें? यदि ऐसा है तो मैं दृढ़ता से सुझाव दूंगा कि कहीं न कहीं दस्तावेज की जरूरत है, इस तथ्य के साथ कि उस विनिर्देश के बिना आसन्न पैकेजों का आयात किया जाता है और इसे पाइप 19.X में हटा दिया जाएगा (हमें सहमत होना होगा कि एक्स क्या है), हम ऐसा नहीं कर सकते एक प्रोग्राम डिप्रैशन (मुझे नहीं लगता) लेकिन यह स्पष्ट रूप से दस्तावेज़ करने के लिए और अधिक कारण है, इसलिए हमें पर्याप्त सूचना के बिना कार्यक्षमता को हटाने का आरोपी (फिर से) नहीं मिलता है।

संपादित करें: लेकिन अन्यथा, नए पीआर और सारांश के लिए धन्यवाद।

संपादित करें 2: मैं देख रहा हूं कि आपने setuptools.build_meta_legacy प्रस्ताव बंद कर दिया है। मैं, इस तरह यकीन है कि मैं नहीं कर रहा हूँ के रूप में यह हमें अब क्या हमारे दीर्घकालीन योजना है कहने के लिए अवसर खो देता है, इसलिए किसी भी निंदा अवधि को बढ़ाने, जैसा कि मैंने ऊपर कहा गया है ...

@pfmoore नहीं, यह मतलब है कि वांछित व्यवहार के लिए हो रही वापस # 6163 वैकल्पिक हल को दूर करने के साथ जुड़े एक नया मुद्दा द्वारा कवर किया जाना चाहिए (शायद एक पर अपडेट करते हुए setuptools कि प्रदान करता है setuptools.build_meta_legacy )।

संपादित करें: अभी के लिए मैंने सिर्फ # 6212 को फिर से खोल दिया है, लेकिन यह स्पष्ट करने के लिए इसे वापस ले लिया कि मुझे नहीं लगता कि हमें वर्तमान में स्थापित आदेशों को विफल करने से पहले पूरे build_meta_legacy चर्चा का इंतजार करना चाहिए।

मेरा प्रस्ताव है कि वास्तव में था कि विकल्प के रूप में पीईपी के लिए 517 को निर्दिष्ट किया जाता है build-system.build-backend के अस्तित्व नहीं build-system सब पर है, और उस के बीच अब और 19.1 रिहाई, setuptools जोड़ना होगा build_meta_legacy और pip इसे डिफ़ॉल्ट बैकएंड के रूप में उपयोग करेंगे।

मैं मानता हूं कि 19.1 में, शायद pip setuptools.build_meta_legacy नहीं मिल सकता है, इसे पुराने कोड पथ पर वापस आ जाना चाहिए। यह हमें अधिकतम लोगों की संख्या में चयन करते हुए न्यूनतम ब्रेकिंग परिवर्तन देगा।

मेरा प्रस्ताव वास्तव में पीईपी 517 के लिए ऑप्ट-इन बिल्ड-सिस्टम.बिल्ड-बैकएंड को निर्दिष्ट कर रहा था

... जो केवल कमबैक के मामले में use_pep517 = False सेट करके ही संभाला जा सकता है (इसे has_pyproject सेट करने के बजाय जो अभी हम करते हैं।

19.1 में, अगर पाइप में सेटपूलटसलाइफलाइन_मेटा_एल्गेसी नहीं पाई जा सकती है, तो उसे पुराने कोड पथ पर वापस आ जाना चाहिए

मुझे नहीं लगता कि यह करने लायक है। हम पर्याप्त रूप से हाल ही में स्थापित होने वाले संस्करण को निर्दिष्ट कर रहे हैं कि हमें यकीन है कि हमें विरासत का बैकएंड मिल रहा है, और इस संभावना की पूर्ति करने की कोई आवश्यकता नहीं है कि सेटटॉप्स भविष्य के संस्करण में बैकएंड को हटा दें (या यदि वे करते हैं, तो हम बस उन्हें परिणामस्वरूप समस्याओं के लिए दोषी ठहराएं;;)

नोट: 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] तालिका" केस छोड़ता है, जो मुझे लगता है कि दोनों दिशाओं में यथोचित रूप से हल किया जा सकता है। हालांकि, जैसा कि मुझे नहीं लगता कि यह विशेष मामला व्यवहार में अक्सर सामने आने वाला है (कोई भी requires या build-backend सेट किए बिना build-system तालिका जोड़ने की परेशानी में क्यों जाएगा? build-backend ?), मैंने इसे एक तरह से हल करने के लिए चुना, जिसका अर्थ था कि पहले से परिभाषित पीईपी 518 परीक्षण मामले को पारित किया गया था, बजाय एक दूसरी अपेक्षित विफलता मार्कर को जोड़कर।

अन्य दिशा में 3 को हल करने के लिए, हमें लाइन बदलने की आवश्यकता होगी:

use_pep517 = build_system is not None

इसके बजाय:

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

इस तरह से केवल एक गैर-रिक्त आवश्यकता के लिए PEP 517 बिल्ड आइसोलेशन का उपयोग करना होगा (जिसका अर्थ 4 वे परीक्षण केस जोड़ना भी होगा, क्योंकि खाली और गैर-रिक्त build-system.requires फ़ील्ड अब भिन्न व्यवहार करेंगे)।

यहाँ बिन बुलाए योगदान के लिए खेद है, लेकिन मैं यह ध्यान देने में मदद नहीं कर सकता कि यह सब sys.path पर cwd से बचने के लिए एक बहुत विस्तृत तरीके की तरह लगता है और अंततः उन चीजों को छोड़ देगा जो काम करते थे, जो काफी विघटनकारी लगता है एक UX के नजरिए से।

उपयोगकर्ताओं और पैकेजों की संख्या एक से प्रभावित होती है। कम से कम उनमें से कुछ के पास [build-system] खंड परिभाषित है और _also_ पुराने व्यवहार पर भरोसा करते हैं, और इसलिए उन सभी के लिए टूटे रहेंगे जिनके पास उन संस्करणों को पिन किया गया है।

@techalchemy हाँ, में मूल धारणा pip था कि setuptools.build_meta एक से एक ही तरह से काम किया sys.path परिप्रेक्ष्य इस बात का प्रत्यक्ष मंगलाचरण setup.py करता है, और है कि इस धारणा गलत साबित हुआ। एक बार setuptools रिलीज होने वाली setuptools.build_meta_legacy बैकग्राउंड को https://github.com/pypa/setuptools/pull/1652 में परिभाषित किया गया है, तब # 6212 पूरा हो सकता है, और यह लंबा होगा शब्द का संकल्प। हालाँकि, इस तरह की रिलीज़ के लिए कोई वर्तमान ईटीए नहीं है, इसलिए हमें sys.path के स्रोत पैकेज पर वापस पाने के लिए pip संकल्पों की खोज जारी रखने की आवश्यकता है जो स्पष्ट रूप से "पीईपी 517 देशी नहीं हैं" ”।

# 6229 में मैंने " पीईएसपी 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/ में तैयार किया गया है। --no-binary :all: के साथ संगत हो

AWOL RM होने के लिए क्षमा करें। चीजें ऐसी हुईं जिनका मुझे अनुमान नहीं था।

मैं स्पष्ट रूप से इसके लिए सेटपूल-साइड फिक्स पसंद करता हूं लेकिन # 6210 मेरे साथ भी ठंडा है - शॉर्ट टर्म फिक्स के रूप में।

मैं @techalchemy और @pradyunsg से सहमत हूं - मुझे लगता है कि सेटपूलस-साइड फिक्स यहां सही दृष्टिकोण है। जबकि मैं पाइप के भीतर एक तेजी से ठीक करने की कोशिश करने पर काम की सराहना करता हूं, क्या ऐसे समय में _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 जानकारी के लिए धन्यवाद!

मैं pipenv साथ काम करते समय सुझाए गए वर्कअराउंड के साथ इस समस्या को हल करने में असमर्थ था। $ # $ $ $ $ $ $ # $ 2 $ # $ $ # $ 3 $ # $ $ $ $ pip 18.1 Pipfile pipenv मिलते रहें। मैं मैन्युअल रूप से 18.1 पर पाइप सेट कर सकता हूं, लेकिन जब मैं पिपेनव आभासी वातावरण को फिर से तैयार करता हूं तो पिपेनव नवीनतम पाइप में अपग्रेड करेगा चाहे कोई भी हो ... इसे बनाने के लिए कोई सिफारिशें?

@altendky अफसोस की बात है, कविता के लिए भी) उपयोगकर्ताओं के लिए संभव नहीं है। दोनों नवीनतम संस्करण का उपयोग करते हैं। इसलिए मैं अनुमान लगा रहा हूं कि बहुत से लोग अभी के लिए टूटी हुई पाइपलाइनों के साथ फंस गए हैं

और भी अजीब बात है, यह लगातार नहीं हो रहा है। मैंने एक ऐपवॉर की नौकरी फिर से की है, पहला पास हुआ, दूसरा असफल रहा हालांकि वे सख्ती से समान हैं

यदि किसी की टाइमलाइन के बारे में किसी की सोच है, तो मुझे उम्मीद है कि हम इस सप्ताह के अंत तक या अगले सप्ताह की शुरुआत में एक फिक्स तैयार कर पाएंगे और उसके बाद जल्द ही बग को ठीक कर देंगे।

सेटप्टूल का नया संस्करण, 40.8.0 अब build_meta:__legacy__ बैकेंड के साथ उपलब्ध है।

धन्यवाद! और यह कुछ हम PyInstaller उपयोग करने के लिए बात करनी चाहिए? वो थे
परिवर्तनों से काफी दुखी ... कोई भी दस्तावेज या पीईपी मैं प्रस्तुत कर सकता हूं
परिवर्तनों का समर्थन करने के लिए उनके साथ?

Tue, Feb 5, 2019, 10:24 पॉल गन्सल < नोटिफिकेशन @github.com पर लिखा:

सेटपूल का नया संस्करण, संस्करण 40.8.0 अब के साथ उपलब्ध है
build_meta: __ विरासत__ बैकेंड।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/pypa/pip/issues/6163#issuecomment-460747909 , या म्यूट
सूत्र
https://github.com/notifications/unsubscribe-auth/ADtXZjnOfu56IYR6VEKK4yowMg3XdcFEks5vKcxBgaJpZM4nNvmP
।

@AlmogCohen नहीं, यह ऐसी जिसका आपको सीधे उपयोग करना चाहिए, यह केवल PEP 517 फ्रंट-एंड द्वारा उपयोग के लिए है। अगला कदम pip लिए build_meta:__legacy__ का उपयोग अपने डिफ़ॉल्ट बैकेंड के रूप में शुरू करने के लिए है। यह अंतिम-उपयोगकर्ता के दृष्टिकोण से कार्रवाई योग्य नहीं है।

नई रिलीज पर कोई ईटीए जो फिक्स को एकीकृत करेगा?

कुछ घंटों में। :)

पिन किए गए मुद्दे को देखें।

इसके लिए फिक्स के साथ पाइप 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\

इस थ्रेड को स्वचालित रूप से बंद कर दिया गया है क्योंकि इसे बंद करने के बाद हाल ही में कोई गतिविधि नहीं हुई है। कृपया संबंधित बग के लिए एक नया मुद्दा खोलें।