<p>pip 19.0이 CWD에서 설치할 패키지를 가져 오는 패키지를 설치하지 못함</p>

이것은 pyinstaller가 설치를 위해 자체적으로 가져 오는 방법과 관련된 문제인 것 같습니다.

PyInstaller 직원에게 문제를 제출하는 것이 좋습니다.

현재 18.1을 사용하고 있으며 19.0으로 업그레이드하면이 문제도 발생합니다. pip ''가 sys.path에 없기 때문에 PyInstaller 리포지토리에 관련 문제가 있습니다.

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 파일을 사용함으로써 기본적으로 pip에게 PEP 517/518을 사용하고 싶다고 말하고 있습니다.

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

위의 내용은 PyInstaller를 빌드하기 위해 setuptools 및 wheel 가 필요하다고 pip에 알려줍니다. 그러나 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 코드가 pandas가 setup.py 옆에있는 versioneer.py를 가지고 있기 때문에 패키지 디렉토리의 루트가 sys.path에 있는지 확인하지 않는 것입니다. 나는 이것이 언젠가 다가오는 것을 기억하지만 그 토론이 무엇인지 머릿속에서 기억하지 못합니다. 이는 pip 대신 setuptools 빌드 백엔드의 문제로 간주되거나 pip의 격리 메커니즘의 결함 일 수 있습니다.

[...] 누군가가 --no-use-pep517이이 문제를 해결하는지 확인해 주시겠습니까?

PyInstaller는 --no-use-pep517 잘 설치됩니다.

좋습니다. 새로운 PEP 517 코드의 문제이며 프로젝트 루트를 포함하는 디렉토리가 sys.path 에 추가되지 않았다는 것이 문제라고 확신합니다. 아마도 @pfmoore 는 그것이 pip의 책임인지 설정 도구인지 더 잘

이것이 도움이된다면 ( 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을 사용하는 경우 작동합니다.
pendulum == 1.5.0 (AttributeError : 모듈 'enum'에 'IntFlag'속성이 없음)
pendulum == 1.5.1 (AttributeError : 모듈 'enum'에 'IntFlag'속성이 없습니다.)
pendulum == 2.0.0 (AttributeError : 모듈 'enum'에 'IntFlag'속성이 없음)
pendulum == 2.0.1 (AttributeError : 모듈 'enum'에 'IntFlag'속성이 없음)
pendulum == 2.0.2 (AttributeError : 모듈 'enum'에 'IntFlag'속성이 없음)

2.0.3 및 2.0.4는 잘 설치됩니다.

cartopy (최소한 최신 릴리스)도 19.0 이후 설치에 실패하여 setup.py 옆에있는 versioneer.py를 가져 오지 못함

이것은 내가 다루는 일부 프로젝트의 문제이기도합니다. pyproject.toml을 사용하여 python black 매개 변수를 정의하고 setup.py에서 유사한 from project.version import __version__ 를 수행합니다.

최소한 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가이를 수행하지 않으면 pip는 빌드 디렉토리를 sys.path 추가 할 수 있지만 PEP 517은이를 프론트 엔드의 책임으로 간주하지 않습니다.
3. 빌드 디렉토리를 요구하는 것은에 후크 볼 수 있도록 sys.path 적어도 PEP의 설명을 필요로한다.

이 시나리오는 PEP 517이 개발 될 때 고려되지 않았다고 생각합니다. 아마도 그것은 setuptools에 특정한 (또는 빌드의 일부로 임의의 Python 코드를 실행하는 백엔드에 특정한) 때문일 수 있습니다.

나는 사람들이 현재 디렉토리에서 setup.py 로 무언가를 가져오고 일반적으로 setup.py 이 $PWD 있는 것처럼 취급하는 것이 매우 일반적이라고 생각합니다.

나는 위에이 책임 밀어 합리적인 생각 setuptools 그 아마 정말 그것을 필요로하는 유일한 프로젝트이기 때문에.

네, 이것에 대해 좀 더 생각하면 setuptools 백엔드 책임이라고 확신합니다. PEP 517 이전, pip는 setup.py 를 스크립트로 실행 했으므로 표준 Python 규칙은 스크립트 디렉터리를 sys.path 합니다. PEP 517에서 setup.py 호출은 백엔드 후크에 대한 호출로 대체되므로 해당 후크는 의미를 보존해야합니다. setuptools는 후크에서 setup.py in-process를 실행하므로 sys.path 자체를 관리해야합니다. 바라건대, 그것은 그들에게 큰 해결책이 아닙니다. @jeanlaroche (또는이 문제를 해결 한 다른 사람)가이 스레드를 다시 참조하여 setuptools 추적기에서 문제를 제기 할 수 있습니까?

[...] 누군가가 --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의 Build Environment 섹션을 읽었을 때 pyproject.toml 선언 된 종속성을 사용할 수 있다는 점을 제외하고는 환경에 대해 가정해야하는 것이 없다고 생각합니다.

또한 setup.py 에서 설치중인 패키지를 가져 오는 것도 나쁜 습관이 아닌가? PyPA 의이 패키징 가이드에 설명 된 것처럼 한곳에서 패키지 버전을 유지하는 훨씬 더 좋은 방법

나는 모두이를 바라고 사람들이 있다는 사실에 의존 중지 갈 수있는 기회가 될 수 @uranusjr 및 pypa / setuptools에 # 1642에서 토론에서는 . 에 sys.path 당신은을 실행할 때 python 스크립트를 작성하고 사람들을보다 명시적인 의미 체계로 이동하기 시작합니다.

여기서 가장 큰 문제는 pyproject.toml 존재만으로 사람들이 PEP 518과 PEP 517을 모두 선택하는 것이므로 빌드 백엔드를 지정하지 않더라도 갑자기 새로운 의미를 갖게됩니다.

이 시점에서 pip 의 부분에 대한이 결정은 되돌릴 수 없습니까? 아마도 우리는 pyproject.toml 의 존재를 가지고 PEP 518에 옵트 인 할 수 있지만 실제로 빌드 백엔드를 지정하지 않는 한 PEP 517이 트리거되지 않습니까?

솔직히 말해서 모든 상황이 험난하지만 setuptools 보다는 pip 가 경고하는 것이 더 쉽다고 생각 합니다. 지금 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 에서 설치되는 패키지를 전략 6으로 정의하므로 확실히 다소 일반적입니다. 이 시점에서 우리가 그러한 종류의 전략에서 벗어나면 더 이상 포함하지 않도록 해당 페이지를 업데이트해야합니다.

pyproject.toml 의 존재에 대해 PEP 517을 트리거하기로 한 결정은 의도적 인 선택이었습니다 (논의는 PEP 517 구현 문제 또는 PR에 대한 것이었지만 지금은 찾을 시간이 없습니다). 분명히 우리가 여기에서 보는 것에 비추어 변경할 수 있지만, 우리가 결정을 내린 이유를 고려하지 않고는 그렇게해서는 안됩니다.

Pip 자체는 setup.py 이 프로젝트 디렉토리가 sys.path 에 있다고 가정하는 것이 옳은지 여부에 대한 견해를 갖지 않으므로 간단히 pip를 변경하는 것을 다소 꺼립니다. setuptools는 백엔드가 사용될 때 다른 기본값을 푸시하려고하기 때문입니다. setup.py 에서 빌드중인 프로젝트를 가져 오는 데 많은 어려움이 있다는 데 동의하지만 지금까지 경고를 유발 한 것이 아니기 때문에 백엔드가 해당 의미를 유지해야한다고 가정했습니다. 다른 말로하면, pip가 당신이 제안한대로 경고 했음에도 불구하고, 왜 사용자들은 "당신은 setup.py 에서 당신의 프로젝트를 가져올 수 없을 것입니다."라는 의미로 "빌드 격리는 기본적으로 setuptools.build_meta 를 사용합니다"라고 읽었 을까요? setup.py "? 두 가지 사실은 나와 관련이없는 것 같습니다 ...

개인적으로 나는 pyproject.toml 파일의 존재에 의존하는 현재 접근 방식에 동의합니다. IMO 문제는 패키징 이외의 용도로 pyproject.toml을 사용하는 사람들에서 비롯됩니다. 따라서 올바른 방법은 비 패키징 도구를 푸시하여 다른 구성 방법을 제공하는 것이므로 사람들이 pyproject.toml을 사용할지 여부를 선택할 수 있습니다.

Pip 자체는 setup.py가 프로젝트 디렉토리가 sys.path에 있다고 가정하는 것이 옳은지 여부에 대한 견해를 갖지 않으므로 setuptools가 푸시를 원하기 때문에 pip를 변경하는 것을 다소 꺼려합니다. 백엔드가 사용될 때 다른 기본값.

사실, pip 는 setuptools.build_meta 후크를 호출하는 것이 setup.py 호출과 완벽하게 동일해야한다고 가정하고 있습니다. 우리는 이미 그렇지 않은 경우를 보았고, 우리 ( setuptools )가 setuptools.build_meta 의 계약을 "이것이 python setup.py 를 호출하는 것과 동일하기를 원하는지 여부는 아직 확립되지 않았습니다 setuptools python setup.py "또는 대신"이것은 setup.py 직접 호출하는 좀 더 잠겨 있고 격리 된 버전입니다 ".

물론 setuptools 는 "기능의 계약이 아니므로 수정하지 않을 것입니다."라고 말할 수 있고 pip 는 "기본적으로 PEP 517로 설정하는 것이 었습니다"라고 말할 수 있습니다. 버그가 다른 프로젝트에 있다고 둘 다 말할 수 있지만 조정하는 것이 좋습니다.

다시 말해, pip가 제안한대로 경고 했더라도 사용자가 "빌드 격리는 기본적으로 setuptools.build_meta를 사용하도록 설정됩니다"라는 메시지가 "setup.py에서 프로젝트를 가져올 수 없습니다"라는 의미로 읽는 이유는 무엇입니까? 두 가지 사실은 나와 관련이없는 것 같습니다 ...

관련이있을 수도 있고 아닐 수도 있지만 의미 체계에 다른 변경 사항이있을 수도 있습니다. 이와 같은 경고의 요점은 "이 빌드가 어떻게 이루어지기를 원하는지 명시 해주세요. 곧 빌드를 손상시킬 수있는 무언가를 선택할 것입니다." 프로젝트는 사전에 pyproject.toml 빌드 백엔드를 추가하고 발생할 수있는 모든 파손을 사전에 수정할 수 있습니다.

우리는 또한 가능성에 "더미"PEP 517 백엔드 만들 수 setuptools 같은 setuptools.build_meta_legacy 단지 chdir 의 루트 디렉토리에 넣고 원용 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 통해 기존 코드 경로를 삭제하는 것으로 비교적 빠르게 전환한다는 것입니다. 위의 제안 된 릴리스를 사용하기 위해 pip 21.0에서만 setuptools 백엔드를 만들면 추가로 2 년이 더 걸립니다.

PEP 517은 기본 백엔드가 무엇인지에 대해 아무것도 지정하지 않습니다.

진실. 그러나 어느 시점에서 pip 는 setuptools의 특별한 경우 지원을 중단합니다. 즉, PEP 517의 전체 요점 (적어도 우리에게는)이 백엔드에서 프런트 엔드를 분리하고 모든 백엔드를 동일한 기반에 배치하는 것입니다. 따라서 그렇게 할 때마다 백엔드가 없으면 오류를 발생 시키거나 기본값을 선택해야합니다 (레거시 이유로 인해 setuptools로 기본값을 설정하겠습니다). 여기서 논쟁은 우리가 그렇게 할 때입니다.

Pip에는 현재 PEP 517 경로와 기존 setup.py 경로의 두 가지 코드 경로가 있습니다. 이것이 유지 관리 문제의 원인이며 잠재적 인 버그입니다. 우리는 PEP 517 경로의 사용을 보장하기 위해 pyproject.toml 가있는 경우 PEP 517을 기본값으로 설정했습니다 (프로젝트가 build-backend = setuptools.buid_meta 를 추가하기 위해 서두르지 않을 것이므로 현재 동작이 없으면 확률은 다음과 같습니다. pip의 PEP 517 코드와 setuptools의 백엔드 테스트는 오랜 기간 동안 거의 0에 가깝습니다.) setuptools 백엔드가 부적합한 경우 (드물다고 가정)를 정확히 처리하기 위해 --no-use-pep517 형식의 옵트 아웃이 있습니다.

나는 setuptools가 setup.py 와 백엔드 사이의 의미 적 차이를 원할 것이라고 예상 한 사람이 없다고 생각합니다. 따라서 의미 적 차이를 해결하기 위해 --no-use-pep517 가 필요할 가능성이 있습니다. 기본값은 고려되지 않았습니다.

또한 setuptools.build_meta_legacy와 같은 setuptools에서 "더미"PEP 517 백엔드를 생성 할 수 있습니다.이 백엔드는 루트 디렉토리로 chdir하고 setuptools.build_meta를 호출합니다. 이렇게하면 사람들이 중단되기 전에 필요한 경우에만 이전 동작을 선택할 수 있습니다. .

그것은 합리적인 해결책이 될 수 있습니다. 그러나 최소한 부분적으로 문서화되어야합니다. 최소한 pip는 이것이 우리가 가정하는 기본값임을 문서화합니다. setuptools가 백엔드를 문서화되지 않은 상태로 두 었는지 여부는 그들이 선택한 것입니다.

더 이상의 이론적 논의가 얼마나 유용한 지 잘 모르겠습니다. 확실히 더 이상 추가 할 것이 없다고 생각합니다. 누군가가 이것을 진행하고 싶다면 가장 좋은 방법은 기본값을 전환하는 PR을 만들고 우리가 수락할지 여부에 대한 논의가 거기로 넘어갈 수 있다는 것입니다.

사용자를 위해이 문제를 해결하려는 패키지 관리자를 위해 : sys.path 수정을 구현하는 shim을 게시했습니다.

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

바라건대 이것은 임시 방편으로 작동하여 솔루션으로 서두르지 않고 앞으로 나아가거나 불필요하게 pip 19.0 (PEP 517보다 훨씬 더 많은 혜택을 포함)의 채택을 늦추지 않고 어떻게 진행해야하는지 고민 할 수 있습니다.

sys.path 수정을 구현하는 shim을 게시했습니다.

굉장합니다! 궁극적 인 수정에 관계없이 이것은 PEP 517 후크 시스템의 유연성을 보여주는 정말 좋은 예입니다. :-)

19.x에서 내 pip 버전을 다운 그레이드하여 수정 한 다음 설치를 시도하고 성공적으로 진행했습니다.

세 번째 사용 사례가 있습니다. 자체 빌드 백엔드를 제공하는 패키지는 어떻습니까? 예 : setuptools 자체는 빌드 요구 사항으로 wheel 만 나열합니다.

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

물론 PEP 517을 처리하는 pip의 코드가 소스 디렉토리를 sys.path 추가하지 않으면 실패합니다.

PEP 517에서 :

모듈 경로를 가져올 때, 어쨌든 sys.path에 있지 않는 한 (예를 들어 PYTHONPATH에 지정되어 있기 때문에) 소스 트리를 포함하는 디렉토리를 찾지 않습니다. Python은 일부 상황에서 자동으로 작업 디렉토리를 sys.path에 추가하지만 백엔드를 해결하는 코드는 이에 영향을받지 않아야합니다.

그것은 매우 명확하게 (나에게) 프로젝트가 build-backend 해결할 때 프로젝트가 자신의 프로젝트 디렉토리를 볼 수있을 것으로 기 대해서는 안된다고 말합니다. 따라서 setuptools는 자신을 requires IMO에 추가해야합니다. 그리고 네, 그렇게하는 것이 순환 적이라는 것을 이해합니다. 그러나 스스로 빌드하는 빌드 백엔드는 본질적으로 꽤 순환 적입니다. 확실히 정상적인 경우는 아닙니다.

이 섹션은 빌드 도구가 프로젝트 디렉토리가 빌드 환경의 sys.path 에있을 것으로 예상하지 않아야 함을 확인하는 것으로 보입니다.

--no-binary :all: 어떻게 작동합니까?

@pfmoore 상황의 변형은 패키지가 사용자 지정 빌드 시스템을 제공한다는 것입니다. 빌드 시스템은 설치되어 있지 않지만 (bdist의 일부가 아님) sdist와 함께 제공되어 일부 빌드 프로세스를 사용자 지정합니다. 이것이 유효한 사용 사례입니까, 아니면 관리자가 사용자 지정 빌드 시스템을 별도의 패키지로 게시해야합니까?

편집 : 같은

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 = [""]

pip는 사용자에게 마이그레이션을 알리는 경고 / 정보 메시지를 표시 할 수 있습니다 (문서 페이지 링크 포함).

이 솔루션의 또 다른 이점은 모든 것이 pip (실제로 공급되는 pep517 모듈)에서 수행 될 수 있다는 것입니다. setuptools 또는 기존의 깨진 프로젝트에서 변경할 필요가 없습니다.

상황의 변형은 패키지가 사용자 지정 빌드 시스템을 제공한다는 것입니다.

솔직히 모르겠습니다. 나 자신에 대해 생각했던 상황이 아닙니다. PEP 작성자가 고려했는지는 모르겠습니다. PEP가 개발되었을 때이 문제에 대해 논의한 내용이 없습니다.

실제로 확인한 후 PEP 517은 명시 적으로 ( build-backend 섹션에서) "모듈 경로를 가져올 때 sys.path에 있지 않는 한 소스 트리를 포함하는 디렉토리를 보지 않습니다. "인트 리 백엔드를 사용하는 것이 명시 적으로 권장되지 않음을 의미합니다. 누군가가 충분히 교활한 코드로이 문제를 해결할 수 있는지 여부는 확실하지 않습니다.

PEP 517을 개발할 때 예상되는 사용 사례는 백엔드가 빌드 환경에 다운로드되고 설치되는 PyPI (또는 사용자 지정 인덱스)의 휠로 배송된다는 것입니다. 백엔드는 범위에서 명시 적이었다 만들어진 방법 - 내 개인 가정 그들이 PEP (517 개) 메커니즘을 사용하지 않을, 오히려 낮은 수준의 명령을 (사용할 것이라고했다 setup.py bdist_wheel 또는 flit build , 예를 들어 ). 반복적으로 PEP 517 백엔드를 사용하여 자체를 구축하는 것은 복잡한 단계처럼 보였습니다. 이는 pip의 PEP 518 구현의 일부로 간주되었습니다 (백엔드가 sdist로 제공되고 자체 구축에 사용되는 경우 잠재적 인 포크 폭탄 공격이 있습니다. 우리는 바퀴로 배포되지 않은 백엔드를 지원하기 전에 방지해야했습니다. ) 그러나 PyPI에서 백엔드를 다운로드하는 맥락에서만 가능합니다.

tl; dr; 제가 제공 할 수있는 것은 당시의 토론에 대한 기억뿐입니다. 실제 배경에 대해 아카이브를 검색하는 것이 더 나을 수 있습니다.

PEP 작성자가 고려했는지는 모르겠습니다. PEP가 개발되었을 때이 문제에 대해 논의한 내용이 없습니다.

나는 방금 아카이브를보기 시작했고,이 질문은 실제로 프로세스가 끝날 무렵 (또는 적어도 그 안에) 자세히 논의 된 것으로 보입니다. 아카이브를 보는 데 가장 적합한 웹 사이트는 없지만 토론이이 질문에 대해 다시 이야기하기 시작하는 지점이 있습니다 (2017 년 7 월 28 일).
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에 있지 않도록 명령하고 python-path에 대해서만 약간의 후속 PEP를 수행하도록하는 것이 더 합리적 일 수 있습니다.

최종 판결이 무엇인지 알게되면 알려 드리지만 다른 사람들이 직접 읽어 보도록 권장합니다.

좋은! 찾아 주셔서 감사합니다 :-)

그래서 저는 많은 이메일을 훑어 보았고, 적어도 8 월 29 일로 건너 뛸 수 있다고 생각합니다. Nick이 sys.path의 소스 디렉토리 _out_을 떠나는 것에 대한 합의가 있다고 제안하는 것 같습니다.
https://mail.python.org/pipermail/distutils-sig/2017-August/031413.html
(사람들은 하나씩 나다니엘의 주장을 확신하게되었습니다.)

그러나 위에 링크 된 동일한 이메일에서 Nick은 다음과 같이 말합니다. :)

1. 생략하는 것이 정말로 문제라면 setup.py 백엔드 구현의 일부로 곧 알게 될 것입니다.

다음은 이메일의 전체 단락입니다.

나는 우리가 우리가 초기의 일환으로 새로운 것을 배우는 우리의 기회를 극대화가 의미합니다 시작으로, "현재 디렉토리가 지정된 백엔드를 가져 오기 전에의 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 를 업그레이드하면 빌드가 손상된다는 것을 처음 발견 한 후에 만 ​​발견됩니다.

기능적인 관점에서 우리가 소개하고자하는 주요 변경 사항은 " build-system 섹션이없는 pyproject.toml "케이스에서 setup.py 포함하는 디렉토리가 종료되어야한다는 것입니다. 다시 sys.path . 이를 처리하는 두 가지 주요 방법이 있습니다.

1. pip 를 받아보세요. 이는 동작 프런트 엔드를 종속적으로 만드는 불행한 부작용이 있으므로 모든 프런트 엔드가 동일한 해결 방법을 구현하지 않으면 기존 프로젝트가 설치되지 않는 것을 볼 수 있습니다.
2. build-system 섹션에 대해 pyproject.toml 를 검사하고 setup.py 디렉터리를 sys.path 삽입하여 setuptools PEP 517 백엔드를 가져옵니다. 섹션과 경로 항목이 모두 누락 된 경우. " build-system 섹션 없음"사례를 올바르게 처리하는 최소 버전의 setuptools를 지정해야하므로 새로운 pip 가 여전히 필요합니다.

불행한 디자인 코너에 우리 자신을 칠하지 않고 가능한 한 빨리 최종 사용자를 위해 일을 처리하기 위해 실제로 3 단계 해결책을 제안합니다.

1. " build-system 항목 없음"사례에 대한 추가 sys.path 항목을 추가하는 새 pip 릴리스 (19.0.1?)를 지금 수행하십시오. 이 시점에서 최종 사용자에게는 호환성 문제가 크게 해결되어야합니다.
2. 프런트 엔드가 아직 수행하지 않은 경우 sys.path 추가를 처리하는 새로운 setuptools 릴리스를 수행합니다.
3. 이후 pip 릴리스에서는 "no build-system entry"케이스를 변경하여 특수 케이스를 삭제하고 대신 setuptools 대해 더 엄격한 최소 버전을 설정하십시오.

이 제안은 setuptools PEP 517 백엔드가 setup.py 하위 호환성 문제를 처리하기에 "올바른"장소라고 생각하지만 pip 직접적으로는 가까운 시일 내에 훨씬 더 간단한 변경이 될 수 있으며, 구조적으로 더 바람직한 수정 작업을 수행하는 동안 문제를 포함 할 변경입니다.

pypa / setuptools # 1652에 build_meta_legacy 백엔드를 만들었습니다. pip 가 setuptools.build_meta_legacy 를 기본 백엔드로 사용하도록 전환하는 경우 정말 선호하지만 기본 제공 "레거시 shim"백엔드를 만드는 것이 편한 정도라고 생각합니다. setuptools . 메인 setuptools PEP 517 백엔드에서 " python setup.py install 에뮬레이션"전체를 무기한 지원하지 않기를 바랍니다.

나는 setuptools가 TBH에서 기본적으로 스크립트를 실행하는 것을 에뮬레이트하고 싶지 않은 이유를 약간 혼란스럽게합니다. python setup.py bdist_wheel 가 올바르게 작동 할 때 최종 사용자에게 혼동을 줄 것을 요청하는 것처럼 보이지만 pip wheel 는 작동하지 않습니다 (레거시가 아닌 빌드 백엔드로 설정했다고 가정).

그 이유는 무엇입니까?

그 이유는 무엇입니까?

내 장기 계획은 PEP 517 프런트 엔드 또는 이와 동등한 것 (다른 명령의 경우)에 의한 간접 호출을 위해 setup.py 의 모든 직접 호출을 사용하지 않는 것입니다. 우리는 "모든 격리 환경"세계로 이동하는 경우, 나는의 의미 유지하도록 강요하지 않으 setuptools 호출과 호환 명령 호출 python setup.py 같은 이유 PEP를 들어, 517은 특히 프런트 엔드가이를 수행해서는 안된다고 말했습니다. 빌드 격리를 깨고 일반적으로 바람직하지 않은 상황을 만들 가능성이 있습니다.

안티 패턴의 일부를 제외하고는 이것이 필요한 경우는 매우 드뭅니다. 정당한 필요가있는 사람은 누구나 설정 스크립트에서 sys.path 를 매우 쉽게 조작 할 수 있습니다.

참고로 PEP 517이 후크를 통해 모든 빌드 도구에 액세스 할 수 있다는 디자인 목표를 가진 적이 없다고 생각합니다. 예를 들어, flit에는 flit build 등의 고유 한 명령 세트가 있으며 이러한 명령을 폐기 할 의도는 없습니다. 따라서 PEP 517의 의도가 도구 별 명령을 사용해야하는 경우에 가장 적합한 경우를 찾을 수 있습니다. 명백한 예는 위에서 언급했듯이 백엔드 자체를 빌드하는 것이지만 편집 가능한 설치 및 현재 위치 빌드 (이전 빌드의 아티팩트 재사용)와 같은 다른 경우 (현재 표준화되지 않았지만 향후 PEP가 후크를 추가 할 수 있음)가 존재합니다.

모든 도구가 "build sdist"및 "build wheel"을 지원할 수 있다는 동의를 얻는 것은 더 이상 표준 작업 목록을 확장 할 것으로 예상하지 않을만큼 어렵습니다.

참고로 PEP 517이 후크를 통해 모든 빌드 도구에 액세스 할 수 있다는 디자인 목표를 가진 적이 없다고 생각합니다.

이것은 내가 제안한 것이 아니며 약간의 여담입니다. 내 요점은 PEP 518을 필요로하는 문제가 모든 setup.py 명령에 대해 더 일반적으로 존재하며 사람들을 setup.py 호출에서 멀어지게함으로써 가장 잘 해결된다는 것 입니다. flit 는 하위 명령을 추가하기 위해 PEP가 필요하지 않은 것과 같은 방식으로이를 수행하기 위해 표준이 필요하지 않습니다.

그래. 오해해서 죄송합니다.

@ncoghlan 의 제안 된 전환이 나에게 좋은 것 같습니다. 아무도 그것에 문제가 없다면 계속 진행합시다.

@cjerdonek 아카이브를 찾아 주셔서 감사합니다!

기존 백엔드 도입을 통해 setuptools에서이를 수정하는 PR이 이미 있다는 점을 감안할 때. 위의 1 단계를 건너 뛰지 않는 이유가 있습니까? 격리 된 빌드 환경에 setuptools를 설치하고 있으므로 최신 버전에 따라 문제가되지 않습니다.

위의 1 단계를 건너 뛰지 않는 이유가 있습니까?

아니. 현재 최소 필수 버전을 직접 올릴 수 있습니다.

내 전환 계획은 사람들이에 수명이 긴 전환 메커니즘에서 작업에 더 많은 시간이 필요할 것이라는 가정에 근거 setuptools 측면 -while @pganssle의 그 전면에 약속 전용 전환 백엔드 외모, 난 변경 사항을 검토하는 동안 현상 유지를 그대로 두는 것이 타당하지 않습니다.

즉, pip 에서 PEP 517 구현이 어떻게 작동하는지에 대한 세부 사항에 대해 잘 모르기 때문에 프런트 엔드에서 문제를 해결하는 것이 간단 할 것이라는 내 가정은 올바르지 않을 수 있습니다.

백엔드는 하위 프로세스에서 실행되기 때문에 (실제로는 공급 업체가 제공하는 pep517 프로젝트를 사용하여 간접 수준을 추가 함) sys.path 를 설정하는 방법이 명확하지 않습니다. 백엔드 후크. 최소한 PYTHONPATH 를 포함해야합니다. 즉, 사용자가 이미 PYTHONPATH 세트를 가지고있는 경우와 격리 코드에서이를 사용하는 방법에 대해 걱정해야합니다.

본질적으로 pip에 sys.path 를 설정하는 것은 분명히 사소한 일이 아니라고 생각합니다. 세부 사항을 조사 할 시간이 없을 것 같고, 패치를 작성하는 것보다 훨씬 적습니다 (그리고 제대로 테스트되었는지 확인하십시오!).

고정 setuptools 백엔드를 얻는 것이 가장 빠른 방법이라고 생각합니다.

내 장기 계획은 PEP 517 프런트 엔드 또는 이와 동등한 것 (다른 명령의 경우)에 의한 간접 호출을 위해 setup.py의 모든 직접 호출을 사용하지 않는 것입니다.

@pganssle 아야. setup.py 절차는 반드시 죽어야합니다. 어떤 이유로 든 존재해서는 안됩니다. 이 "유연성"은 고통과 쇠약의 끝없는 원천이기 때문입니다. setup.py 마이그레이션이 불가능하므로 Python 패키징의 모든 문제가 발생합니다.

setup.py 를 package.json 바꾸고 다른 패키지 설명 형식 대신 Python 섹션을 추가합니다.

적어도 ==1.x 버전 지정자를 사용할 수 있습니다.

@techtonik 저리 가세요 . 귀하의 비 구조적 기여는 내가 참여하고있는 어떤 프로젝트에서도 환영받지 못합니다.

# 6210 작업을 통해 pip 수준에서이 문제를 해결하는 것이 얼마나 어려운지에 대한 위의 질문에 답할 수있었습니다. 문제는 소스 디렉토리를 sys.path[0] 로 삽입해야하는지 여부에 대한 정보입니다. pyproject.toml 를 읽는 코드에서 PEP 517 후크 호출자까지 터널링 된 다음 거기에서 실제 프로세스 내 래퍼 스크립트로 터널링되어야합니다.

이는 주요 아키텍처 변경 (첫 번째 부분의 경우 빌드 백엔드 이름에 pip._implicit. 접두사, 후자의 경우 PEP517_SYS_PATH_0 환경 변수)없이 수행 할 수 있지만, 이는 일시적으로 공급 업체 pep517 수정하는 것을 의미합니다 setuptools 의 적절한 수정이 준비 될 때까지 pep517 코드.

내 전환 계획은 사람들이 setuptools 측에서 오래 지속되는 전환 메커니즘을 해결하는 데 더 많은 시간이 필요하다는 가정에 기반을두고 있습니다. @pganssle 의 전용 전환 백엔드는 그 측면에서 유망 해 보이지만 말이되는지 잘 모르겠습니다. 변경 사항을 검토하는 동안 현재 상태를 유지합니다.

네, 동의합니다. 나는 distutils 게시물에서 이것을 제안했습니다. 중요한 두 가지가 있습니다.

1. 최대한 빨리 사용자를 위해 수정하기
2. 적절한 전환이 이루어집니다.

개인적으로해야 할 옳은 일은 전환 로직이 제자리에있을 때까지 "pyproject.toml의 존재가 PEP 517을 선택합니다"로직을 제거하는 것이라고 생각합니다. setuptools 의 변경 사항이 공용 API에 영향을 미치고 pip 에서는 이전 버전과 호환되지 않는 변경으로 판명 된 사항을 지연시킬 뿐이라는 점을 고려할 때 setuptools 의 진행 방향을 검토하는 동안 pip 에서 빠른 수정을 수행하십시오.

내 로컬 컴퓨터에서 두 가지 접근 방식을 모두 사용하여 문제가있는 원래 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 실패가 테스트 설정 문제인지 여부 또는 실제로 setuptools 시험판에 추가 문제가있는 경우 해당 솔루션에 확신을 갖기 전에 수행해야 할 추가 통합 작업이 있다는 것만 알고 있습니다. 나는 지금 # 6210에 자신이있다-그것의 유일한 잘못된 점은 우리가 pip 가 영원히 가지고 다니기를 원하지 않는 끔찍한 호환성 해킹이라는 것이다.

--no-cache 가 # 6212에서 assert 실패에 대한 책임이있는 것 같습니다. 대신 --cache-dir 를 사용한 테스트는 성공적인 로컬 테스트를 제공했습니다. https://github.com/pypa/pip/pull/6212#issuecomment -458166386

(저는 수면과 업무를 위해 ~ 18 시간 동안 오프라인 상태가 될 것이므로, 그동안 # 6210 또는 # 6212 중 어느 쪽이든 상관없이 자유롭게 실행해야합니다)

상황을 더 잘 반영하기 위해 제목을 업데이트했습니다. PR에 대해 @ncoghlan 에게 감사드립니다!

중재 참고 사항 : 또한 비생산적인 댓글 (및 이에 대한 응답)을 "Off Topic"으로 숨겼으며 향후 해당 라인의 모든 댓글에 대해 그렇게 할 것입니다. 중재에 대해 토론하고 싶은 사람이 있으면 새로운 문제를 제출하거나 이메일로 저를 핑하십시오. 이 스레드는 중재와 관련된 문제를 제기하기에 적합한 장소가 아닙니다.

나는 또한 사람들이 중복을 만드는 것을 방지하고 우리가 이것에 대해 알고 있다는 것을 분명히 알리기 위해 이것을 고정했습니다.

pep517을 옵트 인하더라도 이는 발표되지 않은 동작 변경이므로 이미 옵트 인한 경우에도 _ 라이브러리를 중단합니다 _ (예 PyInstaller 참조). 라이브러리가 pep517 빌드에 대한 옵트 인을 선언하고 _and_ sys.path 에서 찾을 것으로 예상되는 것을 로컬로 가져 오는 경우, pip에 의한 가정은 없지만 (라이브러리가 명시 적이기 때문에) 라이브러리는 여전히 갑자기 부서졌습니다.

이 경우 setuptools에 cwd 를 포함하는 것 외에는 대안이 보이지 않습니다. 제안이 사람들에게 pep517과 pip 19 사이에서 잘라낸 릴리스를 수정하라고 말하는 것이 아니라면, 사용자가 해당 버전을 엄격하게 고정하면 갑자기 설치가 중단 될 수 있습니다. 영향을 고려해야한다고 생각합니다. 사용자 경험에 대한 이러한 결정 중. 이 토론과 현재 제안을 기반으로 이러한 라이브러리 중 일부는 pep517 빌드가 명시 적으로 비활성화되지 않는 한 기본값을 사용하는 새로운 버전의 pip + setuptools와 함께 설치할 수 없습니다.

이것은 파이썬이 제공하는 도구로 패키지를 설치하려는 경우 매우 효과적이지만 실제로는 다소 무작위로 설치할 수 없습니다. 나는 잠시 기술적 인 측면에서 초점을 맞추고 도구, 생태계, 라이브러리 또는 언어 자체에 실망 할 수있는 최종 사용자에게 미치는 영향에 초점을 맞추기 위해 이렇게 말합니다. 특정 상황), 그들이 잘 설치할 수있는 것은 이제 설치할 수 없습니다. 구현되는 모든 솔루션에서이 격차를 좁혀 야한다고 생각합니다.

현재 pipenv에서 실패한 설치를 처리하기 위해 실패 스택을 사용하고 있으며, 이러한 변경으로 인한 실패를 처리 할 수있는 경우 --no-use-pep517 추가합니다. 나는 그것이 문제의 원인이 무엇인지 즉시 명확하지 않기 때문에 일반 사용자에게 직관적 일지 확신하지 못합니다. 해결 방법이 있음을 지적하기 위해 이렇게 말하지만 사용자가이 문제에 대해 약간의 도움을주기 위해이 격차를 좁히는 것이 중요하다고 느낍니다.

(편집 : pganssle, cjerdonek, pfmoore, pradyunsg, ncoghlan 및 이에 대해 많은 시간과 노력을 기울인 모든 사람들에게도 감사드립니다)

PEP 517을 개발할 때 예상되는 사용 사례는 백엔드가 빌드 환경에 다운로드되고 설치되는 PyPI (또는 사용자 지정 인덱스)의 휠로 배송된다는 것입니다. 백엔드가 구축 된 방법은 명시 적으로 범위를 벗어났습니다. 제 개인적인 추측은 PEP 517 메커니즘을 사용하지 않고 하위 수준 명령 (예 : setup.py bdist_wheel 또는 flit 빌드)을 사용하는 것입니다. 반복적으로 PEP 517 백엔드를 사용하여 자체를 구축하는 것은 복잡한 단계처럼 보였습니다. 이는 pip의 PEP 518 구현의 일부로 간주되었습니다 (백엔드가 sdist로 제공되고 자체 구축에 사용되는 경우 잠재적 인 포크 폭탄 공격이 있습니다. 우리는 바퀴로 배포되지 않은 백엔드를 지원하기 전에 방지해야했습니다. ) 그러나 PyPI에서 백엔드를 다운로드하는 맥락에서만 가능합니다.

이것으로 돌아가서-새로운 setuptools.build_meta_legacy 기본값은 setuptools 자체의 문제인 PEP 517 백엔드를 제외한 모든 것에 PEP 517을 사용하는 문제를 해결합니다. 우리가 해결되지 않으면 @ 벤와 - 피에르 사람들이 사용할 수 있도록 # 1644, 그것은 할 수 없습니다 pypa / setuptools에에서 지적하고 다음과 같이 pip install --no-binary :all: 에 따라 어떤 프로젝트에 setuptools (또는 아마도 모든 PEP 517 백엔드 공급자).

이 스레드에서 논의해야합니까, 아니면 논의 할 새 스레드를 만들어야합니까?

이 스레드에서 논의해야합니까, 아니면 논의 할 새 스레드를 만들어야합니까?

나는 그것을 나누었습니다. 내 즉각적인 느낌은 문제가 --no-binary :all: 가 여기서 의도하지 않은 중대한 결과를 초래한다는 것입니다 (실제로는 sdist가 아닌 바퀴 만 배포하는 프로젝트가있을 때 해당 플래그를 사용하는 것과 유사 함). 예를 들어 --no-binary :all: 를 사용하는 것이이 스레드에서 더 산만 해지는 것을 방지하기 위해.

--no-binary :all: 빌드 백엔드 빌드 문제를 해결하는 것이 이것만큼 중요하다고 생각하지 않습니다 . 사용자가 이미 --no-binary :all: 를 지정하고있는 경우 비교적 쉽게 --no-use-pep517 추가 할 수 있습니다.

다음과 같은 새로운 PR # 6229 :

1. pyproject.toml 에서 build-system 섹션을 PEP 517에 자동으로 옵트 인하기위한 초기 요구 사항을 만드는 @pganssle 의 임시 해결 방법을 구현합니다 ( "모든 pyproject.toml 파일"opt- 이후 릴리스)
2. setup.py 에서 인접 패키지 가져 오기를 다루는 3 개의 전용 테스트 케이스 추가

최종 사용자를 위해 작업을 다시 수행해야하고 # 6210과 같은 끔찍한 해킹이나 # 6212와 같은 새로운 설정 도구 릴리스가 필요하지 않은 최소한의 수정이므로 나머지 2 개의 PR을 종료하겠습니다.

그렇다면 setuptools.build_meta_legacy 어디에 pyproject.toml 에 명시 적으로 지정해야합니까? 그렇다면 해당 사양 없이 인접한 패키지를 가져 오는 것은 더 이상 사용되지 않으며 pip 19.X에서 제거 될 것이라는 사실과 함께 어딘가에 문서화 할 필요가 있다는 것을 강력히 제안합니다 (X가 무엇인지 동의해야 함). 프로그래밍 방식의 지원 중단 (내 생각에는 아님)이 명확하게 문서화해야하는 이유이므로 충분한 통지없이 기능을 제거했다는 비난을받지 않습니다.

편집 : 그러나 그렇지 않으면 새로운 PR 및 요약에 감사드립니다.

편집 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에서는 pip가 setuptools.build_meta_legacy를 찾을 수없는 경우 이전 코드 경로로 돌아 가야합니다.

나는 이것이 할 가치가 없다고 생각합니다. 우리는 레거시 백엔드를 얻을 것이라고 확신하는 충분히 최신 setuptools 버전을 지정할 것이며, setuptools가 향후 버전에서 해당 백엔드를 제거 할 가능성을 수용 할 필요가 없습니다. 결과적인 문제에 대해 단순히 비난하십시오 ;-))

참고 : use_pep517 = False 기본값은 # 6229로 시작된 것이지만 PEP 518 테스트에서 실패했습니다.

1. " build-system.requires is set"사례 는 상위 환경에 영향을주지 않고 요청 된 종속성을 설치할 수 있도록 빌드 격리를 사용해야합니다. 현재 코드 구조를 고려할 때이를 수행하는 가장 쉬운 방법은이 경우 use_pep517 = True 를 설정하는 것이므로이를 수행하고 테스트 케이스를 다시 통과했습니다.
2. 누락 [build-system] 표를 나타내는 pyproject.toml 단지에 설정을 저장하는 데 사용되는 [tools] 그 발생하는 있도록 테이블 use_pep517 = False 효과적으로 해결 될 원래보고 된 문제에 대해이 테스트 케이스를 예상 된 실패로 표시했습니다.
3. 그러면 "빈 [build-system] 테이블"케이스가 남게되는데, 이는 어느 방향 으로든 합리적으로 해결할 수 있다고 생각합니다. 그러나이 특별한 경우가 실제로 자주 발생하지 않을 것이라고 생각하므로 (왜 requires 또는 build-backend 를 설정하지 않고 build-system 테이블을 추가하는 데 어려움을 겪을까요? 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 필드가 이제 다르게 동작하므로 네 번째 테스트 케이스를 추가하는 것도 의미 함).

여기에 초대하지 않은 기여에 대해 죄송합니다.하지만이 모든 것이 sys.path 에 cwd를 사용하지 않도록하는 매우 정교한 방법처럼 느껴지고 궁극적으로 작동하던 작업이 중단되어 매우 혼란스럽게 느껴진다는 사실을 알아 차릴 수 없습니다. UX 관점에서.

사소한 수의 사용자와 패키지가 이로 인해 영향을받습니다. 이들 중 적어도 일부는 [build-system] 섹션이 정의되어 있고 _also_ 이전 동작에 의존하므로 해당 버전을 고정한 모든 사람에게 깨져 있습니다.

@techalchemy 예, pip 의 원래 가정은 setuptools.build_meta 가 setup.py 의 직접 호출과 동일한 방식으로 sys.path 관점에서 작동한다는 것이 었습니다. 틀린 것으로 판명되었습니다. https://github.com/pypa/setuptools/pull/1652에 정의 된 setuptools.build_meta_legacy 백엔드가 포함 된 setuptools 릴리스를 사용할 수있게되면 # 6212를 완료 할 수 있습니다. 용어 해결. 그러나 그러한 릴리스에 대한 현재 ETA가 없으므로 명시 적으로 "PEP 517 기본이 아닌 패키지에 대해 sys.path 에서 소스 디렉토리를 다시 얻기 위해 pip -전용 해상도를 계속 탐색해야합니다. ".

# 6229에서 나는 단순히 "기본적으로 PEP 517"의 채택을 연기 하라는 @pganssle 의 제안을 구현했지만, 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 는 여전히 처리되고 setup.py 가 실행될 때 소스 디렉토리는 sys.path[0] 입니다. 또한 https://discuss.python.org/t/pep-517-backend-bootstrapping/789/29?u=ncoghlan 에서 제안한 것과 매우 유사하며 @takluyver 는 https://github.com/ 에서 초안을 작성했습니다. --no-binary :all: 와 호환되는 방식으로 셀프 부트 스트랩 백엔드를 처리합니다.

AWOL RM이되어서 죄송합니다. 내가 예상하지 못했던 일이 일어났다.

나는 분명히 이것에 대한 setuptools-side 수정을 선호하지만 # 6210은 단기 수정으로서 나에게도 멋지다.

@techalchemy 및 @pradyunsg에 동의합니다. 여기서는 setuptools-side 수정이 올바른 접근 방식이라고 생각합니다. pip 내에서 빠른 수정 사항을 찾으려고 노력하는 작업에 감사하지만 _build_meta_legacy 를 사용하여 새로운 setuptools 릴리스를 신속하게 처리하는 데 그렇게 시간을 보내는 것이 더 낫지 않습니까? setuptools에에 빠른 수정을 해제에 문제가합니다 (setuptools에 사이클이 빠른 방법은 주사위의보다 릴리스)가 왜 나는 모든 명확에서 아니에요, 그래서 나는 setuptools에에 무슨 일이 일어나고 있는지보고되지 않았다.

단기 pip-side 수정은 괜찮지 만 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 , 지금은 pip <19를 사용하십시오.

@altendky 정보

pipenv 작업하는 동안 제안 된 해결 방법으로이 문제를 해결할 수 없습니다. 냉동 pip 에 18.1 (가)에서 Pipfile 보이는 것은 같은 효과가 없습니다 pipenv 최신 핍 버전을 강제로 유지합니다. 수동으로 pip를 18.1로 설정할 수 있지만 pipenv 가상 환경을 다시 만들면 Pipenv는 어떤 상황에서든 최신 pip로 업그레이드합니다.

@altendky 슬프게도, pipenv (그리고 제 생각에 시 를 위해서도) 사용자에게는 미리 정의 된 버전의 pip를 사용할 수 없습니다. 둘 다 최신 버전을 사용합니다. 그래서 지금은 많은 사람들이 고장난 파이프 라인에 갇혀 있다고 생각합니다

더 이상한 것은 일관되게 발생하지 않습니다. Appveyor 작업을 다시 실행했습니다. 첫 번째 작업은 통과했으며 두 번째 작업은 완전히 동일하지만 실패했습니다.

타임 라인에 대해 궁금한 사람이있는 경우 이번 주 말이나 다음 주 초까지 수정 사항을 준비하고 곧 pip의 후속 버그 수정 릴리스를 만들 수있을 것으로 기대합니다.

이제 build_meta:__legacy__ 백엔드에서 새로운 버전의 setuptools 버전 40.8.0 사용할 수 있습니다.

감사! 그리고 이것이 PyInstaller가 사용하도록 지시해야하는 것입니까? 그들은
변경 사항에 만족하지 않습니다 ... 내가 제시 할 수있는 모든 문서 또는 PEP
변화를 지원하기 위해 그들과 함께?

2019 년 2 월 5 일 화요일 10:24 Paul Ganssle < [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가 있습니까?

몇 시간 안에. :)

고정 된 문제를 참조하십시오.

pip 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\

이 스레드는 닫힌 후 최근 활동이 없었기 때문에 자동으로 잠겼습니다. 관련 버그에 대한 새 문제를여십시오.