이것을 백엔드의 관점에서 보면 "out of tree build"라는 개념은 실제로 의미가 없습니다. 백엔드에는 프로세스의 현재 디렉토리 형태로 "소스 트리"가 제공되고 빌드를 실행하라는 요청을 받습니다. 해당 디렉토리가 sdist에서 추출되었는지, VCS에서 체크아웃되었는지, 또는 다른 곳에서 복사되었는지 알 방법이 없습니다. 할 수 있는 것은 빌드뿐이며 빌드에 필요한 것이 없으면 실패를 보고합니다.

그래서 가능한 솔루션을 거의 죽입니다. (3) IMO - 백엔드에는 내부 빌드 가 무엇인지에 대한 개념이 없으므로 그러한 빌드가 안전한지 여부를 말할 수 없습니다 ¹ .

(2)와 관련하여 나는 일반적으로 이와 같은 추가 옵션에 반대합니다. 우리가 최선의 방법이 무엇인지 안다면 그것을 해야 하고, 그렇지 않다면 문제를 사용자에게 전달하는 것은 특별히 친숙한 옵션이 아닙니다. 여기서의 문제는 올바른 선택이 무엇인지 아는 사용자가 거의 없을 정도로 미묘하므로 사람들이 2가지 옵션을 시도하고 맹목적으로 "효과가 있는 것"을 사용하는 것을 볼 수 있습니다. 또한 지원 의미는 중요합니다. 옵션을 제공한다는 것은 적어도 일부 경우에는 빌드 결과가 다를 것으로 예상한다는 것을 분명히 의미하므로 차이점이 예상대로인지 테스트하려면 어떻게 해야 합니까? 인플레이스 빌드 플래그가 필요한 시기에 대해 사용자를 교육할 책임이 있습니까(문서를 통해 또는 무엇을 사용해야 할지 모르는 사용자가 제기한 문제의 결과로)?

그렇긴 하지만, 저는 단순히 제자리에 구축하는 pip에 반대하지 않습니다. 우리가 하지 않는 이유는 이전 빌드에서 남겨진 아티팩트가 후속 빌드에서 사용되었지만 다른 옵션으로 빌드된 경우가 있기 때문이라고 생각합니다(예: 디버그 모드에서 빌드된 개체 파일이 릴리스 빌드에 링크됨 같은 나무에서 수행). 그러나 백엔드는 이와 같은 문제가 발생하지 않도록 해야 하며, 발생하는 경우 백엔드 버그이며 이에 대해 방어하기 위해 노력하지 않는 것이 합리적입니다. 그러나 이러한 입장을 취하는 것이 특히 사용자 친화적인지 확실하지 않습니다. 이는 증분 빌드라는 주제로 PEP 517 토론 중에 제기되었으며 당시에 연기될 정도로 논란이 많았습니다.

내 선호도는 sdist를 구축한 다음 지금부터 오랫동안(선택 사항 1) 휠을 구축하는 것이었습니다. 나는 pip 구축에 동의하지만 (위에서 언급했듯이 백엔드에서 알려주는 것을 기대할 수 없다는 점을 감안할 때 그렇게 하는 것이 안전하다는 데 동의할 수 있다면) 커뮤니티가 필요하다고 생각합니다. 더 넓은 의미(백엔드, pip/프론트엔드 및 최종 사용자에 대한)를 해결하기 위한 토론.

¹ 물론 "out of tree" 빌드와 대조적으로 "in-place" 소스 트리를 구성하는 요소를 정의 하기 위해 PEP 517을 업데이트하는 것이 가능하지만, 나는 그것이 고정시키기 매우 어려운 개념이 될 것이라고 생각합니다.

솔루션 4.(pip를 항상 제자리에 빌드하도록 변경) 및 5.(pip를 외부 빌드 옵션과 함께 기본적으로 제자리에 빌드하도록 변경) 솔루션을 추가했습니다.

나는 다음과 같은 이유로 sdist(솔루션 1.)를 통한 건물에 대해 엇갈린 감정을 가지고 있습니다.

1. 일부 프로젝트에는 sdist-to-wheel 경로가 손상될 수 있습니다. sdists에서 빌드가 작동하는지 확인하는 가치를 확인하는 동안 기본적으로 지금 수행하면 많은 최종 사용자 빌드가 확실히 중단됩니다.
2. 큰 sdist가 있는 프로젝트와 추가 하위 프로세스 호출로 인해 여전히 성능에 영향을 미칩니다.
3. 개인적으로 프로젝트에서 빌드된 아티팩트를 게시하고 소스 릴리스에 대해 선호하는 코드 호스팅 플랫폼(예: VCS 체크아웃의 존재에 의존하는 백엔드를 참조하는 것이 일반적이므로 건물은 작동하는 sdist를 생성하기 위해 농구대를 뛰어 넘을 필요가 있습니다. 그리고 PEP 517은 백엔드가 UnsupportedOperation 대해 build_sdist UnsupportedOperation 를 올릴 수 있도록 구체적으로 허용합니다.

토론에 대한 이

나는 솔루션 3의 경로에 동의합니다. 명백하지 않습니다.

또한 가능하면 추가 옵션을 피해야 한다는 데 동의합니다.

또한 링크된 토론 스레드에서 인플레이스 빌드에 찬성하는 목소리가 있었지만 실제로 해당 접근 방식을 탐색하려면 해당 특정 주제에 대한 집중적인 커뮤니티 토론이 필요합니다.

• 제자리에 sdist를 만들고 임시 위치에 sdist의 압축을 푼 다음 그 위치에서 빌드합니다.

좋은 접근 방식이라고 생각합니다.

IMO 가능성은 로컬 디렉토리와 관련된 대부분의 pip install 실행에서 단일 패키지에 대해 실행됩니다. 가장 일반적으로 pip install . 상상합니다. 이는 패키지 개발 워크플로의 일부로 수행될 가능성이 높습니다.

이 행동은 다음과 같아야 한다고 생각합니다.

• 백엔드가 sdist를 생성할 수 없으면 local-dir -> wheel(in-place)을 수행합니다.
  
  
  
  • 이 경우 local-dir -> wheel이 멱등성 작업인지 확인하는 책임은 백엔드에 매우 크다고 생각합니다.
  
  
• 백엔드가 sdist를 생성할 수 있는 경우 local-dir -> sdist -> unpacked-sdist -> wheel을 수행합니다.

local-dir -> sdist -> wheel을 수행하면 추가 호출 세트가 있습니다. 그러나 특히 개발 중에 생성된 sdist가 정상인지 확인하는 것이 합리적이라고 생각합니다. tox는 이미 워크플로의 일부로 이 작업을 수행하고 있으며 여기에서 setuptools의 그다지 친숙하지 않은 인터페이스를 다루기 위해 체크 매니페스트를 사용합니다.

전반적으로, 로컬 디렉토리가 주어졌을 때 sdist를 구축하는 비용은 프로젝트에서 그러한 오류를 방지하는 데 가치가 있다고 생각합니다. 특히 로컬 디렉토리에서 설치하는 사람들이 프로젝트 개발자일 가능성이 높기 때문입니다.

롤아웃과 관련하여 #6536이 어떻게 나오는지 지켜보고 싶습니다. 우리는 이전할 수 있는 몇 가지를 확실히 배울 것입니다.

나는 sdist를 빌드/해제하고 설치하는 것보다 sdist를 빌드/설치하는 것을 선호합니다(따라서 setup.py install 또는 setup.py bdist_wheel 또는 PEP 517 백엔드에서 build_wheel 호출) 그것을 통해서. 내 구체적인 이유는 다음과 같습니다.

1. 즉시 사용 가능한 가장 많은 수의 사용자를 지원합니다.
   
   
   
   1. pip가 local-dir -> installed(휠 빌드 인플레이스 또는 setup.py install 를 통해)를 수행한다고 가정합니다. local-dir -> 설치를 원하는 사용자는 pip install local-dir 실행할 수 있습니다. local-dir -> sdist -> 설치에서 이동하려는 사용자는 자유롭게 sdist를 생성한 다음 pip install ./path/to/sdist 를 실행할 수 있습니다. sdist를 구축할 수 있는 대체 도구가 많이 있으며, 이는 사용자가 PyPI에 업로드하는 배포판을 손으로 제작하지 않는 한 사용자가 이미 가지고 있을 가능성이 더 큰 것입니다.
   
   
   2. 이제 pip가 local-dir -> sdist -> 설치를 수행한다고 가정합니다. local-dir -> 설치로 이동하려는 사용자에게는 pip와 관련된 옵션이 없습니다. local-dir -> sdist -> installed 에서 이동하려는 사용자는 pip install local-dir 실행할 수 있습니다. 옵션이 없는 사용자는 pip에게 동작을 제어하는 ​​옵션을 요청하거나 그렇지 않으면 필요하지 않은 다른 도구를 찾아야 합니다.
   
   
2. local-dir -> sdist -> installed를 구현하면 아마도 VCS 기반 요구 사항에 대해서도 수행할 것입니까? 그렇다면 더 많은 작업이 필요합니다. 그렇지 않은 경우 사용자가 기억해야 하거나 지원을 제공할 때 설치가 처리되는 방식의 코드 및 편차를 통한 추가 경로입니다.
3. 구현해야 할 최소 작업량. local-dir -> installed( here , here , here )를 구현하기 위해 변경할 곳이 세 곳 있습니다. local-dir -> sdist -> 설치의 경우 #6607이 완료될 때까지 이것을 구현하고 싶지 않습니다. 그렇지 않으면 아티팩트 다운로드/해시 검사와 유사한 코드 기반의 많은 위치에서 끝날 것이라고 생각합니다.
4. IMO, 기존 테스트는 local-dir -> 설치된 코드 경로를 커버하기에 충분하기 때문에 테스트할 작업이 가장 적습니다. local-dir -> sdist -> 설치된 경로의 경우 실제로 sdist를 빌드하고 있고 휠을 직접 빌드하는 데 폴백이 작동하는지 확인하고 싶습니다.
5. 최소 작업량(계산상). 다른 곳에서 언급했듯이 local-dir -> sdist -> installed는 추가 하위 프로세스 호출입니다(해당 하위 프로세스가 작동 중임). 또한 휠 빌드를 수행하기 전에 pip가 sdist(hello 바이러스 스캐너 및 느린 디스크)의 압축을 풀어야 함을 의미합니다.

접근 방식에 관계없이 제자리에서 작업을 수행할 때 볼 수 있는 유일한 문제는 setuptools 빌드의 경우(이것이 레거시 및 PEP 517에 적용된다고 생각합니다) 프로젝트 디렉토리에 .egg-info 로 끝날 것이라는 것입니다. pip가 해당 디렉토리에서 python -m pip 로 호출될 때 "설치된 패키지"로. 이것은 #4575에 의해 수정될 것이며, 이는 아마도 어떤 체계에 대해 설치된 패키지에 대한 쿼리에 현재 디렉토리를 포함하지 않을 것입니다.

sdist 빌드를 건너뛰고 직접 트리 내 빌드를 수행하는 아이디어가 pip가 기본적으로 취하고 local-dir -> sdist -> wheel을 시도하지 않는 더 나은 접근 방식이라는 데 동의하게 되었습니다.

Fedora에서 Python RPM 패키지를 빌드할 때 우리는 공룡이며 씬을 수행하는 표준 방법은 python setup.py build 입니다. PEP 517에서는 pip wheel 대신 사용하는 "임시" 방법을 추가했습니다. 그러나 확장 모듈의 경우 pip가 빌드에 사용하는 "소스를 tmp로 이동하고 거기에서 빌드" 접근 방식에 문제가 있습니다.

빌드 기계는 일부 컴파일러 플래그를 주입하므로 빌드 아티팩트(이 경우 .so 확장 모듈)에 소스에 대한 메타데이터가 포함됩니다. 나중에 빌드 아티팩트를 탐색하고 이 정보를 추출하고 소스를 /usr/src/debug 에 복사하여 특수 *-debugsource RPM을 통해 설치하는 쉘 스크립트가 있습니다. mahcinery는 모든 것이 작업 트리 내에서 구축되기를 기대하며 외부에서 구축할 때는 실제로 제대로 작동하지 않습니다. 다음은 우리 측에서 문제를 완화하기 위해 (함께) 할 수 있는 일입니다.

1. RPM 스크립트가 예상하는 위치에 $TMPDIR 환경 변수를 설정합니다(예: export TMPDIR=%{_builddir}/.tmp (및 생성)).
2. --no-clean 옵션과 함께 pip wheel 사용하여 복사한 소스를 $TMPDIR
3. 쉘 쿵푸를 실행하여 "내 소스가 무엇입니까" 정보를 올바른 위치에 다시 작성하십시오. find %{buildroot} -iname '*.so' -print0 | xargs --no-run-if-empty -0 -n1 /usr/lib/rpm/debugedit -b "%{_builddir}/.tmp/pip-req-build-"* -d "$PWD"
4. (선택 사항: $TMPDIR 수동으로 정리합니다.)

너무 많은 구현 세부 정보에 의존하기 때문에 세 번째 단계는 특히 마음에 들지 않습니다.

• /usr/lib/rpm/debugedit API 및 위치(및 존재)
• pip-req-build 이름
• pip가 소스를 빌드하는 메커니즘

pip가 항상 제자리에 구축되거나 이에 대한 명령줄 스위치가 있으면 문제가 사라집니다.

다운스트림 보고서: https://bugzilla.redhat.com/show_bug.cgi?id=1806625

sdist 빌드를 건너뛰고 직접 트리 내 빌드를 수행하는 아이디어가 pip가 기본적으로 취하고 local-dir -> sdist -> wheel을 시도하지 않는 더 나은 접근 방식이라는 데 동의하게 되었습니다.

나는 또한 제자리에서 바퀴를 만드는 아이디어를 받아들이는 경향이 있습니다. 남은 예약은 다음과 같습니다.

1. 우리는 "올바르게" 작동하는 백엔드에 의존할 것입니다. 예를 들어 이전 빌드의 남은 데이터를 기반으로 다른 결과를 제공하지 않는 등의 작업입니다. 그런 가정을 하는 것은 괜찮지만 사람들이 "pip built my wheel wrong"라고 말하기 시작하면 지원 비용이 걱정되고 디버그만 하면 백엔드 문제라는 것을 알 수 있습니다.
2. 우리가 어떤 접근 방식을 취하
3. 위의 결과로 우리는 현재 "복사 및 빌드" 접근 방식에 의존하는 프로젝트가 없는지 확인해야 합니다.

... 그리고 물론 누군가가 이 변경을 구현하는 PR을 작성해야 할 것입니다(테스트, 문서 등 - 일반적인 것들 포함) 그렇지 않으면 우리가 하는 모든 것은 이야기하는 것입니다 🙂

우리는 "올바르게" 작동하는 백엔드에 의존할 것입니다. 예를 들어 이전 빌드의 남은 데이터를 기반으로 다른 결과를 제공하지 않는 등의 작업입니다. 그런 가정을 하는 것은 괜찮지만 사람들이 "pip built my wheel wrong"라고 말하기 시작하면 지원 비용이 걱정되고 디버그만 하면 백엔드 문제라는 것을 알 수 있습니다.

"깨끗한" 후크를 포함하도록 PEP 517 인터페이스를 확장하는 것이 합리적입니까? 우리는 아마도 다른 노력(예: 편집 가능한 설치 구현, PEP 517 프로젝트를 빌드하는 패키지 개발 도구 빌드)을 가능하게 하는 어떤 지점으로 그것을 원할 것입니다. pip는 트리 내 빌드를 수행하기 전에 남은 쓰레기가 없는지 확인하기 위해 여기에서 호출할 수 있습니다.

"깨끗한" 후크를 포함하도록 PEP 517 인터페이스를 확장하는 것이 합리적입니까?

아마도? 그러나 pip가 자동으로 clean 호출하면 증분 빌드 등을 수행하기 위해 그렇게 하지 않으려 는 사람이 있을 수 있습니다. 그런 다음 다른 옵션으로 끝납니다.

제 성향은 "인플레이스 빌드가 올바르게 작동하도록 하는 것이 백엔드의 책임이라고 가정할 수 있어야 합니다"라는 제 입장을 고수하는 것입니다. 그것이 지지할 수 없는 것으로 판명되더라도, 작동하지 않는 이유에 대한 구체적인 예를 얻는 것은 단순히 추측하기보다는 문제에 대해 무엇을 해야 하는지 더 잘 이해하는 데 도움이 될 것입니다.

1. 우리는 "올바르게" 작동하는 백엔드에 의존할 것입니다. 예를 들어 이전 빌드의 남은 데이터를 기반으로 다른 결과를 제공하지 않는 등의 작업입니다.

이것을 명시적인 요구 사항으로 만들기 위해 PEP-517을 확장하고 싶습니다.

이것을 명시적인 요구 사항으로 만들기 위해 PEP-517을 확장하고 싶습니다.

이미 다음과 같이 말합니다.

백엔드는 캐시 위치 또는 임시 디렉토리에 중간 아티팩트를 저장할 수 있습니다. 캐시의 존재 여부는 빌드의 최종 결과에 중요한 차이를 만들지 않아야 합니다.

백엔드가 의도적으로 이 요구 사항을 위반할 가능성은 그리 많지 않습니다. 사용자가 자연스럽게 문제를 pip 문제로 보고하고 백엔드 프로젝트로 리디렉션되므로 약간의 추가 오버헤드가 발생하기 때문입니다.

Fedora에 대한 해결 방법을 찾으려고 할 때 https://github.com/pypa/pip/issues/7872 가 발생했습니다.

#7731 및 친구들과 함께 ".egg-info in cwd" 문제를 해결했기 때문에 제자리에 빌드할 때 걱정할 일이 한 가지 줄어듭니다.

그래서 옵션 4(항상 제자리에 빌드)가 #7882에서 구현되었습니다.

우리는 이제 (#7951에 따라) pip, pip 20.1b1의 베타 릴리스를 게시했습니다. 이 릴리스에는 이 문제에 대한 솔루션을 구현한 #7882가 포함되어 있습니다.

이번 호의 참가자들이 베타를 테스트하고 새로운 버그를 확인함으로써 우리를 도울 수 있기를 바랍니다. 화요일에 주요 20.1이 릴리스되기 전에 잠재적인 문제를 식별하고 해결하고자 합니다.

또한 "예, 이제 더 잘 작동합니다!"라는 긍정적인 피드백을 환영합니다. 또한 문제 추적기는 일반적으로 "문제"로 가득 차 있기 때문입니다. :)

우리는 Fedora에서 그것을 완전히 테스트할 계획이지만(당신의 코멘트 전에 이미 계획했습니다), 화요일 마감일은 아마도 현실적이지 않을 것입니다.

@hroncok Fedora가 언제 이러한 변경 사항을 테스트할 수 있는지 알 수 있습니까?

월요일에 어떻게든 해볼 수 있도록 최선을 다하겠지만 어떤 약속도 할 수 없습니다.

실제로 20.1b1은 문제를 해결합니다.

https://mail.python.org/archives/list/[email protected]/message/5EAUIYYIRKXEHTAG5GQ7EJHSXGZIW2F7/의 보다 일반적인 20.1b1 피드백

만세! @hroncok 베타를 사용해 주셔서 감사합니다! 매우 감사! ^>^

빌드 인 플레이스의 한 가지 결과: 여러 버전의 Python을 병렬로(manylinux 도커 컨테이너 내부에서) 휠을 빌드했습니다. 내부 빌드를 사용하면 병렬 빌드가 다른 버전 충돌로 작동하지 않습니다. 트리 외부 빌드에서는 각 버전이 별도의 트리를 만들고 문제가 없었습니다.

@manthey 토론이 #

그래서 이제 10일이 넘었습니다. 변경 사항에 대해 몇 가지 문제가 제기되었습니다(모두 예상 - #8165, #8168, #8196). 변화가 도움이 된다고 명시적으로 언급하는 사람들도 있었습니다.

• 성능 문제 외에도 이전 동작(임시 디렉터리로 복사)에는 호출자만 가지고 있는 컨텍스트 지식 없이는 pip로 수정할 수 없는 정확성 문제(위에 링크됨)가 있었습니다. 이상한 상황에 대처하기 위한 반창고 - 트리의 tmpdir, 소켓 등).
• 이전 동작을 활성화하는 옵션에는 여전히 정확성 및 성능 문제가 있습니다.
• 올바른 솔루션에는 오늘날 완전히 존재하지 않는 빌드 디렉토리를 제어하기 위한 빌드 백엔드 지원이 포함됩니다(예를 들어 setuptools bdist_wheel 에는 --bdist-dir 가 있지만 여전히 .egg-info 를 씁니다. 장소, https://github.com/pypa/setuptools/issues/1816, https://github.com/pypa/setuptools/issues/1825 참조). 이제 pip가 올바르게 작동하므로 논의가 전환되어 예를 들어 setuptools가 소스 디렉토리를 건드리지 않고 빌드를 수행하는 옵션을 발전시킨 다음 해당 옵션을 제어하기 위해 PEP 517 변경이 필요한지 여부를 확인할 수 있습니다.
• 그 동안 보고된 문제는 호출자가 비교적 쉽게 해결할 수 있습니다(예: 임시 디렉토리에 자신을 복사하거나 컨텍스트에 대한 완전한 지식으로 올바르게 수행할 수 있는 임시 tarball을 생성).
• 마지막으로, 우리가 가지고 있는 데이터로 확실히 말하기는 어렵지만, 내 직관은 이 변화가 상처를 주는 것보다 더 많은 사람들에게 도움이 된다는 것입니다.

그래서 저는 브레이킹 체인지를 싫어하는데 이번 작업은 가볍게 한 것이 아니라 이런 이유로 개인적으로 유지하는 편입니다.

나는 새로운 행동이 pip가 "올바르게", 확실히 다르게 행동한다는 점에 동의하지 않으며, 어떤 경우에는 분명히 다르게 깨져 있으며, 그와 같이 틀을 잡는 것이 올바르지 않다고 생각합니다. 이는 다른 세트에 대해 깨진 사용자 세트에 대한 절충안을 나타냅니다. 두 경우 모두 여기에 수행할 수 있는 해결 방법이 있습니다.

나는 이 변경 사항을 병합하지 않았고 발생하는 것을 놓쳤거나 그것에 대해 논쟁했을 것입니다. ). 즉, 되돌리기가 여기에서 올바른 것인지 잘 모르겠습니다. 행동이 많이 뒤바뀌는 경우 사용자에게 더욱 혼란을 줄 수 있습니다. 되돌리려면 빨리 해야 하고 그렇지 않으면 현재 동작이 더 좋거나 나쁠 것입니다.

pip wheel <localdir> 및 pip install <localdir> cd <localdir> ; setup.py bdist_wheel 에 어떤 경우에는 https://github.com/pypa/pip/issues/7555#issuecomment -595180864 또는 #6276 또는 일반 오류가 있는 다른 버전입니다. 나는 pip 20.1이 그런 나쁜 바퀴/설치를 생성한다고 생각하지 않으므로 그런 의미에서 나는 그것이 실제로 더 정확하다고 믿습니다.

물론 변경 사항으로 인해 일부 워크플로가 중단될 수 있으며 피드백이 있는 지금 절충안을 다시 평가하고 원래대로 되돌리거나 확인해야 한다는 것을 알고 있었습니다.

그리고 여전히 setup.py sdist && pip install dist/*.tar.gz 와 다른 휠을 생성할 수 있습니다.

내 제안은 PR을 되돌리고 먼저 sdist를 섞은 다음 결과 sdist에서 휠을 빌드하여 수정 사항을 구현하는 것입니다.

이것은 프로젝트가 sdist를 올바르게 구축할 수 없는 경우를 제외하고 모든 정확성 문제를 해결해야 합니다. 즉, 해결해야 할 중요한 사용 사례가 아닌 IMO입니다.

거기에서 트레이드 오프는 더 느려질 것이라는 것입니다. 그러나 일단 구현하고 나면 속도 향상을 가능하게 하는 선택적 API를 추가하기 위해 PEP 517 인터페이스를 더욱 세분화할 수 있습니다. 이 변화만큼 빠르지는 않겠지만 확실히 더 가까이 갈 수는 있습니다.

이러한 변경은 사용자가 만족하지 못할 성능 회귀를 도입하지 않고 정확성에 대한 바늘을 더 이상 밀어 넣는 것을 사실상 불가능하게 만듭니다. 그러나 이를 수정하고 성능을 향상시키면 양 당사자를 모두 만족시키는 행복한 중간 지점에 도달할 수 있습니다.

옛 속담이 말하듯이, 먼저 올바르게 만들고, 그 다음에는 빠르게 하십시오. 나는 이 PR로 우리가 그것을 빨리 만들고 그것을 수정하는 우리의 능력을 잠그는 것이 두렵습니다.

나는 여전히 sdists를 검증하는 것이 바람직하지만 pip 설치 시간에는 그렇지 않다는 데 동의합니다. 아마도 이것은 미래의 sdist 빌더 도구 또는 pip 빌드 명령의 기능일 것입니다.

또한 setup.py sdist 는 로컬 디렉토리에 .egg-info를 생성하므로 읽기 전용 소스 디렉토리 또는 동시 빌드에 대해 보고된 문제가 그대로 유지됩니다.

pip 설치 시간에 발생하지 않으면 다른 사람의 pip 설치 시간까지 기능적으로 발생하지 않습니다. 건너뛴다는 것은 프로젝트가 VCS에서 설치된 패키지로 계속 이동할 수 있는 여러 경로가 있다는 것을 의미하며 모든 경로는 차이가 날 수 있는 또 다른 기회입니다. 이것은 새로운 것이 아닙니다. 기본적으로 설치 경로를 변경하는 모든 옵션은 가장 엄격한 프로젝트의 경우에도 디스크에 다른 바이트 세트로 끝납니다. 미묘한 차이는 항상 존재하며 그러한 차이가 의미가 없기를 바랄 뿐입니다. 또는 구조적으로 처음부터 차이를 가질 수 없도록 하여 이러한 차이를 제거하기 위해 할 수 있는 일을 할 수 있습니다.

일부 성능 문제는 sdist를 통해 빌드할 때 실제로 다시 나타날 수 있지만 pip < 20.1에서 있었던 것보다 훨씬 낮을 것입니다. 실제로 대부분은 .git 또는 venv , 또는 sdist에 없는 기타 관련 없는 방대한 내용을 복사하는 데 사용되었습니다.

pip 결국에는 어떤 결과를 가져오든, 둘 중 하나가 모든 사람을 만족시킬 수 없을 것 같기 때문에 다른 옵션을 만들 수 있습니까? 현재 접근 방식이 유지되어야 하는 경우(어떤 것이 기본값이어야 하는지에 대한 의견이 없음) 사용자가 sdist를 만들고 설치할 수 있는 최종 결과 폴백을 제공할 수 있어야 한다고 생각합니다. 거기에서 패키지.

또한 setup.py sdist 는 로컬 디렉토리에 .egg-info 를 생성하므로 읽기 전용 소스 디렉토리 또는 동시 빌드에 대해 보고된 문제가 그대로 유지됩니다.

나는 (적어도 빠른 테스트가 나와 동의함) setuptools ( distutils 아님)만 수행하고 이 동작은 다른 곳에서 dir을 생성하도록 구성할 수 있다고 생각합니다. 다른 백엔드와 마찬가지로 깨끗한 sdist 생성을 수행하도록 권장할 수 있어야 합니다.

FWIW, 저는 sdist-generation --egg-info 디렉토리를 작업 디렉토리에 덤프할 필요가 없다고 생각합니다. generate-sdist-unpack-it-build-wheel 접근 방식을 사용하면 generate_metadata 처럼 임시 디렉토리에 덤프하십시오.

@pradyunsg 는 setuptools의 변경이 필요하지 않습니까? 내가 마지막으로 확인한 sdist 명령에는 .egg-info 기본 위치를 지정하는 옵션이 없었습니다. 반대로 --egg-base 옵션이 있는 egg_info 에는 #7978에서.

물론! setuptools에서 잘못된 파일을 보고 있었습니다. 🙈 정정합니다.

이 공간의 모든 것이 왜 그렇게 복잡합니까? :(

$  ls -la
total 8
drwxr-xr-x  3 dstufft  staff   96 May  6 14:26 .
drwxr-xr-x  9 dstufft  staff  288 Apr 28 15:46 ..
-rw-r--r--  1 dstufft  staff   85 Apr 23 16:23 setup.py

$  py setup.py egg_info --egg-base /tmp/foo sdist
/Users/dstufft/.pyenv/versions/3.8.2/lib/python3.8/site-packages/setuptools/dist.py:471: UserWarning: Normalizing '2020.04.23.3' to '2020.4.23.3'
  warnings.warn(
running egg_info
creating /tmp/foo/dstufft.testpkg.egg-info
writing /tmp/foo/dstufft.testpkg.egg-info/PKG-INFO
writing dependency_links to /tmp/foo/dstufft.testpkg.egg-info/dependency_links.txt
writing top-level names to /tmp/foo/dstufft.testpkg.egg-info/top_level.txt
writing manifest file '/tmp/foo/dstufft.testpkg.egg-info/SOURCES.txt'
reading manifest file '/tmp/foo/dstufft.testpkg.egg-info/SOURCES.txt'
writing manifest file '/tmp/foo/dstufft.testpkg.egg-info/SOURCES.txt'
running sdist
warning: sdist: standard file not found: should have one of README, README.rst, README.txt, README.md

running check
warning: Check: missing required meta-data: url

warning: Check: missing meta-data: either (author and author_email) or (maintainer and maintainer_email) must be supplied

creating dstufft.testpkg-2020.4.23.3
copying files to dstufft.testpkg-2020.4.23.3...
copying setup.py -> dstufft.testpkg-2020.4.23.3
Writing dstufft.testpkg-2020.4.23.3/setup.cfg
creating dist
Creating tar archive
removing 'dstufft.testpkg-2020.4.23.3' (and everything under it)

$ ls -la                                        
total 8
drwxr-xr-x  4 dstufft  staff  128 May  6 14:28 .
drwxr-xr-x  9 dstufft  staff  288 Apr 28 15:46 ..
drwxr-xr-x  3 dstufft  staff   96 May  6 14:28 dist
-rw-r--r--  1 dstufft  staff   85 Apr 23 16:23 setup.py

https://github.com/pypa/pip/issues/8165#issuecomment -624669107 이것은 꽤 쇼 중지 버그처럼 느껴지며 틀림없이 우리 버그가 아니지만 PEP 517 토론 중에 발생할 것이라고 주장한 버그 유형 중 하나입니다. 기본적으로 제자리 빌드를 수행합니다.

bdist_wheel 는 과거에 빌드 디렉토리를 자동으로 정리하도록 요청받았습니다. 그 기능이 들어가야 합니다. 다른 distutils 빌드는 깨끗합니까?

SCons라면 관심 있는 파일을 기억하고 파일 시스템에 있는 경우에도 휠에서 build/ 디렉토리의 추가 파일을 생략합니다.

위의 문제가 manylinux 에만 영향을 미치는 것은 아니라고 생각합니다. 빌드 디렉토리가 ABI를 캡처하기에 충분히 구체적이지 않을 때마다 발생해야 합니다(setuptools의 경우 플랫폼으로 표시되고 python 버전은 빌드 디렉토리의 ABI 태그에 캡처된 모든 것입니다). 나는 이것이 현재 인터프리터에서도 ABI를 넘어 확장된다고 생각합니다. 예를 들어 뭔가가 NumPy에 대해 링크되는 경우, ABI가 최신 버전에서는 작동하지만 이전 NumPy에서는 작동하지 않는다고 생각합니다. 빌드 디렉토리 이름에서 인코딩하지 않는 한 이것은 효과도 그런 식으로 사용합니다.

빌드 디렉토리를 자동으로 청소한다고 해서 문제가 해결되는 것은 아닙니다. (예를 들어 두 개의 pip wheel 호출을 병렬로 실행하면 여전히 문제가 발생할 수 있음) 이러한 방식으로(적어도 PEP 517 토론 중에) 증분 빌드에 대한 호출 사이에 캐싱을 허용하여 더 많은 성능을 제공할 수 있었습니다. IOW 현재 동작은 실행 사이에 빌드 아티팩트를 재사용하여 일부 하위 집합이 원했던 것입니다. 가장 일반적인 빌드 백엔드가 매우 잘못되었습니다. 패키지 사용자 정의).

물론 기본 setuptools 명령에 대한 충분한 플래그가 있으면 이 문제를 해결할 수 있습니다( py setup.py egg_info --egg-base /tmp/foo build --build-base /tmp/foo/build-base bdist_wheel --bdist-dir /tmp/foo/bdist 와 같은 것이 가능합니다).

문제는 추가 파일이 아니라 휠과 호환되는 예상 ABI가 변경되었고 .so 가 다시 빌드되지 않았다는 것입니다. SCons가 pymalloc으로 빌드된 Python에 하나의 빌드 디렉토리가 필요하고 Python이 다른 빌드 디렉토리( .so 링크될 수 있는 NumPy 버전 포함)가 필요하다는 것을 알만큼 똑똑하다면 영향을 받지 않습니다. 이전에 빌드된 아티팩트를 다른 ABI로 재사용하는 경우 영향을 받습니다.

enscons를 테스트하려고 시도했지만 오류 없이 rsalette를 빌드할 수 없었습니다.

scikit-build를 테스트하여 증분 빌드를 처리하는 방법을 확인하려고 시도했는데 무엇을 하든 두 번째 빌드에서 자체적으로 토했고 매번 _skbuild 디렉토리를 수동으로 삭제해야 했습니다. 오류 없이 실행합니다.

멋있는. 유감스럽게도 enscons는 업데이트되었지만 rsalette는 업데이트하지 않았습니다.

2020년 5월 6일 수요일 오후 4시 18분에 Donald Stufft는 다음과 같이 썼습니다.

enscons를 테스트하려고 시도했지만 오류 없이 rsalette를 빌드할 수 없었습니다.

scikit-build를 테스트하여 증분 빌드를 처리하는 방법을 확인하려고 시도했는데 무엇을 하든 두 번째 빌드에서 자체적으로 토했고 매번 _skbuild 디렉토리를 수동으로 삭제해야 했습니다. 오류 없이 실행합니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/pypa/pip/issues/7555#issuecomment-624867490 에서 확인하거나 https://github.com/notifications/unsubscribe-auth/AABSZERIEDAPUIXCPAKBBUDRQHAXRANCNFSM4KCV5MHQ 구독을 취소

유감스럽게도 enscons는 업데이트되었지만 rsalette는 업데이트하지 않았습니다.

업데이트된 enscons를 사용하는 좋은 C ext가 있습니까? rsalette가 목록의 첫 번째이고 디버깅하고 싶지 않았기 때문에 방금 rsalette를 선택했습니다. 다른 것으로 시도하게 되어 기쁩니다.

rsalette 의 유일한 문제는 SConstruct의 Environment에 ROOT_IS_PURELIB 를 전달해서는 안 된다는 것입니다. C 확장자가 없습니다. cryptacular 괜찮아 보입니다.

#8165(코멘트)

이것으로, 나는 우리가 이 변경 사항을 되돌려야 한다는 데 동의한다고 생각합니다.

새로운 문제가 예상보다 훨씬 크다고 생각합니다. 빠른 20.1.1로 되돌린 다음 트리 내 및 트리 외 빌드의 문제를 모두 해결하는 방법에 대해 더 긴 토론을 할 수 있습니까?

나는 또한 되돌리기에 투표하고 이에 대한 해결책으로 https://discuss.python.org/t/proposal-adding-a-persistent-cache-directory-to-pep-517-hooks/2303/15 를 추구합니다. 백엔드가 제자리에 빌드되지 않도록 허용하므로 이러한 문제가 노출되지 않습니다. 거기에 있는 제안에 동의한다면 해당 스레드에도 참여하십시오.

저에게도 그럴싸해 보입니다. 인트리(또는 sdist에서 빌드) 접근 방식에는 몇 가지 매우 중요한 이점이 있다고 생각합니다. 중요한.

여기에 UI가 무엇인지 확실하지 않습니다(기본적으로 어떤 접근 방식을 사용해야 하나요? 어떤 종류의 옵션을 선택해야 하나요?). 하지만 현재 문제를 해결하는 동안 결정을 내리는 것보다 결정하는 데 시간이 조금 더 소요되어야 한다고 생각합니다. .

알았어! 나는 일반적인 합의가 되돌리고 재평가하는 것이라고 생각합니다. 이에 대해 PR을 제출하겠습니다. :)

거기에 있는 제안에 동의한다면 해당 스레드에도 참여하십시오.

해주세요 - 제가 댓글을 달았지만 의미있는 제안을 하기에는 제가 충분히 알지 못하기 때문에 경험이 있으신 분들의 의견이 소중할 것입니다.

https://github.com/pypa/pip/issues/8165#issuecomment -625401463에 몇 개의 큰 텍스트를 삭제했습니다. 오늘은 이만 물러가겠습니다... 마지막에 개인노트를 쓰다보니 좀 답답하네요. #5599에서 끝내고 부정적인 사용자 댓글을 읽는 것은 확실히 도움이 되지 않았습니다.

안녕하세요 여러분, 저는 이것에 대해 좀 더 생각했습니다. 여기에 이 ​​문제에 대한 저의 현재 관점이 있습니다.

1. 제자리에 sdist를 만들고 임시 위치에 sdist의 압축을 푼 다음 그 위치에서 빌드합니다.

나는 여전히 pip install / pip wheel이 나쁜 sdists를 잡으려고 시도하고 잡을 수있는 올바른 장소가 아니라고 믿습니다. 애초에 나쁜 sdist를 만들지 않는 것이 백 엔드 책임이 아니어야 합니까? 또한 sdist를 통한 무조건 빌드는 빌드만큼 파괴적이라고 생각합니다.

1. 제자리에 빌드하려면 pip 옵션을 추가하십시오.

솔루션 4가 성공하지 못했기 때문에 단기적으로 가장 좋아하는 것입니다. pip 20.1.1에 추가하는 것이 시기상조입니까?

1. 내부 빌드에 대해 "안전한" 경우 백엔드가 프런트엔드와 통신할 수 있도록 하는 일종의 메커니즘으로 PEP 517을 업데이트합니다.

이 핍을 사용하면 여전히 깨지고 고칠 수 없는 카피트리로 되돌아가야 하므로 나는 이것을 선호하지 않습니다.

1. 항상 제자리에 빌드하도록 pip를 변경합니다.

따라서 이것은 너무 파괴적인 것으로 간주되어 20.1.1에서 되돌릴 것입니다.

1. 트리 외부에서 빌드하는 옵션을 사용하여 기본적으로 제자리에 빌드하도록 pip를 변경합니다.

이것이 장기적인 목표가 될 수 있으며, 캐시 디렉토리 개념과 트리 외부 혼합을 구축하는 옵션이 될 수 있습니까?

저는 CLI 옵션, 특히 이와 같은 옵션을 좋아하지 않습니다. 내 로컬 FS에 있는 두 개의 패키지를 나열하고 하나는 제자리에 빌드하고 다른 하나는 빌드해야 하는 경우 어떻게 합니까? 둘 중 하나를 수행할 수 있는 옵션을 제공하면 둘 중 하나로만 빌드할 수 있는 기존 패키지가 될 것입니다.

그것은 또한 프로젝트가 결정을 내릴 수 없었고 그 결정을 최종 사용자에게 미루기로 결정했기 때문에 완전히 존재하는 일종의 옵션과 같은 냄새가 납니다.

sdist를 통한 빌드는 정확히 나쁜 sdist를 잡는 것이 아닙니다. 대부분의 경우 프로젝트가 설치를 끝내기 전에 통과할 수 있는 "경로"의 가능한 변형을 줄이는 것입니다. 어떤 식으로든 플래그를 추가하면 문제가 더 악화되지 않고 악화됩니다.

내 말은 설치가 통과할 수 있는 몇 가지 "경로"가 있다는 것입니다.

1. VCS -> Sdist -> 휠 -> 설치됨
2. VCS -> 휠 -> 설치됨
3. VCS -> 설치됨(레거시)

단계적으로 제거되는 몇 가지 추가 경로가 있지만 일반적으로 3개입니다(이상적으로는 3개도 단계적으로 제거됨). 편집 가능한 설치도 있지만 곧 사라지지 않을 것입니다.

sdist 또는 휠이 PyPI에 업로드되고 동일한 "경로"의 일부가 될 때까지 설치되는 것으로 간주할 수 있습니다. 일시 중지하고 다른 컴퓨터에서 완료하면 됩니다.

이와 같은 여러 "경로"가 있는 문제는 최종 설치 결과에 불일치가 발생한다는 것입니다. 항상 발생하는 것은 아니지만 자주 발생하는 것은 쉽게 관찰할 수 있는 경우입니다. 종종 이러한 불일치는 큰 문제가 아니지만 때로는 그렇습니다.

우리가 이와 같은 제자리 빌드를 수행하는 경우 우리는 단일 경로로 절대 무너질 수 없을 것이라고 효과적으로 말하고 있습니다. 사람들은 설치 방법에 따라 다른 결과를 얻게 됩니다.

추가 이점으로, 이것은 행복한 경로가 행복하게 유지되도록 하는 강제 기능으로 작용할 수도 있습니다.

대부분 @dstufft 에 동의합니다. 특히 sdist에서 빌드 접근 방식이 "sdist를 검증하려는 시도"가 아니라 "모든 것이 "소스 트리 -> sdist -> 휠 -> 설치 경로를 따릅니다. (일부 초기 단계를 건너뛰는 경우도 있음)".

그러나 한 가지 점을 지적하고 싶습니다.

내 로컬 FS에 있는 두 개의 패키지를 나열하고 하나는 제자리에 빌드하고 다른 하나는 빌드해야 하는 경우 어떻게 합니까?

서로 다른 옵션을 사용하여 두 개의 개별 pip 실행에서 두 패키지를 실행하기만 하면 됩니다?!? 하나가 다른 하나의 종속성일 수 있다는 것을 알고 있으며 일반적으로 귀하의 요점은 유지되지만 사람들이 모든 설치 시나리오가 단일 실행으로 축소되어야 한다고 가정하는 일반적인 경향이 있는 것 같습니다. 합리적이라고 생각함

(만약) 되돌릴 때 트리 내 빌드를 구현한 결과 닫혀 있던 #6276과 같은 문제를 다시 열어야 합니다.

문제의 일부는 pip가 종속성을 해결할 때 이미 설치된 항목을 고려하지 않는다는 것입니다(새 해결 프로그램이 이를 변경하는지 확실하지 않습니까?). 따라서 해결하려면 단일 pip 호출 내에 모든 것이 포함되어 있어야 합니다. 종속성을 "올바르게"(현재 리졸버가 올바르게 수행하는 범위 내에서).

새로운 리졸버가 이미 설치된 것을 고려한다면 pip install foo bar 와 pip install foo && pip install bar 는 거의 같을 것이고 전혀 중요하지 않을 것입니다. 두 프로젝트가 모두 "스팸"에 의존했지만 foo가 < 2이고 bar가 > 1이면 잘못된 설치가 발생합니다.

그것은 접선입니다 :)

(새로운 리졸버 작업이 변경되는지 확실하지 않습니까?)

#7744에서 입력을 환영합니다. :)

1. 항상 제자리에 빌드하도록 pip를 변경합니다.

따라서 이것은 너무 파괴적인 것으로 간주되어 20.1.1에서 되돌릴 것입니다.

분명히 말해서, 우리는 "너무 빨리 출시"했고 우리가 취한 출시 접근 방식은 이것이 결국 너무 파괴적인 이유의 일부입니다.

1. 제자리에 빌드하려면 pip 옵션을 추가하십시오.

@dstufft @pfmoore 저는 그런 종류의 옵션을 옵트인 메커니즘으로 보고 있습니다. 따라서 사용자가 어느 시점에서 기본값으로 설정하는 것을 목표로 인플레 이스 빌드로 점진적으로 넛 지를 할 수 있습니다. 이 의견의 정신: https://github.com/pypa/pip/issues/8165#issuecomment -625501216

이에 대해 PR을 제출하겠습니다. :)

8221입니다.

되돌린 변경 사항이 포함된 20.1.1이 릴리스되었습니다.

Fedora에서 Python RPM 패키지를 빌드할 때 우리는 공룡이며 씬을 수행하는 표준 방법은 python setup.py build 입니다. PEP 517에서는 pip wheel 대신 사용하는 "임시" 방법을 추가했습니다. 그러나 확장 모듈의 경우 pip가 빌드에 사용하는 "소스를 tmp로 이동하고 거기에서 빌드" 접근 방식에 문제가 있습니다.

빌드 기계는 일부 컴파일러 플래그를 주입하므로 빌드 아티팩트(이 경우 .so 확장 모듈)에 소스에 대한 메타데이터가 포함됩니다. 나중에 빌드 아티팩트를 탐색하고 이 정보를 추출하고 소스를 /usr/src/debug 에 복사하여 특수 *-debugsource RPM을 통해 설치하는 쉘 스크립트가 있습니다. mahcinery는 모든 것이 작업 트리 내에서 구축되기를 기대하며 외부에서 구축할 때는 실제로 제대로 작동하지 않습니다. 다음은 우리 측에서 문제를 완화하기 위해 (함께) 할 수 있는 일입니다.

1. set the `$TMPDIR` environment variable to have it within the place where the RPM script expects it (i.e. `export TMPDIR=%{_builddir}/.tmp` (and create it))

2. use `pip wheel` with the `--no-clean` option to keep the copied sources in `$TMPDIR`

3. run some shell kung fu to rewrite the "what is my source" information to the correct location: `find %{buildroot} -iname '*.so' -print0 | xargs --no-run-if-empty -0 -n1 /usr/lib/rpm/debugedit -b "%{_builddir}/.tmp/pip-req-build-"* -d "$PWD"`

4. (Optional: clean `$TMPDIR` manually.)

이것은 pip 통합, #6505 등을 볼 때 효과적으로 시작한 경로입니다.

pip를 사용한 반복 빌드는 오늘날 효과적으로 손상되었습니다. 이는 C 확장 형식의 많은 양의 python 코드가 있는 그룹에 큰 손실이므로 setup.py 를 사용하여 빌드를 호출했습니다.

pip 필요 build 명령의 최종 결과 build 같은 다른 하위 명령에 따라 무난되어야 명령 wheel , install , 등.

지금 pip 는 install 를 build 및 install pip 효과적으로 처리합니다. 이것은 바이너리 아티팩트를 빌드하고 캐싱하고 읽기보다 바이너리를 설치하는 일부 사람들이 원하는 _아닌_입니다. - 전용 마운트 등

난 정말 사용할 수있는 방법이 있었으면 좋겠어 setup.py 한 후, 바이너리를 구축하기 pip install 생성에 의지없이 bdist ,하지만 오늘은 가능하지 않는 것 , pip 및 distutils / setuptools 바이너리 아티팩트를 찾을 위치에 동의하지 않기 때문에.

setup.py를 사용하여 바이너리를 빌드한 다음 bdist를 생성하지 않고 pip 설치하는 방법이 있었으면 좋겠지만, pip 및 distutils/setuptools가 동의하지 않기 때문에 오늘날에는 불가능한 것 같습니다. 바이너리 아티팩트를 찾는 곳.

나는 내가 따르고 있는지 확실하지 않습니다. 당신은 바이너리를 사용하는 방법을 원하지만 이미 존재하는 바이너리 배포 형식을 사용하고 싶지 않다고 말하고 있습니다. 왜 그런 겁니까?

setup.py를 사용하여 바이너리를 빌드한 다음 bdist를 생성하지 않고 pip 설치하는 방법이 있었으면 좋겠지만, pip 및 distutils/setuptools가 동의하지 않기 때문에 오늘날에는 불가능한 것 같습니다. 바이너리 아티팩트를 찾는 곳.

나는 내가 따르고 있는지 확실하지 않습니다. 당신은 바이너리를 사용하는 방법을 원하지만 이미 존재하는 바이너리 배포 형식을 사용하고 싶지 않다고 말하고 있습니다. 왜 그런 겁니까?

bdist 형식은 매우 제한적입니다. 우리 그룹은 tar와 같은 멍청한 형식에 의존하고 그대로 압축을 풀어야 합니다(BSD는 지원되지 않으며 데비안은 지원되지 않습니다. 등).

내가 어젯밤 발견한 것은 멍청한 bdist를 사용하는 것이 pip 를 통해 설치할 수 없다는 것입니다. 멍청한 바이너리에는 pip , AFAICT를 통해 설치하는 데 필요한 메타데이터가 부족합니다. 여기서 pip 바퀴가 작동하는 것 같습니다.

계란과 zip도 시도했지만 file:// URI만 사용하여 설치하는 데 필요한 메타데이터가 부족합니다.

나는 distutils, setuptools를 통해 make를 사용하여 더 큰 빌드 시스템으로 빌드를 구부리려고 애썼습니다. 그래서 표준 bdist 호출이 있을 것입니다.

https://github.com/pypa/pip/issues/2195#issuecomment -664728481 저는 --use-feature=in-tree-build 뒤에 #7882를 다시 하게 되어 기쁩니다.

만세! 계획 같은 소리!

이번에는 --build 의 독스트링도 업데이트합시다. ;)

#2195(댓글)에서 가져온 --use-feature=in-tree-build 뒤에서 #7882를 다시 수행하게 되어 매우 기쁩니다.

pyproject.toml in-tree-build 옵션을 설정하는 것이 합리적일 수 있는지 궁금합니다. 이것은 pip를 래핑하기 위해 bash 스크립트나 makefile을 만들 필요 없이 #6276을 해결하는 데 아주 좋습니다. (그게 특별히 큰 문제는 아닙니다.)

pyproject.toml에 트리 내 빌드 옵션이 설정되어 있습니다.

@davidhewitt 이것은 이 문제에 대한 원래 설명에서 다소간 옵션 3입니다. 가능한 한 추가 옵션을 피하는 것이 더 낫다는 현재의 합의가 있는 것으로 알고 있습니다. 따라서 전환 기간 동안 --use-feature 를 사용하여 트리 내 빌드를 활성화하고 이를 기본 및 유일한 메커니즘으로 만드는 장기적인 목표를 설정합니다.

BTW, 나는 이것을 20.3에 제때에 구현할 수 없지만, 20.4에서 희망적으로는 여전히 할 의향이 있습니다.

@sbidoul 이 기능을 사용하는 데 도움이 되는 패치를 작성했습니다. #9091 참조.