Sebuah proposal yang ambisius!

dukungan konfigurasi ini (konfigurasi ini global ada di rumah pengguna)

Pertimbangkan untuk menggunakan appdirs (atau serupa) untuk menemukan konfigurasi di lokasi pilihan platform.

appdirs juga bisa menjadi pilihan, meskipun kemudian kita harus memulai bisnis vendor barang ke dalam paket kita. Agar adil 70% dari ini sudah dilakukan, hanya perlu reorganisasi yang lebih baik.

Mengapa vendor daripada hanya bergantung padanya? (Bukannya sulit untuk vendor, itu hanya satu file). IMO, kami benar-benar harus menerima bahwa (dengan pengecualian pip) alat pengemasan benar-benar harus dibuat seperti aplikasi lainnya. Jika memiliki dependensi cukup sulit sehingga aplikasi PyPA menghindarinya, apa artinya tentang seberapa baik yang kami lakukan sehingga memudahkan pengguna kami untuk mengembangkan aplikasi?

(Maaf, tidak membuat semacam poin besar tentang virtualenv di sini, saya hanya melihat begitu banyak orang mengatakan "menambahkan ketergantungan PyPI bukanlah masalah besar", maka alat PyPA yang saya kerjakan pada hal-hal vendor membuat saya bertanya-tanya ...) .

Tanpa vendoring fitur cross interpreter saya kira akan sulit. Misalnya membuat lingkungan virtual untuk juru bahasa yang tidak menginstal virtualenv.

PYTHONPATH=/t/path/ke/virtualenv.whl python -m virtualenv

Eh, ini berarti kita tidak bisa bergantung pada paket tambahan apa pun dari virtualenv. Karena kami akan menyediakan zipapp, kasus penggunaan apa yang diaktifkan ini?

@gaborbernat Maksud Anda opsi -p ? Saya rasa begitu. Sepertinya persis seperti situasi yang zipapps dimaksudkan untuk membantu, tetapi tidak ada yang pernah benar-benar melakukan banyak hal untuk membahas detail membuatnya bekerja dengan baik.

Dari @pradyunsg :

Uh, ini berarti kita tidak bisa bergantung pada paket tambahan apa pun dari virtualenv

Sebenarnya, seperti yang dikatakan @gaborbernat , opsi -p mungkin menyiratkan bahwa :-( Tapi saya bertanya-tanya mengapa kita membutuhkan opsi "roda pada PYTHONPATH " serta zipapp - terutama mengingat roda itu pada PYTHONPATH secara umum tidak didukung (kami menggunakannya secara internal dalam virtualenv karena alasan bootstrap pip yang biasa - pip cukup banyak pengecualian untuk semuanya ;-))

masa tenggang dukungan

Hmm...

Kekhawatiran saya di sini adalah bahwa efek jaringan ini dapat menyebabkan perlambatan adopsi versi Python yang lebih baru dan ledakan kombinasi jumlah Python yang didukung. CPython sedang mendiskusikan irama rilis yang berbeda untuk 3.9, jadi 2 tahun bahkan mungkin lebih lama dari yang mungkin dimiliki beberapa rilis dari pengembang inti.

Yang mengatakan, saya tidak ingin memblokir ini tetapi kebanyakan hanya memastikan saya menyuarakan bahwa saya tidak tertarik melakukan ini.

(berharap untuk IronPython dan Jython di beberapa titik - ada yang lain yang harus kami dukung?)

Pastinya. @gaborbernat mungkin tahu saya akan mengatakan ini - ini akan bagus untuk dimiliki tetapi saya cukup yakin orang-orang yang lebih akrab dengan implementasi akan berada pada posisi terbaik untuk melakukan ini. Paling tidak, dalam hal dukungan dalam jangka panjang, dan idealnya, juga pekerjaan untuk mendapatkan dukungan yang baik sejak awal (CI, tes, dll).

pertama, dukungan konfigurasi ini (konfigurasi ini global ada di rumah pengguna),

Saya bias -- saya benar-benar ingin melihat ini menjadi TOML. :)

(Saya belum sepenuhnya memproses ini karena saya harus pergi ke suatu tempat -- tetapi ini memang terlihat seperti tujuan keseluruhan yang hebat!)

kami sudah tidak dapat benar-benar bergantung pada paket tambahan karena fitur lintas juru bahasa, jadi saya tidak menganggap ini sebagai kelemahan utama, dan saya ingin memiliki cara sederhana tanpa instalasi/ketergantungan menjalankan lingkungan virtual (diperlukan ketika orang memanggil kami dari paket node). Mengingat tidak banyak biaya yang kami tawarkan selain zipapp tampaknya murah.

lebih suka built-in venv: jika target python memiliki venv, kami akan membuat lingkungan menggunakan itu (dan kemudian melakukan operasi selanjutnya untuk memfasilitasi jaminan lain yang kami tawarkan)

Saya tidak yakin saya mengerti alasan untuk ini. Sepertinya itu akan membuat pemeliharaan virtualenv lebih sulit dan akan membuat perilaku lebih sulit dipahami oleh pengguna akhir. setuptools sudah pergi ke arah lain dengan mencoba menyerap distutils daripada terus menambal monyet itu.

@pganssle cakupannya berbeda dan ruang masalahnya juga. Masalah virtualenv adalah bahwa seringkali sistem menempatkan batasan tambahan pada paket sistem, sehingga mereka menambal venv bawaan untuk mematuhinya. Mereplikasi semua ini akan sulit, lihat misalnya #1362.

FWIW Saya pikir menggunakan paket venv bawaan untuk isolasi adalah ide yang tepat, itu dibangun ke dalam penerjemah yang sebenarnya (daripada distutils yang hanya modul stdlib) sehingga dapat melakukan hal-hal yang jauh lebih bersih daripada virtualenv bisa.

Virtualenv juga tidak perlu melakukan monkeypatch apa pun, itu hanya akan menggunakan API publik yang seharusnya baik-baik saja.

FWIW Saya akan merekomendasikan memeriksa cabang virtualenv penulisan ulang lama saya, itu sudah melakukan banyak hal ini.

Saya mungkin akan menyarankan sistem plugin tidak terlalu berguna untuk virtualenv, paling banyak kemungkinan hanya ada satu kait, langkah membuat posting dan bahkan kemudian Anda mungkin bisa lolos hanya dengan memiliki daftar hal yang harus diinstal.

JUGA, Anda masih dapat bergantung pada hal-hal "alami" dan masih menggunakan zipapps, Anda hanya perlu vendor di dalam zipapp itu sendiri. Saya akan merekomendasikan menjauh dari eksekusi ulang di bawah opsi target python, itu adalah hal yang buruk dan dapat dilakukan lebih bersih.

697 -- PR lama @dstufft

PYTHONPATH=/t/path/ke/virtualenv.whl python -m virtualenv

OTOH, kita mungkin tidak boleh melakukan ini -- https://www.python.org/dev/peps/pep-0427/#is -it-possible-to-import-python-code-directly-from- a-wheel-file

@pradyunsg jadi

Bootstrap pip mungkin OK - itulah yang digunakan virtualenv sekarang ¹ . Tapi saya sangat menyarankan hanya menggunakannya untuk pip, dan bukan sebagai sarana menjalankan virtualenv itu sendiri.

¹ Tapi saya akan menghindari fungsionalitas yang rumit - menggunakan roda pada PATH untuk menginstal pip dari roda itu dijamin akan baik-baik saja. Tetapi Anda mungkin memiliki masalah jika Anda, misalnya, mengakses internet menggunakan roda seperti itu, karena menurut saya sertifikat memerlukan bundel sertifikat yang disematkan sebagai file aktual (tapi saya mungkin salah, itu tidak pernah menyebabkan masalah bagi saya, tetapi saya tahu get-pip.py mengekstrak sertifikat dari roda secara eksplisit untuk mengatasi hal ini.

Adakah alasan mengapa kami tidak mengirimkan pip sebagai zipapp ? Itu akan menghindari kebutuhan ini seperti yang saya mengerti, dan zipapp didukung dengan python 2.7 sebelumnya

@gaborbernat sudahkah anda mencobanya? Apakah itu bekerja? jika pendekatan yang Anda uraikan berfungsi di windows, saya tidak memiliki masalah awal tetapi @uranusjr kemungkinan akan memiliki umpan balik. Satu-satunya komentar saya sejalan dengan @dstuff yaitu -- lebih sederhana lebih baik

Adakah alasan mengapa kami tidak mengirimkan pip sebagai zipapp?

Karena dalam kasus tertentu, pip tidak akan berjalan langsung dari file zip (atau roda, itu hal yang sama), seperti yang saya katakan di atas. 99% (peringatan - nomor yang dibuat) dari waktu, itu berfungsi, tetapi kadang-kadang fakta bahwa bundel sertifikat perlu menjadi file nyata penting.

Mungkin akan berfungsi dengan baik untuk menggabungkan pip sebagai shiv , karena shiv membongkar zipapp sebelum menjalankannya, tepatnya untuk menghindari kasus sudut di mana lari dari zip pecah. Tidak ada yang sepengetahuan saya telah mencobanya.

Seperti biasa, alasan utama itu belum terjadi adalah:

1. Tidak ada yang memikirkannya.
2. Tidak ada yang punya waktu/motivasi untuk melakukannya.
3. Pendekatan saat ini bekerja dengan baik, dan ada ikan yang lebih besar untuk digoreng.

jadi adakah metode lain untuk bootstrap pip tanpa meletakkan roda di jalurnya?

Saya tidak berpikir kita membutuhkannya di sini -- virtualenv menggunakan roda pip untuk menginstal dari IIRC itu sendiri, yang seharusnya berfungsi dengan baik. Seperti yang dikatakan @pfmoore , satu-satunya hal "ekstra" yang dilakukan get-pip.py adalah membongkar sertifikat dan memberikan jalur ke sana. Karena usecase virtualenv tidak akan mencapai jaringan, kita tidak perlu melakukan sesuatu yang baru di sini.

Pendekatan saat ini bekerja dengan baik, dan ada ikan yang lebih besar untuk digoreng.

Ini, jauh lebih banyak dari IMO lainnya. Kami bisa, tetapi ada masalah yang lebih berdampak untuk ditangani. :)

Saya memiliki PR pada satu titik yang membuat pip sebagai aplikasi Zip, itu berhasil tetapi IIRC saya harus membuat perubahan pada pip agar berfungsi penuh.

Itu mungkin sedikit rumit sekarang karena pip memanggil dirinya sendiri sebagai subproses dari dirinya sendiri untuk PEP 517. Saya tidak yakin tapi itu pasti layak untuk ditelusuri.

Pada titik ini shiv (atau opsi self-extracting lainnya) akan lebih cocok untuk pip daripada mencoba mengerjakan pip ke dalam Zip-runnable. Tapi saya tidak berpikir ini adalah hal yang sangat penting pada saat ini. surepip sudah mengikuti rute wheel-on-path, mengapa tidak melakukan hal yang sama saja. Bootstrap pip alternatif dapat dieksplorasi setelah kami menggoreng semua ikan yang lebih besar, dan berpotensi disumbangkan kembali ke stdlib.

Alternatif pip bootstrap dapat dieksplorasi setelah kita menggoreng semua ikan yang lebih besar

Kedengarannya seperti rencana [yang sudah kita ikuti. ;)]

Terima kasih atas tautannya, berdasarkan umpan balik, saya telah memulai beberapa pekerjaan awal di https://github.com/gaborbernat/virtualenv/tree/rewrite/src/virtualenv . Rencananya adalah untuk membuatnya menjadi bentuk rilis dalam bulan depan (dan memiliki satu minggu tinjauan terbuka sebelum itu). Berdasarkan dampak dari perubahan tersebut, saya berencana untuk merilisnya 20.0.0 .

+1 untuk menggunakan venv jika ada. Itu akan membuat kasus penggunaan PyPy lebih sederhana.

Jadi penulisan ulang sampai pada keadaan di mana saya merasa orang-orang nyaman memeriksanya dan memberikan umpan balik. Silakan hubungi saya jika Anda memiliki waktu luang untuk membantu dalam hal ini; rencananya akan dirilis pada akhir bulan Catatan https://github.com/pypa/virtualenv/milestone/7 masih perlu diimplementasikan, namun, ide intinya ada di sana.

PS. Membuat PR umpan balik di bawah https://github.com/pypa/virtualenv/pull/1481/

Permintaan fitur: Menyediakan mekanisme untuk mendefinisikan variabel lingkungan kustom, misalnya dengan menempatkan file env.txt di direktori venv bin dengan format standar:

VARNAME=value
OTHERVAR=othervalue

Saya rasa saya tidak mengerti kasus penggunaan Anda? Bagaimana variabel lingkungan ini digunakan, disetel, kapan?

Sunting. NM. Saya melihat Anda memperluas https://github.com/pypa/virtualenv/issues/1124.

Pembaruan kecil; Saya telah berhasil menutup sebagian besar masalah pemblokiran, selain dua yang masih membutuhkan cinta: pengujian termasuk header + caching panggilan interogasi python dengan beberapa kunci diterapkan pada data aplikasi, sehingga kami dapat membuat lingkungan virtual secara paralel (ke lokasi yang berbeda). Pada kecepatan saat ini saya mungkin terlambat beberapa hari... tapi pasti harus keluar pada tanggal 7 Februari.

Apa rencana kami dalam hal peluncuran? Apakah kami akan merilis beta sebelum rilis utama?

Ya, ingin mendapatkan sesuatu pada hari Senin... Dan kemudian tinggalkan sementara seminggu untuk umpan balik, perbaikan... Dan kemudian ganti master dengan penulisan ulang dan rilis.

Saya tidak 100% yakin bahwa seminggu akan cukup dan kami pasti harus berkomunikasi di beberapa saluran bahwa kami ingin orang-orang mencoba versi beta.

Kata kunci di sana adalah tentatif . Saya optimis di sini, mengingat jumlah upaya yang telah saya lakukan, saya tidak mengharapkan masalah besar, tapi

virtualenv 20.0.0 beta1 tersedia .

Karena beta keluar, saya merasa masalah ini disajikan adalah tujuannya. Saya akan menutup dan kita bisa berdiskusi lebih fokus pada isu-isu khusus.