<p>instalasi pip dari sebuah direktori sangat lambat</p>

Itu membuat salinan seluruh direktori, termasuk .git . Mungkin seharusnya tidak melakukan itu, tidak.

$ 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

Saya mencoba meneruskan 3 -v 's ( time pip install -vvv --no-install ~/dev/git-repos/pip ) -- yang tidak menghasilkan info lebih lanjut.

Melangkah melaluinya dengan pdb, segalanya melambat ketika saya sampai ke:

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

Dan ya, @tomprince benar - ia melambat ketika menyalin seluruh pohon:

> /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

Beberapa diskusi di https://github.com/pypa/pip/issues/2196

Jauh lebih cepat sekarang karena https://github.com/pypa/pip/pull/2196 digabungkan.

Ini harus dibuka kembali sejak #2196 dikembalikan. Saya ingin datang dengan PR alternatif yang membangun sdist daripada menggunakan heuristik untuk mencari tahu apa yang harus disalin. Lihat komentar pada PR itu untuk detailnya.

$ 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

Ya ampun, hampir 3 menit.

Mungkin sebagian besar karena ini:

$ du -sh .tox
177M    .tox

Direktori .tox adalah 177 juta dari total 270 juta untuk seluruh direktori pip .

Silakan lihat https://github.com/pypa/pip/pull/2535 , yang mempercepat unpack_file_url dengan membuat sdist dan membongkarnya.

Masalah ini harus dibuka kembali, karena PR yang digabungkan tidak melakukan apa-apa (lihat gh-3219).

Ada kemajuan untuk masalah ini?

Tidak, dan sepertinya solusi akhir tidak akan tiba dalam waktu dekat. PEP 516 atau PEP 517 perlu menerima sebelum keputusan dapat dibuat apakah menghasilkan sdist terlebih dahulu benar (saya pribadi tidak berpikir begitu).

PEP 516 merangkumnya sebagai:

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.

Mungkin yang paling mudah adalah seseorang mengirimkan PR sederhana yang memperbaiki perilaku paling mematikan, seperti menyalin semua .git dan .tox (dengan asumsi itu masih terjadi hari ini). Itu akan menjadi percepatan yang signifikan dalam banyak kasus dan tidak akan kontroversial.

Entah bagaimana masalah serupa apa yang harus dilakukan ketika menginstal dari repo kosong (alih-alih distribusi sumber atau haruskah saya mengatakan paket yang diterbitkan) di npm - jalankan prepublish untuk paket url git

@rgommers Bagaimana kalau menambahkan file .pipignore ke daftar file dan direktori untuk diabaikan seperti .gitignore daripada hardcoding beberapa nama file/direktori seperti .git dan .tox ?

Itu bukan ide yang baik - itu memindahkan tanggung jawab untuk menangani kelambatan ini ke pengembang setiap paket, yang tidak berfungsi.

Jika npm memilikinya, itu pasti bagus :) – https://docs.npmjs.com/misc/developers#keeping -files-out-of-your-package

ini juga secara aktif merusak hal-hal seperti setuptools_scm bahkan lebih ^^ - pip install membuat salinan folder sudah merusak segalanya

Apa hubungannya setuptools_scm dengannya? Itu harus dijalankan pada repo yang valid dan bukan jenis paket sumber apa pun .

Itu bukan ide yang baik - itu memindahkan tanggung jawab untuk menangani kelambatan ini ke pengembang setiap paket, yang tidak berfungsi.

Minta .pipignore secara implisit menyertakan .git, .hg dll. dengan .pipignore kosong yang menekan ini.

@piotr-dobrogost instalasi pip dari repo sumber akan rusak dalam berbagai keadaan di mana pip tidak menyalin konteks yang cukup - misalnya pypa/setuptools_scm#138

Kami sebelumnya melakukan mengabaikan direktori seperti .git dan hal-hal seperti itu dan bangkrut seperti pbr dan harus mengembalikan perubahan.

@dstufft masih merusak barang jika ada di subdir git repo alih-alih root ^^

Hmm, jika kerusakan itu cukup parah maka tidak ada cara sederhana untuk memperbaikinya di sini. Kira itu menunggu salah satu PEP build.

pbr pasti melakukan sesuatu yang sangat tidak masuk akal jika jatuh tanpa hadiah dir .git , tapi yah ....

bertanya-tanya apakah ada kemajuan dalam hal ini? tidak hanya folder .git atau .${scm} menyusahkan, jauh lebih buruk jika orang menyertakan .vagrant/ bersama dengan sumbernya.

memiliki .pipignore yang dapat disesuaikan akan sangat membantu meringankan rasa sakit.

Untuk titik data lain; kami memiliki campuran Python dan Javascript di beberapa proyek, karena kami menggunakan Sphinx untuk mendokumentasikan proyek Javascript kami. Oleh karena itu, pip juga menyalin direktori node_modules sangat besar, yang bisa sangat lambat.

Jadi kami akan memilih opsi .pipignore karena kasus penggunaan kami menyoroti bahwa nilai hardcoded belum tentu cukup untuk semua jenis proyek.

Orang-orang menyimpan semua jenis sampah di pohon di luar file SCM.

Saya memiliki beberapa simulasi besar (16GB +) yang dihasilkan oleh kode yang saya simpan di direktori yang sama dengan kode sumber paket (sebagai cara untuk melacak proyek yang berbeda).

pip install . menyalinnya ke /tmp. Partisi yang buruk benar-benar kehabisan ruang dan pip gagal dengan kesalahan ruang disk.

Jika sdist tidak seharusnya digunakan, dan .pipignore memperluas antarmuka, lalu bagaimana dengan menggunakan kembali kode untuk mengurai file MANIFEST.in / MANIFEST? Seharusnya dijelaskan semua file yang diperlukan untuk instalasi.

Solusi yang baik tampaknya menggunakan instalasi yang dapat diedit ( pip install -e $DIR ).

Solusi yang baik tampaknya menggunakan instalasi yang dapat diedit (pip install -e $DIR).

Kecuali, untuk pengujian, itu tidak menguji apa yang akan digunakan pengguna yang menginstal paket dari pypi. (mis. paket dan modul yang tidak dikemas akan tetap tersedia)

Saya harap ini telah disebutkan sebelumnya di utas ini.

Solusi yang lebih baik adalah membuat sdist atau roda secara langsung menggunakan setup.py dan menginstal artefak yang dihasilkan menggunakan pip. Dengan begitu, pip tidak akan melakukan hal-hal penyalinan direktori (karena ia mendapat file untuk diinstal) dan ini adalah hasil yang sama persis seperti yang Anda lakukan dengan pip install . (pada pip 9), dikurangi salinan direktori.

Demi Tuhan, teman-teman, bisakah ini diselesaikan entah bagaimana? Maksud saya, tampaknya ada beberapa konsensus bahwa perilaku ini adalah braindead - namun tiketnya terbuka selama tiga tahun sekarang, dan tidak ada solusi yang terlihat. Saya benci harus melakukan pemindahan data secara manual masuk dan keluar dari pohon saya hanya agar pip tidak muntah atau hang selama beberapa menit (saya harus bekerja pada sistem file bersama).

Jika tidak ada konsensus tentang cara untuk tidak merusak pekerjaan yang ada, dapatkah solusi seperti .pipignore diberikan sebagai pilihan, mungkin? Saya tidak keberatan melompati beberapa rintangan untuk memperbaikinya.

@andre-merzky harap tenang.

Kami menyadari masalah ini, tetapi kami adalah organisasi sukarelawan dengan sumber daya yang sangat terbatas. Dan dalam istilah praktis, masalah ini tidak cukup mempengaruhi pengguna kami cukup parah untuk menjadi yang teratas dalam daftar prioritas.

Ini akan diperbaiki pada waktunya (dan pekerjaan yang lebih besar yang kami coba selesaikan saat ini, khususnya PEP 517, kemungkinan akan menyelesaikan masalah ini sebagai efek samping) tetapi meneriaki sukarelawan tidak akan membantu. Jika Anda merasa bahwa perbaikan segera sangat penting, kami akan dengan senang hati meninjau PR - tetapi Anda harus menyadari bahwa meskipun Anda menaikkan PR dan membuatnya diterima, itu tidak akan dirilis hingga PIP 10, dan itu rilis kami ingin mendapatkan setidaknya beberapa pekerjaan "tiket besar" yang saya rujuk di atas (mungkin tidak terjadi lagi karena kendala sumber daya sukarelawan, tapi itulah tujuan kami). Jadi mungkin akan digantikan sebelum dirilis - tetapi itu tidak berarti Anda tidak boleh membuat PR, itu akan menjadi mundur jika rencana yang lebih besar tidak datang tepat waktu.

@pfmoore maaf untuk nadanya, frustrasi berbicara... Saya membuat PR untuk perbaikan sepele (dan dengan demikian mungkin tidak dapat diterima) (#4900). Saya mendengar Anda di siklus rilis, begitulah yang terjadi, saya tahu ...

Mengalami ini juga:

(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

Setelah mengatur ulang:

(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

Di mana laporan profil terbaru tentang masalah tersebut?

Tidak ada perubahan di sini. Saat ini, pip masih menyalin seluruh paket ke direktori build sementara.

Apakah direktori ini ada di memori?

Tidak, ini ditulis ke disk - yang membuatnya sangat menyakitkan pada sistem file bersama ...

Apakah setidaknya dalam /tmp atau /dev/shm ? https://stackoverflow.com/questions/9745281/tmp-vs-dev-shm-for-temp-file-storage-on-linux Bisakah itu mendeteksi ketika tmpfs tidak digunakan dan mengusulkan untuk membuatnya?

Itu ada di /tmp . Itu tergantung pada stdlib tempfile .

Menerapkan PEP 517 akan menyelesaikan ini.

Saya mengalami ini dengan pip versi pengembang terbaru - Saya pikir dukungan PEP 517 ditambahkan di pip 19, jadi apakah ini masih harus terjadi?

Dalam kasus saya karena saya bekerja pada sebuah proyek (astropi) di mana saya memiliki banyak remote dan cabang, direktori .git saya adalah 1.8Gb, dan butuh beberapa menit untuk menyalin ini ke direktori sementara. Sepertinya akan lebih masuk akal untuk membangun distribusi sumber terlebih dahulu kemudian membangun roda dari sana, di belakang layar.

Kami masih sangat terluka karena masalah ini juga. Sangat sulit untuk memberi tahu pengguna kami bahwa mereka tidak dapat menyimpan kode dan data eksperimental (yang berukuran besar) di direktori yang sama - ini cukup kontra-intuitif. Pada sistem kami sendiri, kami menggunakan patch .pipignore , tetapi tidak memiliki kemampuan untuk menerapkannya pada sebagian besar sistem yang kami dukung... :/

Kami juga mengalami https://github.com/pypa/pip/issues/2195#issuecomment -351258913 hari ini. Ini masih terjadi.

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

Menerapkan PEP 517 akan menyelesaikan ini.

Narator: tidak.

Memperbaiki ini memerlukan penginstalan melalui sdist, dan terakhir kali kita membahasnya, ada banyak penolakan dari orang-orang yang menggunakan alat yang (tampaknya) memerlukan direktori sumber yang sebenarnya. Secara pribadi saya pikir kita harus menggigit peluru dan mencela proses pembangunan yang tidak memberikan hasil yang sama ketika Anda melakukannya build_sdist lalu build_wheel seperti yang Anda dapatkan ketika Anda baru saja melakukannya build_wheel , tetapi saya tidak punya waktu atau energi untuk memperjuangkan proposal itu sendiri saat ini.

Memperbaiki ini memerlukan penginstalan melalui sdist

Sebenarnya, tidak - #4900 menyediakan implementasi yang memecahkan masalah dengan sedikit kode dengan cara yang kompatibel ke belakang. Ini mungkin tidak menyelesaikan masalah lain - tetapi mengingat usia tiket ini, saya ingin meminta untuk mempertimbangkan kembali pendekatan itu.

Memperbaiki ini memerlukan penginstalan melalui sdist, dan terakhir kali kita membahasnya, ada banyak penolakan dari orang-orang yang menggunakan alat yang (tampaknya) memerlukan direktori sumber yang sebenarnya. Secara pribadi saya pikir kita harus menggigit peluru dan mencela proses pembangunan yang tidak memberikan hasil yang sama ketika Anda melakukan build_sdist kemudian build_wheel seperti yang Anda dapatkan ketika Anda baru saja melakukan build_wheel, tetapi saya tidak punya waktu atau energi untuk memperjuangkan proposal itu sendiri saat ini.

Sebagai seseorang yang peduli dengan inplace build dan karena itu tidak menyukai "harus selalu melalui rute sdist": Saya telah berdamai dengan "rute go sdist" sejak lama.

Masalah ini _sangat_ menyakitkan jika Anda mengalaminya, dan "salin semuanya secara default" tidak masuk akal. Jadi +10 untuk menggigit peluru.

Memperbaiki ini memerlukan penginstalan melalui sdist

Saya salah mengira bahwa kami akan beralih dengan PEP 517.

Saya setuju sepenuhnya dengan Anda di sini.

IIRC kami bisa melakukannya, tetapi perdebatan yang akan dipicu tentang apakah menginstal melalui sdist dapat diterima terlalu banyak kontroversi tambahan untuk ditambahkan pada saat itu - dan karena menginstal melalui menyalin dan membangun roda masih merupakan pilihan, saya mengambil yang kurang stres kursus :-)

Saya masih lebih suka beralih ke bangunan melalui sdist, tetapi saya tidak punya waktu sekarang untuk melakukannya sendiri.

solusi: gunakan klon dangkal (ubah kedalaman sesuai):

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

Untuk mengulangi dan meringkas:

• Pengelola pip setuju bahwa ini bukan pengalaman yang baik bagi pengguna. proses pengembangan pip sendiri mengenai masalah ini.
• Alasan ini terjadi adalah, pip menyalin direktori sumber ke direktori sementara, untuk memastikan bahwa build tidak bergantung pada sesuatu di luar sumber.
• Cara kami ingin menyelesaikan masalah ini, adalah mengubah perilaku pip untuk membangun distribusi sumber di pohon, membongkar distribusi sumber di direktori sementara dan membangun biner dari itu.

Sekarang, mengikuti rute ini juga memperbaiki banyak masalah kegunaan lain di sekitar mekanika bangunan pip untuk pengguna.

Saya telah memulai proyek motivasi diri untuk memperbaiki logika build pip. Meskipun saya tidak akan menangani masalah ini sebagai bagian dari pekerjaan refactoring saya, saya lebih dari bersedia untuk membantu seseorang yang cukup cenderung untuk mencoba memperbaiki masalah ini -- perbaikannya akan cukup terlibat dalam logika build pip, yaitu Ini bukan bagian kode yang paling mudah dan mungkin ada kasus tepi rumit yang hanya kita perhatikan selama implementasi.

Oh, dan sebagai solusi plester untuk ini, ditambahkan di #6770, pip 19.3 akan mengecualikan direktori .nox dan .tox saat menyalin. Ini akan mengurangi jumlah waktu yang dibutuhkan penginstalan ini, untuk cukup banyak pengguna.

Ini tidak menyelesaikan masalah untuk direktori besar .git atau build -- itulah pendekatan yang saya uraikan dalam komentar saya di atas akan menyelesaikannya. :)

Ini tidak menyelesaikan masalah untuk direktori besar .git atau build -- itulah pendekatan yang saya uraikan dalam komentar saya di atas akan menyelesaikannya. :)

Saya tahu ada beberapa alat yang mengandalkan .git , tetapi apakah ada yang mengandalkan build disalin? Itu akan menyenangkan untuk ditambahkan ke direktori yang diabaikan, dengan senang hati mengirim PR jika Anda setuju.

Apakah ini masih diselidiki? Ini adalah kejutan yang sangat menyakitkan untuk melihat beberapa gigabyte dump data debug yang diabaikan git disalin selama pip install .

Ya, lihat masalah terkait seperti #7555.

Masalah ini masih berlanjut, karena direktori tempat saya menginstal mungkin memiliki 10 mb kode python, tetapi kemudian banyak file data json dan .git .

Ini harus diselesaikan dengan #7882 (membangun direktori lokal di tempat).

Kami sekarang (per #7951) telah menerbitkan rilis beta pip, pip 20.1b1. Rilis ini mencakup #7882, yang menerapkan solusi untuk masalah ini.

Saya harap peserta dalam masalah ini akan membantu kami dengan menguji beta dan memeriksa bug baru. Kami ingin mengidentifikasi dan mengatasi masalah potensial apa pun sebelum rilis utama 20.1 pada hari Selasa.

Saya juga menyambut umpan balik positif di sepanjang baris "yay, ini berfungsi lebih baik sekarang!" juga, karena pelacak masalah biasanya penuh dengan "masalah". :)

Saya akan mengatakan bahwa itu jauh lebih baik.

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

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

Bekerja dengan baik/lebih cepat untuk saya! :+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

turun dari ~2 menit menjadi 4 detik, terima kasih banyak!

Terima kasih atas laporan positifnya @PythonCoderAS @astrofrog @klamann! :)

Sayangnya, ada sejumlah masalah dengan penerapan build di tempat (yang dilacak di bawah #7555) yang berarti bahwa untuk saat ini, kita perlu mengembalikan #7882. Akibatnya, masalah ini akan menjadi masalah lagi, dan karena itu kami akan membukanya kembali. Untuk jangka panjang, kami berharap memiliki solusi yang mengatasi masalah yang diselesaikan di tempat, tetapi tanpa berdampak pada alur kerja lain yang dimiliki solusi saat ini.

Mohon maaf atas gangguan yang akan ditimbulkan.

Sayangnya, ada sejumlah masalah dengan penerapan build di tempat

@pradyunsg terima kasih atas pembaruannya. Beberapa umpan balik tentang terminologi (jangan ragu untuk mengabaikan, hanya FYI): kalimat ini, serta gh-7555, membuat saya bingung karena pip tidak melakukan pembuatan di tempat. Apa yang selalu dimaksud dengan build di tempat adalah python setup.py build_ext --inplace (atau python setup.py develop ).

Di sini Anda mengubah artinya menjadi: "membangun tanpa menyalin ke tmpdir". Modul ekstensi masih belum berakhir di tempatnya, mereka berakhir di dir build/ yang biasanya mudah dibersihkan. Akan lebih baik untuk menjadi sedikit lebih eksplisit misalnya gh-7555.

Itu awalnya kata-kata saya. Maaf atas kebingungan apa pun, saya tidak menyadari bahwa setuptools menggunakan istilah "di tempat" untuk mengartikan sesuatu yang berbeda (dan saya masih tidak begitu yakin bagaimana terminologi itu berlaku di luar setuptools). Kami akan melihat apakah kami dapat menemukan istilah yang lebih netral di masa depan (walaupun begitu saja, saya tidak yakin apa - saran diterima dengan senang hati )

Jangan khawatir sama sekali, terima kasih @pfmoore. Saya hanya berpikir saya akan menunjukkannya, karena kebingungan tentang terminologi kadang-kadang dapat mengakibatkan berbicara melewati satu sama lain.

dan saya masih tidak begitu yakin bagaimana terminologi itu berlaku di luar setuptools

Untuk alat seperti CMake dan scikit-build, saya pikir artinya sama: sebenarnya di tempat, binari mendarat di sebelah sumber.

"instalasi yang dapat diedit" di sisi lain (saya percaya) ditemukan di sini, dan agak berarti "di tempat yang diketahui pip".

meskipun begitu saja, saya tidak yakin apa - saran diterima dengan terima kasih

mungkin hanya "build lokal" (vs. "salin ke tmpdir dan bangun" saat ini)?

"instalasi yang dapat diedit" di sisi lain (saya percaya) ditemukan di sini, dan agak berarti "di tempat yang diketahui pip".

Kami baru-baru ini berdiskusi panjang tentang apa artinya instalasi yang dapat diedit, dan saya pikir kami benar-benar mendarat di tempat yang lebih sesuai dengan machine local sejauh pip berjalan. Tetapi pip tidak mengetahui di mana dan bagaimana pada mesin lokal dan apakah tugas backend build untuk mendefinisikan dan menanganinya.

Bisa mencoba «in-tree build» (mirip dengan «in-tree PEP 517 backend») atau «build in source dir»

Pertanyaan saya, mengapa fitur tersebut tidak bersifat opsional, sehingga tidak menimbulkan masalah tetapi dapat diaktifkan dengan argumen atau yang serupa?

Saya mencoba untuk memikirkan solusi untuk ini, di mana instalasi yang dapat diedit bukanlah pilihan. Apakah ada?

Solusinya bisa dengan membuat roda (menggunakan backend build Anda secara langsung) lalu arahkan pip untuk menginstalnya

mengapa fitur tersebut tidak opsional, sehingga tidak menimbulkan masalah tetapi dapat diaktifkan dengan argumen atau yang serupa?

Bisa. Alasan untuk mengembalikan perubahan adalah karena kami tidak memiliki pilihan untuk tidak ikut atau periode untuk mendapatkan umpan balik tentang perubahan tersebut. Kami memiliki tanda baru untuk membantu memfasilitasi itu (--use-feature dan --deprecated-feature), tetapi seseorang harus menerapkan kembali/memperkenalkan kembali fungsionalitas dalam konteks ini sekarang.

Secara garis besar, saya pikir apa yang ingin kita lakukan di sini adalah:

• Tambahkan --use-feature=in-tree-build sebagai keikutsertaan.
• Ganti default di rilis selanjutnya dengan --deprecated-feature=out-of-tree-build sebagai opt-out + mendorong pengguna --use-feature=in-tree-build untuk menjatuhkannya.
• Jatuhkan kedua opsi dalam rilis berikutnya.

Solusinya bisa dengan membuat roda (menggunakan backend build Anda secara langsung) lalu arahkan pip untuk menginstalnya

Saya berpikir tanpa langkah membangun tambahan. Tapi saya kira saya seharusnya tidak pernah berpikir Python bisa lolos tanpa Makefile yang setara sejak awal.