<p>디렉토리의 pip 설치가 매우 느립니다.</p>

.git 포함하여 전체 디렉토리의 복사본을 만들고 있습니다. 아마 그렇게 해서는 안 될 것입니다.

$ du -sh pip
263M    pip

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

3 -v 의 ( time pip install -vvv --no-install ~/dev/git-repos/pip ) 전달을 시도했지만 더 이상 정보를 얻지 못했습니다.

pdb로 스테핑하면 다음과 같이 속도가 느려집니다.

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

그리고 예, @tomprince 가 맞습니다. 전체 트리를 복사할 때 속도가 느려집니다.

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

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

https://github.com/pypa/pip/issues/2196의 일부 토론

https://github.com/pypa/pip/pull/2196 이 병합되어 훨씬 빨라졌습니다.

#2196이 복구되었으므로 다시 열어야 합니다. 복사할 대상을 파악하기 위해 발견적 방법을 사용하는 대신 sdist를 빌드하는 대체 PR을 제공하고 싶습니다. 자세한 내용은 해당 PR의 주석을 참조하십시오.

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

예, 거의 3분입니다.

아마도 다음과 같은 이유 때문일 것입니다.

$ du -sh .tox
177M    .tox

.tox 디렉토리는 전체 pip 디렉토리에 대한 총 .tox 천만 중 pip 입니다.

https://github.com/pypa/pip/pull/2535 를 참조 unpack_file_url 속도가 빨라집니다.

병합된 PR이 아무 작업도 수행하지 않았기 때문에 이 문제를 다시 열어야 합니다(gh-3219 참조).

이 문제에 대한 진전이 있습니까?

아니요. 최종 솔루션이 곧 도착할 것 같지 않습니다. PEP 516 또는 PEP 517은 먼저 sdist 생성하는 것이 올바른지 여부에 대한 결정을 내리기 전에 수락해야 합니다(저는 개인적으로 그렇게 생각하지 않습니다).

PEP 516은 이를 다음과 같이 요약합니다.

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

아마도 가장 쉬운 방법은 .git 및 .tox 모두 복사하는 것과 같이 가장 머리가 좋지 않은 동작을 수정하는 더 간단한 PR을 제출하는 것입니다(오늘날에도 여전히 발생한다고 가정). 그것은 많은 경우에 상당한 속도 향상이 될 것이며 논쟁의 여지가 없을 것입니다.

npm의 베어 리포지토리(소스 배포 대신 또는 게시된 패키지라고 말해야 함)에서 설치할 때 수행할 작업과 유사한 문제 – git url 패키지에 대해 prepublish 실행

@rgommers .git 및 .tox 와 같은 일부 파일/디렉토리 이름을 하드코딩하는 대신 .gitignore 와 같이 무시할 파일 및 디렉토리를 나열하기 위해 .pipignore 파일을 추가하는 것은 어떻 .tox ?

그것은 좋은 생각이 아닙니다. 이것은 모든 패키지의 개발자에게 이 느림을 처리하는 책임을 옮기는데, 이것은 단지 작동하지 않습니다.

npm이 있으면 좋은 것입니다 :) – https://docs.npmjs.com/misc/developers#keeping -files-out-of-your-package

이것은 또한 setuptools_scm와 같은 것들을 훨씬 더 적극적으로 중단시킵니다 ^^ - pip install 폴더 복사를 만드는 것은 이미 어려운 일을 중단시킵니다.

setuptools_scm와 어떤 관련이 있습니까? 어떤 종류의 소스 패키지도 아닌 유효한 저장소에서 실행해야

그것은 좋은 생각이 아닙니다. 이것은 모든 패키지의 개발자에게 이 느림을 처리하는 책임을 옮기는데, 이것은 단지 작동하지 않습니다.

.pipignore가 이를 억제하는 빈 .pipignore와 함께 .git, .hg 등을 암시적으로 포함하도록 합니다.

@piotr-dobrogost 소스 저장소에서 pip 설치는 pip가 충분한 컨텍스트를 복사하지 않는 다양한 상황에서 중단됩니다(예: pypa/setuptools_scm#138).

우리는 이전에 같은 디렉토리를 무시했다 .git 와 같은 및 파산 가지 PBR 등을하고 변화를 되돌릴 수 있었다.

@dstufft 루트 대신 git repo의

흠, 파손 정도가 심했다면 여기서 개선할 수 있는 간단한 방법은 없습니다. 빌드 PEP 중 하나를 기다리고 있다고 생각하십시오.

pbr은 .git dir이 없는 상태에서 넘어지면 상당히 불합리한 일을 하고 있을 것입니다. 하지만 ....

이에 대한 진전이 있는지 궁금하십니까? .git 또는 .${scm} 폴더가 번거로울 뿐만 아니라 사람들이 소스와 함께 .vagrant/ 를 포함하면 훨씬 더 나쁩니다.

사용자 정의할 수 있는 .pipignore 가 있으면 고통을 완화하는 데 정말 도움이 됩니다.

다른 데이터 포인트의 경우 Javascript 프로젝트를 문서화하기 위해 Sphinx를 사용하기 때문에 일부 프로젝트에는 Python과 Javascript가 혼합되어 있습니다. 따라서 pip는 매우 큰 node_modules 디렉토리도 복사하므로 매우 느릴 수 있습니다.

따라서 하드코딩된 값이 모든 유형의 프로젝트에 충분하지 않을 수 있다는 사용 사례가 강조되므로 .pipignore 옵션에 투표할 것입니다.

사람들은 SCM 파일 이외의 모든 종류의 쓰레기를 트리에 보관합니다.

나는 패키지 소스 코드와 동일한 디렉토리에 보관하는 코드로 생성된 몇 가지 큰 시뮬레이션(16GB 이상)을 가지고 있습니다(다른 프로젝트를 추적하는 방법으로).

pip install . 내 /tmp에 복사합니다. 빈약한 파티션은 실제로 공간이 부족하고 pip는 디스크 공간 오류로 실패합니다.

sdist가 사용되지 않아야 하고 .pipignore가 인터페이스를 확장하는 경우 MANIFEST.in/MANIFEST 파일을 구문 분석하기 위해 코드를 재사용하는 것은 어떻습니까? 설치에 필요한 모든 파일을 설명해야 합니다.

좋은 해결 방법은 편집 가능한 설치( pip install -e $DIR )를 사용하는 것 같습니다.

좋은 해결 방법은 편집 가능한 설치(pip install -e $DIR)를 사용하는 것 같습니다.

테스트를 위해 pypi에서 패키지를 설치하는 사용자가 사용하는 것을 테스트하지는 않습니다. (예: 패키지되지 않은 패키지 및 모듈은 계속 사용할 수 있음)

이 스레드에서 이전에 언급된 적이 있기를 바랍니다.

더 나은 해결 방법은 setup.py를 사용하여 직접 sdist 또는 휠을 만들고 pip를 사용하여 생성된 인공물을 설치하는 것입니다. 그렇게하면 pip는 디렉토리 복사 작업을 수행하지 않으며 (설치할 파일이 있기 때문에) 이것은 pip install . (pip 9 기준)에서와 똑같은 결과입니다. 디렉토리 사본.

맙소사, 이 문제는 이미 어떻게든 해결할 수 있습니까? 내 말은, 이 행동이 뇌사 상태라는 데 어느 정도 합의가 된 것 같습니다. 그러나 티켓은 현재 3년 동안 열려 있고 해결책이 보이지 않습니다. 나는 pip가 몇 분 동안 방해하거나 중단되지 않도록 트리 안팎으로 데이터를 수동으로 이동해야 하는 것을 싫어합니다(공유 파일 시스템에서 작업해야 함).

기존 작업을 중단하지 않는 방법에 대한 합의가 없으면 .pipignore 와 같은 솔루션을 옵트인으로 제공할 수 있습니까? 이 문제를 해결하기 위해 몇 가지 문제를 해결하는 데 문제가 없습니다.

@andre-merzky 진정하세요.

우리는 이 문제를 알고 있지만 자원이 매우 제한된 자원 봉사 단체입니다. 그리고 실용적인 측면에서 이 문제는 우선 순위 목록에서 높은 순위를 차지할 만큼 충분히 심각하게 사용자에게 영향을 미치지 않습니다.

그것은 적절한 시기에 고쳐질 것입니다(그리고 우리가 현재 해결하려고 하는 더 중요한 작업, 특히 PEP 517은 부작용으로 이 문제를 해결할 가능성이 높습니다). 그러나 자원봉사자에게 소리치는 것은 도움이 되지 않습니다. 즉각적인 수정이 중요하다고 생각되면 PR을 검토하게 되어 기쁩니다. 하지만 PR을 제출하고 승인을 받더라도 PIP 10까지는 릴리스되지 않습니다. 릴리스 우리는 위에서 언급한 "큰 티켓" 작업의 일부를 얻고 싶습니다(자원 자원 제약으로 인해 다시 발생하지 않을 수도 있지만 그것이 우리의 목표입니다). 따라서 출시되기 전에 대체될 수 있습니다. 하지만 그렇다고 해서 PR을 만들 수 없다는 의미는 아닙니다. 더 큰 계획이 제때에 나오지 않으면 대체가 될 것입니다.

@pfmoore 어조에 대해 유감스럽게 생각하고 좌절감을 느꼈습니다... 저는 사소한(따라서 수용할 수 없는) 수정 사항(#4900)에 대한 PR을 만들었습니다. 출시 주기에 대해 들었습니다. 일이 그렇게 진행되고 있다는 것을 알고 있습니다...

이것에도 부딪쳤습니다.

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

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

재설정 후:

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

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

문제에 대한 최신 프로파일링 보고서는 어디에 있습니까?

변경 사항이 없습니다. 오늘날 pip는 여전히 전체 패키지를 임시 빌드 디렉토리에 복사하고 있습니다.

이 디렉토리가 메모리에 있습니까?

아니요, 디스크에 기록되므로 공유 파일 시스템에서 특히 고통스럽습니다...

적어도 /tmp 또는 /dev/shm 입니까? https://stackoverflow.com/questions/9745281/tmp-vs-dev-shm-for-temp-file-storage-on-linux tmpfs 가 사용되지 않을 때 감지하여 생성을 제안할 수 있습니까?

/tmp 있습니다. stdlib tempfile 에 따라 다릅니다.

PEP 517을 구현하면 이 문제가 해결됩니다.

나는 최신 개발자 버전의 pip로 이 문제를 겪고 있습니다. PEP 517 지원이 pip 19에 추가되었다고 생각했는데, 계속 발생해야 합니까?

제 경우에는 원격 및 분기가 많은 프로젝트(astropy)에서 작업하기 때문에 .git 디렉토리가 1.8Gb이고 이것을 임시 디렉토리로 복사하는 데 몇 분이 걸립니다. 소스 배포를 먼저 구성한 다음 무대 뒤에서 휠을 빌드하는 것이 더 합리적일 것 같습니다.

우리도 이 문제로 인해 여전히 많이 아프다. 사용자에게 코드와 실험 데이터(크기가 큰)를 동일한 디렉토리에 보관할 수 없다고 말하는 것은 정말 어렵습니다. 이는 직관적이지 않습니다. 자체 시스템에서는 .pipignore 패치를 사용하지만 지원하는 대부분의 시스템에는 이를 배포할 수 없습니다... :/

우리는 오늘 이 https://github.com/pypa/pip/issues/2195#issuecomment -351258913을 실행합니다. 여전히 일어나고 있습니다.

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

PEP 517을 구현하면 이 문제가 해결됩니다.

해설자: 그렇지 않았습니다.

이 문제를 해결하려면 sdist를 통해 설치해야 하며, 지난번에 논의했을 때 실제 소스 디렉토리가 필요한 도구를 사용하는 사람들로부터 많은 반발이 있었습니다. 개인적으로 나는 우리가 당신이 할 때 동일한 결과를 제공하지 않는 총알 및 지원 중단 빌드 프로세스 물린해야한다고 생각 build_sdist 다음 build_wheel 그냥 할 때 당신이 얻을으로 build_wheel , 하지만 현재로서는 그 제안을 옹호할 시간이나 에너지가 없습니다.

이 문제를 해결하려면 sdist를 통해 설치해야 합니다.

사실, no - #4900은 이전 버전과 호환되는 방식으로 작은 코드로 문제를 해결하는 구현을 제공했습니다. 다른 문제를 해결하지 못할 수도 있지만 이 티켓의 나이를 감안할 때 그 접근 방식을 재고해 달라고 요청하고 싶습니다.

이 문제를 해결하려면 sdist를 통해 설치해야 하며, 지난번에 논의했을 때 실제 소스 디렉토리가 필요한 도구를 사용하는 사람들로부터 많은 반발이 있었습니다. 개인적으로 저는 build_sdist를 수행한 다음 build_wheel을 수행할 때와 build_wheel을 수행할 때와 동일한 결과를 제공하지 않는 총알을 깨고 빌드 프로세스를 더 이상 사용하지 않아야 한다고 생각합니다. 그러나 나는 그 제안을 옹호할 시간이나 에너지가 없습니다. 순간.

인플레이스 빌드에 관심이 있어서 "항상 sdist 경로를 통해 가야 함"을 싫어했던 사람으로서: 저는 오래전에 "go sdist 경로"와 화해했습니다.

이 문제는 발생하면 _매우_ 고통스럽고 "기본적으로 모든 것을 복사"하는 것은 거의 의미가 없습니다. 그래서 총알을 물어뜯는 데 +10이 됩니다.

이 문제를 해결하려면 sdist를 통해 설치해야 합니다.

나는 PEP 517로 전환할 것이라고 잘못 가정했습니다.

나는 여기에 전적으로 동의합니다.

IIRC 우리는 할 수 있었지만 sdist를 통한 설치가 허용되는지 여부에 대한 논쟁은 당시 추가하기에는 너무 많은 추가 논쟁이었습니다. 강좌 :-)

나는 여전히 sdist를 통해 건물로 전환하는 것을 선호하지만 지금은 직접 할 시간이 없습니다.

해결 방법: 얕은 복제를 사용합니다(깊이를 적절하게 변경).

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

반복하고 요약하자면:

• pip 유지 관리자는 이것이 사용자에게 좋은 경험이 아니라는 데 동의합니다. pip의 자체 개발 프로세스가 이 문제를 해결했습니다.
• 이러한 일이 발생하는 이유는 pip가 소스 디렉토리를 임시 디렉토리에 복사하여 빌드가 소스 외부에 있는 것에 의존하지 않도록 하기 때문입니다.
• 이 문제를 해결하려는 방법은 pip의 동작을 변경하여 소스 배포를 트리 내에서 빌드하고, 소스 배포를 임시 디렉토리에 압축을 풀고, 거기에서 바이너리를 빌드하는 것입니다.

이제 이 경로를 사용하면 사용자를 위한 pip의 빌드 메커니즘과 관련된 여러 사용성 문제도 해결됩니다.

나는 pip의 빌드 로직을 리팩토링하기 위해 자발적인 프로젝트를 시작했습니다. 이 문제를 리팩토링 작업의 일부로 다루지는 않겠지만 이 문제를 해결하려고 할 만큼 충분히 관심이 있는 사람을 기꺼이 도울 수 있습니다. 수정 사항은 pip의 빌드 로직과 상당히 관련이 있습니다. 가장 간단한 코드가 아니며 구현 중에만 알아차릴 수 있는 까다로운 경우가 있을 수 있습니다.

아, 그리고 이에 대한 반창고 해결 방법으로 #6770에 추가된 pip 19.3은 복사할 때 .nox 및 .tox 디렉토리를 제외합니다. 이렇게 하면 상당한 수의 사용자에 대해 이러한 설치에 소요되는 시간이 줄어듭니다.

이것은 큰 .git 또는 build 디렉토리에 대한 문제를 해결하지 못합니다. 이것이 제가 위의 설명에서 자세히 설명한 접근 방식으로 해결할 수 있는 것입니다. :)

이것은 큰 .git 또는 build 디렉토리에 대한 문제를 해결하지 못합니다. 이것이 제가 위의 설명에서 자세히 설명한 접근 방식으로 해결할 수 있는 것입니다. :)

.git 에 의존하는 도구가 있다는 것을 알고 있지만 build 복사에 의존하는 사람이 있습니까? 무시된 디렉토리에 추가하는 것이 좋으며 동의하면 PR을 보내드립니다.

이거 아직 조사중인가요? pip install . 중에 여러 기가바이트의 git 무시 디버그 데이터 덤프가 복사되는 것을 보는 것은 매우 고통스러운 놀라움입니다.

예, #7555와 같은 연결된 문제를 살펴보십시오.

이 문제는 내가 설치하는 디렉토리에 10mb의 파이썬 코드가 있지만 많은 json 데이터 파일과 .git 가 있기 때문에 여전히 지속됩니다.

이것은 #7882(적소에 로컬 디렉토리 구축)로 해결해야 합니다.

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

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

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

나는 그것이 상당히 낫다고 말할 것입니다.

이전: noglob pip3 install . 3.76s user 2.51s system 12% cpu 50.245 total

신규: noglob pip3 install . 3.40s user 0.70s system 42% cpu 9.764 total

나를 위해 훌륭하게 / 더 빠르게 작동합니다! :+1:

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

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

~2분에서 4초로 줄였습니다. 정말 감사합니다!

긍정적인 보고에 감사드립니다 @PythonCoderAS @astrofrog @klamann! :)

불행히도 인플레이스 빌드(#7555에서 추적 중) 구현에 여러 문제가 있어 현재로서는 #7882를 되돌려야 합니다. 결과적으로 이 문제는 다시 문제가 될 것이므로 다시 열어 보도록 하겠습니다. 장기적으로 현재 솔루션이 가지고 있던 다른 워크플로에는 영향을 미치지 않으면서 현재 위치 빌드로 해결된 문제를 해결하는 솔루션이 있기를 바랍니다.

이로 인해 불편을 드려 죄송합니다.

불행히도 인플레이스 빌드 구현과 관련하여 많은 문제가 있었습니다.

@pradyunsg 업데이트에 감사드립니다. 용어에 대한 몇 가지 피드백(참고만 하시면 됩니다): 이 문장과 gh-7555는 pip가 내부 빌드를 수행하지 않기 때문에 저를 혼란스럽게 했습니다. 내부 빌드가 항상 의미하는 것은 python setup.py build_ext --inplace (또는 python setup.py develop )입니다.

여기서 의미를 "tmpdir에 복사하지 않고 빌드"로 변경했습니다. 확장 모듈은 여전히 ​​제자리에서 끝나지 않고 일반적으로 쉽게 정리되는 build/ 디렉토리에 있습니다. 예를 들어 gh-7555에서 좀 더 명시적이면 좋을 것입니다.

원래 내 말이었다. 혼란을 드려 죄송합니다. 저는 setuptools가 "in place"라는 용어를 다른 의미로 사용했다는 사실을 알지 못했습니다(그리고 그 용어가 setuptools 외부에 어떻게 적용되는지 아직 확실하지 않습니다). 앞으로 더 중립적인 용어를 찾을 수 있는지 알아보겠습니다.

전혀 걱정하지 마세요. @pfmoore에게 감사드립니다. 용어에 대한 혼란은 때때로 서로를 지나쳐 이야기하는 결과를 낳을 수 있기 때문에 지적해야 한다고 생각했습니다.

그리고 그 용어가 setuptools 외부에 어떻게 적용되는지 아직 확실하지 않습니다.

CMake 및 scikit-build와 같은 도구의 경우 동일한 의미라고 생각합니다. 실제로는 제자리에 있고 바이너리가 소스 옆에 있습니다.

반면에 "편집 가능한 설치"는 (내 생각에) 여기에서 발명되었으며 일종의 "pip가 인식하는 제자리"를 의미합니다.

손에 꼽히긴 했지만 무엇인지 잘 모르겠습니다. 제안을 감사히 받아 들였습니다.

아마도 "로컬 빌드"(현재 "tmpdir 및 빌드에 복사")?

반면에 "편집 가능한 설치"는 (내 생각에) 여기에서 발명되었으며 일종의 "pip가 인식하는 제자리"를 의미합니다.

우리는 최근에 편집 가능한 설치가 무엇을 의미하는지에 대해 긴 토론을 했으며 실제로 pip가 가는 한 machine local 에 더 가까운 위치에 도착했다고 생각합니다. 그러나 pip는 로컬 시스템의 위치와 방법을 알지 못하며 이를 정의하고 처리하는 빌드 백엔드 작업입니다.

«in-tree 빌드»(«in-tree PEP 517 백엔드»와 유사) 또는 «build in source dir»을 시도할 수 있습니다.

제 질문은 기능이 선택 사항이 될 수 없기 때문에 문제를 일으키지 않지만 인수 또는 이와 유사한 것으로 활성화할 수 있는 이유는 무엇입니까?

편집 가능한 설치가 옵션이 아닌 이 문제에 대한 해결 방법에 대해 머리를 쓰려고 합니다. 있어요?

해결 방법은 휠을 빌드한 다음(빌드 백엔드를 직접 사용하여) pip를 지정하여 설치하는 것입니다.

왜 기능은 선택 사항이 될 수 없으므로 문제를 일으키지 않지만 인수 또는 이와 유사한 것으로 활성화할 수 있습니까?

그것은 할 수 있습니다. 변경 사항을 되돌린 이유는 옵트아웃이나 변경 사항에 대한 피드백을 받을 기간이 없었기 때문입니다. 이를 용이하게 하는 데 도움이 되는 새로운 플래그(--use-feature 및 --deprecated-feature)가 있지만 누군가 지금 이 컨텍스트에서 기능을 다시 구현/재도입해야 합니다.

일반적으로 우리가 여기서 하고자 하는 것은 다음과 같습니다.

• --use-feature=in-tree-build를 옵트인으로 추가합니다.
• --deprecated-feature=out-of-tree-build를 사용하여 이후 릴리스에서 기본값을 옵트아웃으로 전환하고 --use-feature=in-tree-build 사용자를 밀어서 삭제합니다.
• 후속 릴리스에서 두 옵션을 모두 삭제합니다.

해결 방법은 휠을 빌드한 다음(빌드 백엔드를 직접 사용하여) pip를 지정하여 설치하는 것입니다.

추가 빌드 단계 없이 생각하고 있었습니다. 그러나 나는 처음부터 Python이 Makefile에 상응하는 것 없이 벗어날 수 있다고 생각하지 말았어야 했다고 생각합니다.