Melihat ini dari perspektif back-end, gagasan "pembangunan di luar pohon" sebenarnya tidak ada artinya. Bagian belakang diberi "pohon sumber" dalam bentuk direktori proses saat ini, dan diminta untuk menjalankan pembangunan. Tidak ada cara untuk mengetahui apakah direktori itu diekstraksi dari sdist, diperiksa dari VCS, atau disalin dari tempat lain. Yang bisa dilakukannya hanyalah membangun, dan jika tidak memiliki apa yang dibutuhkan untuk membangun, laporkan kegagalan.

Sehingga cukup banyak membunuh mungkin solusi (3) IMO - backend tidak memiliki konsep apa di tempat membangun adalah, sehingga tidak dapat mengatakan apakah membangun seperti aman ^1.

Mengenai (2), saya biasanya menentang opsi tambahan seperti ini. Jika kita tahu apa yang terbaik untuk dilakukan, kita harus melakukannya, dan jika tidak, maka meneruskan masalah ke pengguna bukanlah pilihan yang ramah. Masalahnya di sini cukup halus sehingga saya berharap beberapa pengguna tahu apa pilihan yang benar, jadi kita mungkin akan melihat orang hanya mencoba 2 opsi dan secara membabi buta menggunakan "apa pun yang berhasil". Juga, implikasi dukungannya signifikan - menawarkan opsi dengan jelas menyiratkan bahwa kami mengharapkan hasil build berbeda dalam setidaknya beberapa kasus, jadi bagaimana kami menguji bahwa perbedaannya seperti yang kami harapkan? Apakah kami bertanggung jawab untuk mengedukasi pengguna tentang kapan flag build di tempat akan dibutuhkan atau tidak (baik melalui dokumentasi kami, atau sebagai akibat dari masalah yang diajukan oleh pengguna yang tidak tahu mana yang harus digunakan)?

Karena itu, saya tidak menentang pip hanya membangun di tempat. Saya yakin alasan kami tidak melakukannya adalah karena kami memiliki kasus di mana artefak yang tersisa dari build sebelumnya digunakan dalam build berikutnya, tetapi dibuat dengan opsi berbeda (misalnya, file objek yang dibuat dalam mode debug ditautkan ke build rilis dilakukan dari pohon yang sama). Namun, masuk akal untuk mengatakan bahwa backend harus memastikan bahwa masalah seperti ini tidak terjadi, dan jika terjadi, itu adalah bug backend dan tidak siap untuk mencoba mempertahankannya. Namun, saya tidak yakin apakah mengambil sikap seperti itu sangat ramah pengguna - ini muncul selama diskusi PEP 517 di bawah topik pembangunan tambahan, dan cukup kontroversial sehingga ditangguhkan pada saat itu.

Preferensi saya adalah membangun sdist, dan kemudian membangun roda dari itu, untuk waktu yang lama sekarang (opsi Anda 1). Saya setuju dengan pembuatan pip di tempat (jika kita dapat setuju bahwa melakukannya aman, mengingat seperti yang saya sebutkan di atas, kita tidak dapat mengharapkan back-end untuk memberi tahu kami), tetapi saya pikir itu akan membutuhkan komunitas diskusi untuk membahas implikasi yang lebih luas (pada backend, pip/frontend dan pengguna akhir).

¹ Tentu saja mungkin untuk memperbarui PEP 517 untuk mendefinisikan apa yang merupakan pohon sumber "di tempat" sebagai lawan dari bangunan "di luar pohon", tetapi saya menduga itu akan menjadi konsep yang sangat sulit untuk dijabarkan.

Saya menambahkan solusi 4. (Ubah pip untuk selalu membangun di tempat) dan 5. (Ubah pip untuk membangun di tempat secara default dengan opsi untuk membangun di luar pohon).

Saya memiliki perasaan campur aduk tentang membangun melalui sdist (solusi 1.) karena alasan berikut:

1. beberapa proyek mungkin memiliki jalur sdist-to-wheel yang rusak; sementara saya melihat nilai memvalidasi bahwa bangunan dari sdists berfungsi, melakukannya secara default sekarang pasti akan merusak banyak bangunan pengguna akhir
2. itu masih memiliki implikasi kinerja untuk proyek dengan sdist besar, dan karena panggilan subproses tambahan
3. Saya pribadi berpikir kita tidak boleh terlalu menekankan sdists karena cukup umum untuk proyek untuk menerbitkan artefak yang dibangun dan merujuk ke platform hosting kode favorit mereka untuk rilis sumber mereka (misalnya, backend yang mengandalkan kehadiran checkout VCS untuk bangunan perlu melompati lingkaran untuk menghasilkan sdist yang berfungsi). Dan PEP 517 secara khusus memungkinkan backend untuk meningkatkan UnsupportedOperation untuk build_sdist .

Posting tentang diskusi ini juga merangkum argumen serupa.

Saya setuju jalan untuk solusi 3. masih jauh dari jelas.

Saya juga setuju kita harus menghindari opsi tambahan jika kita bisa.

Saya juga mencatat ada beberapa suara yang mendukung pembangunan di tempat di utas diskusi yang ditautkan, tetapi memang diskusi komunitas yang terfokus pada subjek tertentu diperlukan jika kita ingin menjelajahi pendekatan itu.

• Bangun sdist di tempatnya, buka sdist di lokasi sementara, lalu buat dari itu.

Saya pikir ini adalah pendekatan yang baik.

Kemungkinan IMO adalah, ini akan dijalankan untuk satu paket di sebagian besar pip install menjalankan yang melibatkan direktori lokal -- paling sering saya membayangkan pip install . . Ini akan dilakukan kemungkinan sebagai bagian dari alur kerja pengembangan paket.

Inilah yang menurut saya perilaku ini seharusnya:

• Jika backend tidak dapat membuat sdist, lakukan local-dir -> wheel (di tempat)
  
  
  
  • Saya pikir tanggung jawab sangat banyak di backend untuk memastikan bahwa local-dir -> wheel adalah operasi idempoten dalam kasus ini.
  
  
• Jika backend mampu membuat sdist, lakukan local-dir -> sdist -> unpacked-sdist -> wheel.

Melakukan local-dir -> sdist -> wheel, kami memiliki satu set panggilan tambahan. Namun, saya pikir masuk akal untuk memvalidasi bahwa sdist yang dihasilkan waras, terutama selama pengembangan. tox sudah melakukan ini sebagai bagian dari alur kerjanya, periksa manifes untuk menutupi antarmuka yang tidak begitu ramah setuptools di sini.

Secara keseluruhan, saya pikir biaya membangun sdist ketika diberikan direktori lokal sepadan untuk mencegah kesalahan seperti itu dalam proyek, terutama karena orang yang menginstal dari direktori lokal kemungkinan adalah pengembang proyek itu sendiri.

Mengenai peluncuran, saya pikir kita ingin menunggu dan melihat bagaimana #6536 muncul. Kami pasti akan mempelajari beberapa hal yang dapat ditransfer.

Saya lebih suka membangun/menginstal di tempat tanpa sdist (jadi setup.py install atau setup.py bdist_wheel atau memanggil build_wheel pada backend PEP 517 sebagaimana berlaku) vs membangun sdist, membongkar, dan menginstal dari itu. Alasan spesifik saya adalah:

1. Mendukung jumlah pengguna terbesar di luar kotak.
   
   
   
   1. Asumsikan pip melakukan local-dir -> diinstal (melalui wheel build in-place atau setup.py install ). Pengguna yang ingin pergi dari local-dir -> diinstal dapat mengeksekusi pip install local-dir . Pengguna yang ingin pergi dari local-dir -> sdist -> terinstal bebas untuk membuat sdist dan kemudian menjalankan pip install ./path/to/sdist . Ada banyak alat alternatif yang dapat membangun sdist, dan ini adalah sesuatu yang kemungkinan besar akan dimiliki pengguna kecuali mereka membuat sendiri distribusi yang mereka unggah ke PyPI.
   
   
   2. Sekarang asumsikan pip melakukan local-dir -> sdist -> diinstal. Pengguna yang ingin pergi dari direktori lokal -> diinstal tidak memiliki opsi yang melibatkan pip. Pengguna yang ingin pergi dari local-dir -> sdist -> diinstal dapat mengeksekusi pip install local-dir . Pengguna tanpa opsi akan meminta pip untuk opsi untuk mengontrol perilaku atau harus menemukan alat lain yang tidak mereka butuhkan.
   
   
2. Jika kita mengimplementasikan local-dir -> sdist -> terinstal, mungkin kita juga akan melakukannya untuk kebutuhan berbasis VCS? Jika demikian itu lebih banyak pekerjaan. Jika tidak, itu adalah jalur tambahan melalui kode dan penyimpangan dalam cara penanganan instalasi yang harus diingat oleh pengguna atau saat memberikan dukungan.
3. Sedikitnya jumlah pekerjaan yang harus dilaksanakan. Ada tiga tempat yang harus diubah untuk mengimplementasikan local-dir -> diinstal ( di sini , di sini , dan di sini ). Untuk local-dir -> sdist -> diinstal, saya bahkan tidak ingin menyentuh implementasi ini sampai #6607 selesai, jika tidak, saya pikir itu akan berakhir di banyak tempat di basis kode yang mirip dengan pengunduhan artefak/pemeriksaan hash.
4. Jumlah pekerjaan yang paling sedikit untuk diuji karena, IMO, pengujian yang ada cukup untuk mencakup direktori lokal -> jalur kode yang diinstal. Untuk jalur lokal-dir -> sdist -> terinstal, kami ingin memverifikasi bahwa kami benar-benar membangun sdist, dan bahwa fallback berfungsi untuk membuat roda secara langsung.
5. Jumlah pekerjaan paling sedikit (secara komputasi). Seperti disebutkan di tempat lain, local-dir -> sdist -> diinstal adalah panggilan sub-proses tambahan (dan sub-proses itu bekerja). Ini juga berarti pip harus membongkar sdist (halo pemindai virus dan disk yang lambat) sebelum melakukan pembuatan roda.

Terlepas dari pendekatannya, satu-satunya masalah yang saya lihat dengan melakukan sesuatu di tempat adalah bahwa untuk setuptools build (saya pikir ini berlaku untuk legacy dan PEP 517) kita akan berakhir dengan .egg-info di direktori proyek yang akan salah sebagai "paket terinstal" ketika pip dipanggil dengan python -m pip di direktori itu. Ini akan diperbaiki oleh #4575 yang mungkin TIDAK menyertakan direktori saat ini dalam kueri untuk paket yang diinstal untuk skema apa pun.

Memperhatikan bahwa saya telah tumbuh untuk setuju bahwa gagasan untuk melewatkan sdist build dan langsung melakukan in-tree build adalah pendekatan yang lebih baik untuk diambil pip secara default, dan tidak mencoba melakukan local-dir -> sdist -> wheel.

Di Fedora, ketika kami membuat paket Python RPM, kami adalah dinosaurus dan cara standar untuk melakukan thins adalah dengan menggunakan python setup.py build . Dengan PEP 517 kami menambahkan cara "sementara" menggunakan pip wheel sebagai gantinya. Namun dengan modul ekstensi, kami memiliki masalah dengan pendekatan "pindahkan sumber ke tmp, bangun dari sana" yang digunakan pip untuk membangunnya.

Mesin build kami menyuntikkan beberapa flag compiler sehingga artefak build ( modul ekstensi .so dalam kasus ini) berisi metadata tentang sumbernya. Kemudian ada skrip shell yang melintasi artefak build, mengekstrak informasi ini dan menyalin sumber ke /usr/src/debug untuk diinstal melalui RPM *-debugsource . Mahcinery mengharapkan semuanya dibangun di dalam pohon kerja dan itu tidak benar-benar berfungsi dengan baik saat dibangun di luar. Berikut adalah hal-hal yang dapat dilakukan (bersama-sama) untuk mengurangi masalah di pihak kita:

1. atur variabel lingkungan $TMPDIR agar berada di tempat yang diharapkan oleh skrip RPM (yaitu export TMPDIR=%{_builddir}/.tmp (dan buat))
2. gunakan pip wheel dengan opsi --no-clean untuk menyimpan sumber yang disalin di $TMPDIR
3. jalankan beberapa shell kung fu untuk menulis ulang informasi "apa sumber saya" ke lokasi yang benar: 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. (Opsional: bersihkan $TMPDIR secara manual.)

Kami tidak terlalu menyukai langkah ketiga karena ini bergantung pada terlalu banyak detail implementasi:

• /usr/lib/rpm/debugedit API dan lokasi (dan keberadaan)
• nama pip-req-build
• mekanisme yang digunakan pip untuk membangun sumber

Jika pip akan selalu dibangun di tempat atau jika akan ada sakelar baris perintah untuk ini, masalahnya akan hilang.

Laporan hilir: https://bugzilla.redhat.com/show_bug.cgi?id=1806625

Memperhatikan bahwa saya telah tumbuh untuk setuju bahwa gagasan untuk melewatkan sdist build dan langsung melakukan in-tree build adalah pendekatan yang lebih baik untuk diambil pip secara default, dan tidak mencoba melakukan local-dir -> sdist -> wheel.

Saya juga menjadi lebih cenderung menerima gagasan untuk membuat roda di tempat. Reservasi saya yang tersisa adalah:

1. Kami akan mengandalkan backend yang berperilaku "benar" - misalnya, tidak memberikan hasil yang berbeda berdasarkan data sisa dari build sebelumnya, atau apa pun. Saya baik-baik saja dengan membuat asumsi itu, tetapi saya khawatir tentang biaya dukungan jika kita mulai membuat orang mengatakan "pip membuat roda saya salah" dan kami harus men-debug hanya untuk menemukan bahwa itu adalah masalah backend.
2. Saya pikir pendekatan apa pun yang kita ambil, kita harus mendokumentasikannya dengan sangat jelas dan eksplisit, dan melakukan upaya yang kuat untuk sepenuhnya beralih ke sana. Kami benar-benar tidak ingin menambahkan "pendekatan lain" ke pip sambil meninggalkan semua kode lama untuk kompatibilitas. Jika kami tidak dapat berkomitmen pada pendekatan baru, kami hanya memperkenalkan lebih banyak masalah pemeliharaan.
3. Sebagai akibat wajar dari hal di atas, kita harus memastikan tidak ada proyek yang kita ketahui yang bergantung pada pendekatan "salin dan bangun" kita saat ini, seolah-olah ada yang akan kita hancurkan dengan perubahan ini.

... dan tentu saja seseorang perlu menulis PR yang mengimplementasikan perubahan ini (dengan tes, dokumen, dll - hal-hal biasa) jika tidak, yang kami lakukan hanyalah berbicara

Kami akan mengandalkan backend yang berperilaku "benar" - misalnya, tidak memberikan hasil yang berbeda berdasarkan data sisa dari build sebelumnya, atau apa pun. Saya baik-baik saja dengan membuat asumsi itu, tetapi saya khawatir tentang biaya dukungan jika kita mulai membuat orang mengatakan "pip membuat roda saya salah" dan kami harus men-debug hanya untuk menemukan bahwa itu adalah masalah backend.

Apakah masuk akal untuk memperluas antarmuka PEP 517 untuk menyertakan kait "bersih"? Kami mungkin menginginkannya sebagai titik tertentu untuk memungkinkan upaya lain (misalnya menerapkan instalasi yang dapat diedit, membangun alat pengembangan paket yang membangun proyek PEP 517). pip dapat memanggilnya di sini untuk memastikan tidak ada sampah yang tersisa sebelum melakukan in-tree build.

Apakah masuk akal untuk memperluas antarmuka PEP 517 untuk menyertakan kait "bersih"?

Mungkin? Tetapi jika pip secara otomatis panggilan clean , ada pasti menjadi seseorang yang ingin tidak melakukannya, lakukan bertahap membangun atau sesuatu. Dan kemudian kita berakhir dengan pilihan lain.

Kecenderungan saya adalah untuk tetap pada posisi saya "kita harus dapat berasumsi bahwa itu adalah tanggung jawab backend untuk memastikan bahwa build di tempat bekerja dengan benar". Bahkan jika itu ternyata tidak dapat dipertahankan, mendapatkan contoh nyata mengapa itu tidak berhasil akan membantu kita lebih memahami apa yang harus dilakukan tentang masalah tersebut, daripada hanya menebak-nebak.

1. Kami akan mengandalkan backend yang berperilaku "benar" - misalnya, tidak memberikan hasil yang berbeda berdasarkan data sisa dari build sebelumnya, atau apa pun.

Saya akan tergoda untuk memperluas PEP-517 untuk menjadikan ini sebagai persyaratan eksplisit.

Saya akan tergoda untuk memperluas PEP-517 untuk menjadikan ini sebagai persyaratan eksplisit.

Ini sudah mengatakan ini:

Backend dapat menyimpan artefak perantara di lokasi cache atau direktori sementara. Ada atau tidak adanya cache tidak boleh membuat perbedaan material pada hasil akhir pembangunan.

Bukan karena backend cenderung melanggar persyaratan ini dengan sengaja, karena pengguna secara alami akan melaporkan masalah tersebut sebagai masalah pip, dan dialihkan ke proyek backend, yang merupakan sedikit biaya tambahan.

Saat mencoba mencari solusi untuk Fedora, kami telah terkena https://github.com/pypa/pip/issues/7872

Karena kami telah menyelesaikan masalah ".egg-info in cwd" dengan #7731 dan teman-teman, itu adalah satu hal yang perlu dikhawatirkan saat membangun di tempat.

Jadi opsi 4 (selalu dibangun di tempat) diimplementasikan di #7882 .

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". :)

Kami benar-benar berencana untuk mengujinya di Fedora (kami sudah merencanakannya sebelum komentar Anda), namun batas waktu hari Selasa mungkin tidak realistis.

@hroncok Adakah ide kapan Fedora dapat menguji perubahan ini?

Saya akan mencoba yang terbaik untuk melakukannya pada hari Senin, namun saya tidak bisa berjanji.

Memang, 20.1b1 membuat masalah kita hilang.

Umpan balik 20.1b1 yang lebih umum di https://mail.python.org/archives/list/[email protected]/message/5EAUIYYIRKXEHTAG5GQ7EJHSXGZIW2F7/

Hore! Terima kasih banyak telah mencoba beta @hroncok! Sangat dihargai! ^>^

Salah satu hasil dari build in place: Saya telah membangun roda untuk beberapa versi python secara paralel (di dalam wadah buruh pelabuhan manylinux). Dengan build di tempat, build paralel tidak berfungsi karena konflik versi yang berbeda. Dengan build out-of-tree, setiap versi membuat pohon terpisah dan tidak ada masalah.

@manthey diskusi itu di bawah #8168

Jadi sudah lebih dari 10 hari sekarang. Ada beberapa masalah yang diangkat tentang perubahan (semua yang diharapkan menurut saya - #8165, #8168, #8196). Ada juga orang yang secara eksplisit menyebutkan perubahan itu membantu mereka.

• Selain masalah kinerja, perilaku sebelumnya (salin ke temp dir) memiliki masalah kebenaran (ditautkan di atas) yang tidak mungkin diperbaiki dengan pip tanpa pengetahuan konteks yang hanya dimiliki penelepon (dan, sebagai catatan tambahan, kode copytree itu sudah penuh dengan band-aids untuk mengatasi situasi aneh - tmpdir di pohon, soket, dll).
• Opsi untuk mengaktifkan perilaku sebelumnya masih memiliki masalah kebenaran dan kinerja.
• Solusi yang benar akan melibatkan dukungan back-end build untuk mengontrol direktori build yang tidak sepenuhnya ada saat ini (misalnya, setuptools bdist_wheel memiliki --bdist-dir , tetapi masih menulis .egg-info di tempat, lihat juga https://github.com/pypa/setuptools/issues/1816, https://github.com/pypa/setuptools/issues/1825). Jadi sekarang pip berperilaku dengan benar mungkin diskusi dapat bergeser untuk melihat apakah, misalnya, setuptools dapat mengembangkan opsi untuk melakukan pembangunan tanpa menyentuh direktori sumber dan kemudian melihat apakah perubahan PEP 517 diperlukan atau tidak untuk mengontrol opsi itu.
• Sementara itu masalah yang dilaporkan mungkin relatif mudah untuk diselesaikan oleh penelepon (misalnya dengan menyalin diri mereka sendiri ke direktori sementara, atau membuat tarball sementara, yang dapat mereka lakukan dengan benar dengan pengetahuan penuh tentang konteksnya).
• Terakhir, sulit untuk memastikan dengan pasti dengan data yang kami miliki, tetapi intuisi saya adalah bahwa perubahan ini membantu lebih banyak orang daripada menyakitkan.

Jadi saya benci melanggar perubahan, tetapi yang ini tidak dilakukan dengan mudah, dan untuk alasan ini, saya pribadi cenderung untuk menyimpannya.

Saya tidak setuju bahwa perilaku baru adalah pip yang berperilaku "benar", tentu saja berbeda, dan tampaknya dalam beberapa kasus rusak secara berbeda dan saya pikir membingkainya seperti itu tidak benar. Ini mewakili tradeoff untuk satu set pengguna yang rusak untuk set yang berbeda, dalam kedua kasus di sini ada solusi yang bisa dilakukan.

Saya tidak akan menggabungkan perubahan ini dan melewatkannya atau saya akan menentangnya (dan saya pikir sekarang setelah menggabungkannya, itu membuat beberapa orang menggunakan pip sebagai fungsi pemaksaan untuk membantu mencegah beberapa jenis paket yang rusak secara signifikan lebih sulit ). Karena itu, saya tidak benar-benar tahu apakah pengembalian adalah hal yang benar di sini. Itu bisa menjadi lebih membingungkan bagi pengguna jika perilaku sering berubah-ubah. Jika kita akan kembali, kita harus melakukannya dengan cepat, jika tidak maka perilaku saat ini mungkin akan menjadi lebih baik atau lebih buruk.

Saya menggunakan istilah "dengan benar", karena sebelum pip wheel <localdir> dan pip install <localdir> menghasilkan roda yang berbeda dari cd <localdir> ; setup.py bdist_wheel dalam beberapa kasus: dengan berbagai file yang hilang di hadapan symlink (# 3500), atau versi lain dengan setuptools_scm (#7549), atau https://github.com/pypa/pip/issues/7555#issuecomment -595180864, ​​atau #6276, atau kesalahan biasa. Saya tidak berpikir pip 20.1 menghasilkan roda/pemasangan yang buruk, jadi dalam hal itu saya percaya itu memang lebih benar.

Tentu saja kami tahu bahwa perubahan akan merusak beberapa alur kerja dan tradeoff harus dievaluasi kembali sekarang setelah kami memiliki umpan balik, dan dikembalikan atau dikonfirmasi untuk selamanya.

Dan itu masih bisa menghasilkan roda yang berbeda dari setup.py sdist && pip install dist/*.tar.gz .

Saran saya adalah mengembalikan PR dan menerapkan perbaikan dengan terlebih dahulu mengocok melalui sdist dan kemudian membangun roda dari sdist yang dihasilkan.

Ini harus menyelesaikan semua masalah kebenaran kecuali jika proyek tidak mampu membangun sdist dengan benar dan itu, IMO, bukan kasus penggunaan yang penting untuk dipecahkan.

Trade off di sana adalah bahwa itu akan lebih lambat. Namun, setelah kami menerapkannya, kami selanjutnya dapat menyempurnakan antarmuka PEP 517 untuk menambahkan API opsional yang memungkinkan peningkatan kecepatan. Itu kemungkinan tidak akan pernah secepat perubahan ini, tetapi kita pasti bisa lebih dekat dengannya.

Perubahan ini membuat secara efektif tidak mungkin untuk lebih mendorong jarum pada kebenaran tanpa memperkenalkan regresi kinerja yang tidak mungkin disukai pengguna. Namun jika kita melakukannya dengan benar dan kemudian meningkatkan dengan kinerja, kita bisa sampai pada jalan tengah yang memuaskan kedua belah pihak.

Seperti pepatah lama, perbaiki dulu, lalu cepat. Saya khawatir dengan PR ini kami membuatnya cepat dan mengunci kemampuan kami untuk memperbaikinya.

Saya masih setuju memvalidasi sdists diinginkan tetapi tidak pada waktu pemasangan pip. Mungkin itu fitur untuk alat pembuat sdist masa depan atau perintah pembuatan pip.

Juga, setup.py sdist membuat .egg-info di direktori lokal, sehingga masalah yang dilaporkan dengan direktori sumber hanya-baca atau build bersamaan akan tetap ada.

Jika itu tidak terjadi pada waktu pemasangan pip, itu secara fungsional tidak terjadi sampai waktu pemasangan pip orang lain. Melewatkannya berarti kita memiliki banyak jalur yang dapat dilalui proyek dari VCS ke paket yang diinstal dan setiap jalur adalah peluang lain untuk perbedaan. Ini bukan hal baru, pada dasarnya setiap opsi yang kami miliki yang mengubah jalur penginstalan berakhir dengan kumpulan byte yang berbeda pada disk, bahkan untuk proyek yang paling sulit sekalipun. Perbedaan halus selalu ada dan Anda hanya berharap perbedaan itu tidak berarti— atau Anda dapat melakukan apa yang Anda bisa untuk menghilangkan perbedaan itu dengan secara struktural membuatnya mustahil untuk memilikinya sejak awal.

Beberapa masalah kinerja memang dapat muncul kembali jika/ketika membangun melalui sdist tetapi mereka mungkin akan menjadi urutan besarnya lebih rendah dari apa yang kami miliki di pip <20.1. Memang sebagian besar sering keluar dari menyalin .git , atau venv , atau hal-hal besar lainnya yang tidak terkait yang tidak akan ada di sdist.

Terlepas dari apa pip akhirnya akan berakhir, dapatkah kita menjadikan yang lain sebagai pilihan, karena tidak mungkin keduanya dapat memuaskan semua orang? Saya membayangkan bahwa jika pendekatan saat ini dipertahankan (saya tidak benar-benar memiliki pendapat tentang mana yang harus menjadi default), kita harus dapat memberikan fallback hasil terakhir di mana pengguna dapat memilih untuk membuat sdist dan menginstal paket dari sana.

Juga, setup.py sdist membuat .egg-info di direktori lokal, sehingga masalah yang dilaporkan dengan direktori sumber hanya-baca atau build bersamaan akan tetap ada.

Saya pikir (setidaknya tes cepat setuju dengan saya) bahwa hanya setuptools (bukan distutils ) yang melakukannya, dan perilaku ini dapat dikonfigurasi untuk membuat direktori di tempat lain. Serupa dengan backend lainnya, kita harus bisa merekomendasikan mereka untuk melakukan clean sdist generation.

FWIW, saya rasa kita tidak perlu membuang direktori --egg-info generasi sdist ke direktori kerja, jika kita menggunakan pendekatan generate-sdist-unpack-it-build-wheel, karena kita bisa membuangnya ke direktori sementara, seperti yang kita lakukan untuk generate_metadata .

@pradyunsg apakah itu tidak memerlukan perubahan di setuptools? Terakhir kali saya memeriksa perintah sdist tidak memiliki opsi untuk menentukan lokasi dasar .egg-info , sebaliknya untuk egg_info yang memiliki opsi --egg-base yang kami manfaatkan di #7978.

Memang! Saya melihat file yang salah di setuptools. Saya berdiri dikoreksi.

Mengapa semuanya begitu rumit di ruang ini? :(

$  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 ini terasa seperti bug penghentian pertunjukan yang bagus, bisa dibilang bukan bug kami tetapi ini adalah salah satu jenis bug yang menurut saya akan terjadi selama diskusi PEP 517 ketika melakukan di tempat membangun secara default muncul.

bdist_wheel telah diminta untuk membersihkan direktori build-nya secara otomatis di masa lalu. Fitur itu harus masuk. Apakah distutil lain dibuat bersih?

Jika itu adalah SCons, ia akan mengingat file yang dipedulikannya dan akan menghilangkan file tambahan di direktori build/ dari roda meskipun mereka ada di sistem file.

Saya percaya masalah di atas tidak hanya mempengaruhi banyak linux. Itu harus terjadi kapan saja direktori build tidak cukup spesifik untuk menangkap ABI (dalam kasus setuptools, tampaknya platform dan versi python adalah semua yang ditangkap dalam tag ABI di direktori build). Saya pikir ini melampaui ABI dengan juru bahasa saat ini juga, jika sesuatu terhubung ke NumPy misalnya, saya pikir itu memiliki ABI yang akan bekerja pada NumPy yang lebih baru, tetapi tidak yang lebih lama, dan kecuali mereka menyandikannya dalam penamaan direktori build maka ini akan efek menggunakan seperti itu juga.

Membersihkan direktori build secara otomatis tidak menyelesaikan masalah, itu hanya membuatnya lebih kecil kemungkinannya (misalnya menjalankan dua pemanggilan pip wheel secara paralel masih dapat memicu masalah), selain itu salah satu alasan yang seharusnya untuk penerapan dengan cara ini (setidaknya selama diskusi PEP 517) adalah bahwa ini akan memberikan lebih banyak kinerja dengan memungkinkan caching di antara pemanggilan untuk build tambahan. TAPI perilaku saat ini adalah apa yang diinginkan beberapa subset, menggunakan kembali artefak build di antara proses, kebetulan bahwa sejauh ini backend build yang paling umum membuatnya sangat salah (dan bisa dibilang dalam beberapa kasus tidak memiliki informasi yang cukup untuk memperbaikinya tanpa per kustomisasi paket).

Tentu saja dengan flag yang cukup ke perintah setuptools mendasarinya, Anda dapat memperbaiki ini (sesuatu seperti py setup.py egg_info --egg-base /tmp/foo build --build-base /tmp/foo/build-base bdist_wheel --bdist-dir /tmp/foo/bdist akan melakukannya).

Saya akan tegaskan kembali bahwa masalahnya bukan pada file tambahan, itu adalah bahwa ABI yang diharapkan yang kompatibel dengan roda berubah, dan .so tidak dibangun kembali. Jika SCons cukup pintar untuk mengetahui bahwa Python yang dibangun dengan pymalloc membutuhkan satu direktori build dan Python dibangun dengan yang lain (termasuk hal-hal seperti versi NumPy yang mungkin ditautkan .so ) maka itu tidak terpengaruh. Jika itu akan menggunakan kembali artefak yang dibuat sebelumnya dengan ABI yang berbeda maka itu akan terpengaruh.

Saya mencoba menguji encon tetapi saya tidak bisa membuat rsalette untuk membangun sama sekali tanpa kesalahan.

Saya mencoba menguji scikit-build untuk melihat bagaimana ia menangani build inkremental, dan apa pun yang saya lakukan, itu akan memuntahkan dirinya sendiri pada build ke-2 dan saya harus menghapus direktori _skbuild secara manual setiap kali untuk mendapatkannya berjalan tanpa kesalahan.

Dingin. Maaf sayangnya encons telah diperbarui dan rsalette belum.

Pada Rabu, 6 Mei 2020, pukul 16:18, Donald Stufft menulis:

Saya mencoba menguji encon tetapi saya tidak bisa membuat rsalette untuk membangun sama sekali tanpa kesalahan.

Saya mencoba menguji scikit-build untuk melihat bagaimana ia menangani build inkremental, dan apa pun yang saya lakukan, itu akan memuntahkan dirinya sendiri pada build ke-2 dan saya harus menghapus direktori _skbuild secara manual setiap kali untuk mendapatkannya berjalan tanpa kesalahan.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub https://github.com/pypa/pip/issues/7555#issuecomment-624867490 , atau berhenti berlangganan https://github.com/notifications/unsubscribe-auth/AABSZERIEDAPUIXCPAKBBUDRQHAXRANCNFSM4KCV5MHQ .

Maaf sayangnya encons telah diperbarui dan rsalette belum.

Apakah ada C ext yang bagus yang menggunakan encon yang diperbarui? Saya baru saja memilih rsalette karena itu yang pertama dalam daftar dan tidak ingin men-debug-nya, senang mencoba dengan yang lain.

Satu-satunya masalah dengan rsalette adalah bahwa ia tidak boleh meneruskan ROOT_IS_PURELIB ke Lingkungan di SConstruct. Itu tidak memiliki ekstensi C. cryptacular terlihat baik-baik saja.

#8165 (komentar)

Dengan ini, saya pikir saya setuju bahwa kita harus mengembalikan perubahan ini.

Saya pikir masalah baru jauh lebih besar dari yang diantisipasi. Mungkin 20.1.1 cepat untuk dikembalikan dan kemudian kita dapat berdiskusi lebih lama tentang bagaimana menyelesaikan masalah pembangunan in-tree dan out-of-tree?

Saya juga memilih untuk mengembalikan dan mengejar https://discuss.python.org/t/proposal-adding-a-persistent-cache-directory-to-pep-517-hooks/2303/15 sebagai solusi untuk ini (yang akan izinkan backend untuk membangun tidak di tempat, jadi jangan mengekspos masalah seperti itu). Ikuti utas itu juga jika Anda setuju dengan saran di sana.

Itu tampaknya masuk akal juga bagi saya. Saya pikir pendekatan in-tree (atau build-from-sdist) memiliki beberapa manfaat yang sangat signifikan (saya cukup yakin kita akan mendapatkan keluhan dari bagian basis pengguna ketika kita mengembalikan ) tetapi kerugiannya juga penting.

Saya tidak jelas UI apa yang harus ada di sini (default untuk pendekatan yang mana? opsi seperti apa yang harus kita miliki?) tetapi saya pikir kita harus mengambil sedikit lebih banyak waktu untuk memutuskan itu, daripada membuat keputusan saat memadamkan masalah saat ini .

Baiklah! Saya pikir konsensus umum adalah untuk kembali dan menilai kembali. Saya akan mengajukan PR untuk ini. :)

Ikuti utas itu juga jika Anda setuju dengan saran di sana.

Tolong lakukan - Saya telah berkomentar, tetapi saya sampai pada titik di mana saya tidak cukup tahu untuk menawarkan saran yang berarti, jadi masukan dari orang-orang yang lebih berpengalaman akan sangat berharga.

Baru saja menjatuhkan beberapa gumpalan besar-teks di https://github.com/pypa/pip/issues/8165#issuecomment -625401463. Saya akan pergi untuk hari ini sekarang ... Saya akhirnya merasa sedikit frustrasi saat menulis catatan pribadi di akhir. Berakhir di #5599 dan membaca komentar negatif pengguna tentu saja tidak membantu.

Hai teman-teman, saya memikirkan hal ini lagi, inilah sudut pandang saya saat ini tentang masalah ini.

1. Bangun sdist di tempatnya, buka sdist di lokasi sementara, lalu buat dari itu.

Saya masih percaya pip install / pip wheel bukanlah tempat yang tepat untuk mencoba dan menangkap sdist yang buruk. Bukankah itu seharusnya menjadi tanggung jawab back-end untuk tidak membuat sdist buruk sejak awal? Selain itu, menurut saya build tanpa syarat melalui sdist mungkin sama mengganggunya dengan build di tempat.

1. Tambahkan opsi pip untuk membangun di tempat.

Yang saya suka jangka pendek terbaik, karena solusi 4 tidak berhasil. Apakah terlalu dini untuk menambahkannya di pip 20.1.1?

1. Perbarui PEP 517 dengan semacam mekanisme untuk memungkinkan back-end berkomunikasi dengan front-end jika mereka "aman" untuk build di tempat.

Dengan pip ini masih perlu kembali ke copytree yang rusak dan tidak dapat diperbaiki jadi saya tidak mendukung yang ini.

1. Ubah pip untuk selalu membangun di tempat.

Jadi yang ini dianggap terlalu mengganggu dan kami akan kembalikan di 20.1.1.

1. Ubah pip menjadi build in place secara default dengan opsi build out-of-tree.

Itu bisa menjadi target jangka panjang, opsi untuk membangun blending out-of-tree dengan konsep direktori cache?

Saya sangat tidak suka opsi CLI, terutama yang seperti ini. Bagaimana jika saya mencantumkan dua paket yang ada di FS lokal saya dan saya perlu membangun satu di tempat dan satu tidak? Jika kami memberikan opsi untuk melakukan satu atau yang lain, akan ada paket yang ada yang hanya dapat dibangun dengan satu atau yang lain.

Bagi saya itu juga berbau seperti jenis opsi yang ada sepenuhnya karena sebuah proyek tidak dapat mengambil keputusan, dan memutuskan untuk mendorong keputusan itu ke pengguna akhir.

Membangun melalui sdist tidak sepenuhnya tentang menangkap sdist yang buruk. Sebagian besar tujuannya adalah mengurangi kemungkinan variasi "jalur" yang dapat dilalui proyek sebelum akhirnya diinstal. Menambahkan bendera dalam beberapa hal membuat masalah itu lebih buruk bukan lebih baik.

Maksud saya, kami memiliki beberapa "jalur" yang dapat dilalui oleh penginstalan:

1. VCS -> Sdist -> Roda -> Terpasang
2. VCS -> Roda -> Terpasang
3. VCS -> Terpasang (Legacy)

Ada beberapa jalur tambahan yang agak dihapus, tetapi secara umum itu adalah 3 kami (dan idealnya 3 juga dihapus). Ada juga pemasangan yang dapat diedit tetapi tidak akan dihapus dalam waktu dekat.

Kami dapat mempertimbangkan sdist atau roda yang diunggah ke PyPI dan diinstal dari itu hingga menjadi bagian dari "jalur" yang sama, Anda hanya menjeda dan menyelesaikannya di komputer lain.

Masalah dengan memiliki banyak "jalur" seperti ini, apakah ini menimbulkan inkonsistensi dalam hasil akhir pemasangan. Mereka tidak selalu terjadi, tetapi ini adalah kasus yang mudah diamati dan sering terjadi. Seringkali ketidakkonsistenan ini bukan masalah besar, tetapi terkadang memang demikian.

Jika kita melakukan pembangunan di tempat seperti ini, maka kita secara efektif mengatakan bahwa kita tidak akan pernah bisa runtuh ke satu jalur, dan kita selalu harus berurusan dengan kasus tepi aneh ini di mana kadang-kadang orang akan mendapatkan hasil yang berbeda berdasarkan cara penginstalan dilakukan.

Sebagai manfaat tambahan, ini juga dapat bertindak sebagai fungsi pemaksaan untuk membantu memastikan bahwa jalan bahagia tetap bahagia.

Sebagian besar saya setuju dengan @dstufft , dan khususnya saya setuju bahwa pendekatan build-from-sdist harus dilihat bukan sebagai "mencoba memvalidasi sdists" tetapi sebagai "semuanya mengikuti "pohon sumber -> sdist -> wheel -> install route (hanya beberapa hal yang melewatkan beberapa langkah awal)".

Namun, saya ingin mengambil satu poin:

Bagaimana jika saya mencantumkan dua paket yang ada di FS lokal saya dan saya perlu membangun satu di tempat dan satu tidak?

Jalankan saja dua paket dalam dua proses pip yang terpisah dengan opsi berbeda?!? Saya tahu mungkin yang satu adalah ketergantungan yang lain dan poin Anda secara umum berlaku, Tetapi tampaknya ada kecenderungan umum bagi orang untuk berasumsi bahwa setiap skenario pemasangan harus diciutkan menjadi satu putaran pip, dan saya tidak' menurut saya itu masuk akal (kami memiliki solusi yang sangat baik untuk masalah yang ditolak oleh pengguna karena "itu berarti saya harus membagi daftar persyaratan saya menjadi dua")

Perhatikan bahwa ketika (jika) kita kembali, kita harus membuka kembali masalah seperti #6276 yang ditutup sebagai akibat dari implementasi in-tree build.

Sebagian dari masalahnya adalah pip tidak mempertimbangkan apa yang sudah diinstal saat menyelesaikan dependensi (saya tidak yakin apakah penyelesai baru berfungsi mengubahnya?) dependensi "dengan benar" (sejauh resolver kami saat ini melakukan sesuatu dengan benar).

Jika resolver baru memperhitungkan apa yang sudah diinstal, maka pip install foo bar dan pip install foo && pip install bar kira-kira sama dan tidak masalah sama sekali, tetapi jika tidak (dan hal yang sama kira-kira benar sekarang) jika kedua proyek bergantung pada "spam" tetapi foo diperlukan <2 dan bilah diperlukan> 1 maka kami akan mendapatkan instalasi yang tidak valid.

Itu tangen meskipun :)

(Saya tidak yakin apakah penyelesai baru berfungsi mengubahnya?)

Masukan diterima di #7744. :)

1. Ubah pip untuk selalu membangun di tempat.

Jadi yang ini dianggap terlalu mengganggu dan kami akan kembalikan di 20.1.1.

Untuk lebih jelasnya, kami juga "meluncurkannya terlalu cepat" dan pendekatan peluncuran yang kami ambil jelas merupakan bagian dari mengapa ini akhirnya menjadi terlalu mengganggu.

1. Tambahkan opsi pip untuk membangun di tempat.

@dstufft @pfmoore Saya melihat opsi semacam itu sebagai mekanisme keikutsertaan sehingga kami dapat secara progresif mendorong pengguna ke pembuatan di tempat dengan tujuan menjadikannya default di beberapa titik. Dalam semangat komentar ini: https://github.com/pypa/pip/issues/8165#issuecomment -625501216

Saya akan mengajukan PR untuk ini. :)

8221 itu.

20.1.1 telah dirilis, berisi perubahan yang dikembalikan.

Di Fedora, ketika kami membuat paket Python RPM, kami adalah dinosaurus dan cara standar untuk melakukan thins adalah dengan menggunakan python setup.py build . Dengan PEP 517 kami menambahkan cara "sementara" menggunakan pip wheel sebagai gantinya. Namun dengan modul ekstensi, kami memiliki masalah dengan pendekatan "pindahkan sumber ke tmp, bangun dari sana" yang digunakan pip untuk membangunnya.

Mesin build kami menyuntikkan beberapa flag compiler sehingga artefak build ( modul ekstensi .so dalam kasus ini) berisi metadata tentang sumbernya. Kemudian ada skrip shell yang melintasi artefak build, mengekstrak informasi ini dan menyalin sumber ke /usr/src/debug untuk diinstal melalui RPM *-debugsource . Mahcinery mengharapkan semuanya dibangun di dalam pohon kerja dan itu tidak benar-benar berfungsi dengan baik saat dibangun di luar. Berikut adalah hal-hal yang dapat dilakukan (bersama-sama) untuk mengurangi masalah di pihak kita:

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.)

Ini secara efektif merupakan jalur yang saya mulai ketika mencari integrasi pip, #6505, dll.

Build iteratif dengan pip secara efektif rusak hari ini, yang merupakan kerugian besar bagi grup yang memiliki sejumlah besar kode python dalam bentuk ekstensi C, oleh karena itu saya terpaksa menjalankan build dengan setup.py .

pip membutuhkan perintah build dan hasil akhir dari perintah build harus dapat diteruskan ke subperintah lain, seperti wheel , install , dll.

Saat ini pip secara efektif memperlakukan install sebagai build dan install , yang _tidak_ diinginkan oleh beberapa orang yang sedang membangun dan menyimpan artefak biner, menginstal binari lebih dari membaca -hanya dudukan, dll.

Saya benar-benar berharap ada cara untuk menggunakan setup.py untuk membangun binari, lalu pip install mereka tanpa menggunakan membuat bdist , tetapi sepertinya itu tidak mungkin hari ini , karena pip dan distutils / setuptools tidak setuju di mana menemukan artefak biner.

Saya benar-benar berharap ada cara untuk menggunakan setup.py untuk membangun binari, lalu pip menginstalnya tanpa menggunakan bdist, tetapi itu tampaknya tidak mungkin hari ini, karena pip dan distutils/setuptools tidak setuju di mana menemukan artefak biner.

Saya tidak yakin saya mengikuti - Anda mengatakan Anda ingin cara menggunakan biner tetapi tidak ingin menggunakan format distribusi biner yang sudah ada. Mengapa demikian?

Saya benar-benar berharap ada cara untuk menggunakan setup.py untuk membangun binari, lalu pip menginstalnya tanpa menggunakan bdist, tetapi itu tampaknya tidak mungkin hari ini, karena pip dan distutils/setuptools tidak setuju di mana menemukan artefak biner.

Saya tidak yakin saya mengikuti - Anda mengatakan Anda ingin cara menggunakan biner tetapi tidak ingin menggunakan format distribusi biner yang sudah ada. Mengapa demikian?

Format bdist sangat membatasi. Grup saya harus menggunakan format bodoh, seperti tar, lalu membongkarnya kata demi kata (tidak ada BSD yang didukung, Debian tidak didukung, dll).

Apa yang saya temukan tadi malam adalah bahwa menggunakan bdist bodoh tidak dapat diinstal melalui pip . Binari bodoh tidak memiliki metadata yang diperlukan untuk diinstal melalui pip , AFAICT, di situlah saya kira roda pip ikut bermain.

Saya mencoba telur dan zip, juga, tetapi mereka tidak memiliki metadata yang diperlukan untuk menginstal hanya menggunakan file:// URI.

Saya telah bermain-main dengan mencoba untuk membangun melalui distutils, setuptools menjadi sistem build yang lebih besar menggunakan make, jadi saya tidak dapat menyatakan apakah saya telah melakukan "semua hal yang benar" untuk membuat semuanya berfungsi seperti bdist standar

Berasal dari https://github.com/pypa/pip/issues/2195#issuecomment -664728481 Saya dapat mengatakan bahwa saya lebih dari senang untuk melakukan kembali #7882 di belakang --use-feature=in-tree-build .

Hore! Kedengaranya seperti sebuah rencana!

Mari kita juga memperbarui docstring --build kali ini. ;)

Berasal dari #2195 (komentar) saya dapat mengatakan bahwa saya lebih dari senang untuk membuat ulang #7882 di belakang --use-feature=in-tree-build.

Ingin tahu apakah itu serta dengan baris perintah masuk akal untuk memiliki opsi in-tree-build diatur dalam pyproject.toml ? Ini akan cukup bagus untuk menyelesaikan #6276 tanpa perlu membuat skrip bash atau makefile untuk membungkus pip. (Bukannya itu masalah yang sangat besar.)

memiliki opsi in-tree-build yang disetel di pyproject.toml

@davidhewitt ini kurang lebih opsi 3 dalam deskripsi asli masalah ini. Pemahaman saya adalah bahwa konsensus saat ini adalah lebih baik menghindari opsi tambahan jika kita bisa. Oleh karena itu ide untuk mengaktifkan in-tree build dengan --use-feature selama periode transisi, dengan tujuan jangka panjang untuk menjadikannya sebagai mekanisme default dan satu-satunya.

BTW, saya tidak akan bisa mengimplementasikan ini tepat waktu untuk 20.3, tapi saya masih berniat melakukannya, semoga di 20.4.

@sbidoul Saya menulis tambalan untuk membantu memasukkan fitur ini - lihat #9091.