Pipenv: Bagaimana pipenv mengetahui virtualenv untuk proyek saat ini?

Nama virtualenv adalah nama direktori root proyek, ditambah hash path lengkap ke root proyek. Ini menjamin nama menjadi unik dan dapat diprediksi selama Anda tidak memindahkan proyek. (AFAICT logika pembuatan nama ini adalah detail implementasi yang tidak boleh diandalkan.)

Untuk menginstal versi paket tertentu, gunakan sintaks yang sama seperti yang Anda lakukan dengan pip dan requirements.txt, misalnya pipenv install django==1.11.0 .

@uranusjr Ini berarti jika saya mengganti nama direktori, virtualenv proyek saya akan hilang. Itu buruk. Ini bisa menjadi kasus penggunaan umum untuk mengganti nama direktori dan pengguna mungkin jatuh ke dalam ini dan bertanya-tanya bagaimana lingkungan mereka berhenti bekerja.

Saya akan menyarankan untuk memperbaikinya dan membuat entri ke Pipfile jika memungkinkan. Atau buat file .pipenv lain untuk menyimpan metadata tersebut di setiap direktori proyek.

Apa yang Anda sarankan ?

Terima kasih telah menjawab kedua pertanyaan!

Hai @sachinjain024 , kami telah melakukan beberapa diskusi tentang file metadata lokal tetapi konsensus pengelola adalah bahwa pipenv tidak akan mendukungnya saat ini.

Jalur direktori yang mengidentifikasi proyek adalah sesuatu yang diterapkan sejak awal karena proyek dengan nama yang sama, atau banyak salinan dari proyek yang sama, menyebabkan penimpaan status lingkungan yang tidak disengaja.

Dalam praktiknya, kami menemukan jauh lebih sedikit orang yang memiliki masalah dengan lokasi sebagai bagian dari lingkungan dibandingkan dengan pekerjaan mereka yang ditimpa secara diam-diam. Pipenv adalah alat manajemen penerapan, jadi memindahkan direktori harus menjadi satu perintah perbaikan.

Terima kasih @nateprewitt. Masuk akal untuk dengan cepat melompat ke implementasi yang mudah. Misalkan saya mengganti nama proyek di tahap selanjutnya maka itu berarti lingkungan saya tidak ada.

Jadi apa yang harus saya lakukan dalam situasi ini?

1. Atur ulang lingkungan karena saya sudah memiliki Pipfile yang memiliki informasi paket sehingga akan mudah untuk mengatur ulang env.
2. Entah bagaimana ganti nama direktori virtualenv juga
3. ???

Apa yang Anda sarankan dalam kasus ini? Hanya ingin tahu jika saya mendapatkan situasi ini di masa depan.

Anda dapat menggunakan pew cp untuk dengan mudah menyalin virtualenv yang ada, tetapi 1. saya pikir akan menjadi cara yang lebih "kanonik" untuk melakukannya.

@sachinjain024 , setiap kali Anda perlu memindahkan direktori proyek Anda, Anda hanya perlu menjalankan pipenv install untuk kembali ke status kerja. Ini akan menciptakan lingkungan untuk Anda dengan hash baru dan menginstal ulang semuanya dari lockfile secara identik dengan instalasi sebelumnya yang dibuatnya.

Jika Anda sering melakukan ini, Anda mungkin ingin menggunakan pew rm old_project-a3de90 untuk membersihkan.

Saya tidak akan merekomendasikan menggunakan pew cp kecuali Anda memodifikasi lingkungan virtual di luar pipenv. Dalam hal ini, saya pikir kita harus mempertimbangkan skenario "garansi yang dibatalkan", karena ada segala macam perubahan yang tidak dapat kita pertanggungjawabkan dengan andal.

Terima kasih @nateprewitt @uranusjr. Menutup tiket ini.

Ini adalah salah satu ide terburuk yang keluar dari pipenv sejauh ini. Inilah alasannya:

Saya bekerja di sebuah perusahaan, di mana Python digunakan untuk otomatisasi pengujian banyak proyek internal. Satu penguji biasanya bekerja pada selusin dari itu. Berdasarkan konvensi, semua kode pengujian untuk sebuah proyek berada dalam direktori bernama tests . Ini berarti, bahwa setiap penguji sekarang memiliki banyak lingkungan virtual yang semuanya disebut sesuatu seperti ~/.local/share/virtualenvs/tests-hKjFddnZ - luar biasa! Sudah menjadi sifat manusia untuk lupa mengganti lingkungan virtual, jadi, setiap beberapa hari saya dipanggil ke stasiun kerja yang berbeda karena orang di stasiun kerja itu berpikir bahwa mereka menginstal paket yang mereka butuhkan, mereka menjalankan pipenv install , tetapi impor dalam kode tidak berfungsi. Tidak hanya itu, lingkungan virtual yatim piatu terakumulasi dari waktu ke waktu, tetapi karena semuanya memiliki nama yang tidak mencolok, tidak ada cara untuk mengetahui apakah saya menghapus lingkungan yang tidak digunakan, atau lingkungan yang benar-benar telah digunakan. Ini berarti bahwa di CI, kami membuat lusinan, bahkan ratusan lingkungan virtual setiap hari. Tidak mungkin siapa pun dapat melacak lingkungan yang pada dasarnya memiliki nama acak, dan jumlahnya terlalu banyak, jadi kami harus menghapus semuanya setidaknya sekali sehari. Kami membayar banyak korban dalam waktu tunggu hanya karena keputusan super cerdas yang dibuat oleh pipenv dan seseorang di perusahaan kami, yang memutuskan untuk menggunakannya...

Setel export PIPENV_VENV_IN_PROJECT=1 di konfigurasi bashrc/shell Anda.
(Atau ubah skrip shell Anda untuk membuat venv di $PROJECT/.venv dan kemudian
pipenv akan memilikinya)
Pada Senin, 19 Maret 2018 pukul 6:28 pagi wvxvw [email protected] menulis:

Ini adalah salah satu ide terburuk yang keluar dari pipenv sejauh ini. Inilah alasannya:

Saya bekerja di sebuah perusahaan, di mana Python digunakan untuk otomatisasi pengujian banyak
proyek internal. Satu penguji biasanya bekerja pada selusin dari itu. Oleh
konvensi, semua kode uji untuk proyek tinggal di direktori yang disebut tes.
Ini berarti, bahwa setiap penguji sekarang memiliki banyak lingkungan virtual semua
disebut sesuatu seperti ~/.local/share/virtualenvs/tests-hKjFddnZ -
luar biasa! Sudah menjadi sifat manusia untuk lupa beralih lingkungan virtual, jadi,
setiap beberapa hari saya dipanggil ke tempat kerja yang berbeda karena orangnya
di stasiun kerja itu berpikir bahwa mereka menginstal paket yang mereka butuhkan, mereka
menjalankan pemasangan pipenv, tetapi impor dalam kode tidak berfungsi. Tidak hanya
itu, lingkungan virtual yatim piatu terakumulasi dari waktu ke waktu, tetapi karena semua
dari mereka memiliki nama yang tidak mencolok, tidak ada cara untuk mengetahui apakah saya menghapus
lingkungan yang tidak digunakan, atau lingkungan yang benar-benar telah digunakan. Ini
artinya di CI, kami membuat lusinan, jika bukan ratusan lingkungan virtual
sehari-hari. Tidak mungkin ada orang yang bisa melacak lingkungan yang memiliki
pada dasarnya nama acak, dan jumlahnya terlalu banyak, jadi kita harus
hapus semuanya setidaknya sekali sehari. Kami membayar banyak biaya dalam waktu tunggu
hanya karena keputusan super cerdas yang dibuat oleh pipenv dan seseorang di
perusahaan kami, yang memutuskan untuk menggunakannya...

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/pypa/pipenv/issues/796#issuecomment-374211264 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/ABhjqyABdDHCB8WMm-hJwdkNptVlh8fuks5tf7KBgaJpZM4Pp3kf
.

@jtratner Lalu mengapa saya perlu pipenv jika saya akan membuat lingkungan virtual dengan tangan?

Lingkungan virtual adalah bagian dari pekerjaan itu sendiri. Ini lumpuh di mana-mana dan rusak di Windows (diasumsikan bahwa pada MS Windows, dari semua tempat, direktori home default disebut "~"). Saya berharap bahwa jika seseorang ingin mengulang PIP dan lingkungan virtual, mereka akan, Anda tahu, memperbaiki kesalahan yang jelas dari pendahulu mereka... sebaliknya, ada kekacauan ini dikalikan dengan lapisan ketidakcocokan.

Anda membuat asumsi yang salah. Pipenv tidak mengulang virtualenv atau pip. Itu dibangun di atas mereka.

@uranusjr itu masalah pemahaman bacaan. Saya tahu betul, apa yang dilakukan pipenv , karena saya menghabiskan lebih banyak waktu untuk men-debug kodenya daripada yang saya inginkan. Untuk mengulang lingkungan virtual dan PIP adalah tujuan yang dinyatakan proyek. Bahwa, alih-alih memperbaikinya, diputuskan untuk menggunakannya "sebagaimana adanya" adalah kesalahan besar lainnya dari pipenv , diikuti dengan menggunakan perpustakaan click , dan daftarnya terus berlanjut.

Untuk mengulang lingkungan virtual dan PIP adalah tujuan yang dinyatakan proyek.

Di mana ada yang menyatakan ini?

Saya juga menemukan perilaku ini aneh, saya mengharapkan pipenv untuk memilih nama standar untuk direktori virtualenv dan meletakkan direktori di direktori saat ini, mirip dengan cara npm menggunakan node_modules .

@Flimm export PIPENV_VENV_IN_PROJECT=1 . Baca dokumentasi.

@uranusjr Saya membaca semua https://docs.pipenv.org dan https://docs.pipenv.org/basics/ , dan kecuali saya melewatkannya, itu tidak pernah menyebutkan di mana direktori virtualenv diinstal, juga tidak memperingatkan siapa pun bahwa mengganti nama atau memindahkan direktori proyek akan menyebabkan direktori virtualenv harus dibuat ulang.

PIPENV_VENV_IN_PROJECT diberi nama yang membingungkan, karena pipenv tidak menggunakan venv dikirimkan dalam pustaka standar, ia menggunakan virtualenv , yang merupakan proyek yang berbeda.

Saya hanya mencoba memberikan umpan balik tentang hal-hal yang membuat saya tersandung saat saya membiasakan diri dengan proyek ini.

@Flimm intinya adalah untuk mengabstraksi informasi ini. Jika Anda tahu cara kerja alat lain yang mengelola virtualenvs, Anda seharusnya sudah tahu bahwa memindahkan folder virtualenvs membuatnya tidak dapat ditemukan. Jika Anda tidak terbiasa, Anda mungkin tidak akan menggali ini sejak awal.

Adapun pustaka backend apa yang kami gunakan untuk menghasilkan virtualenvs dan penamaan variabel lingkungan yang pertama tidak begitu penting dan yang terakhir adalah singkatan yang diterima secara luas. Meskipun detail penting, yang ini tidak terasa seperti menyebabkan masalah bagi siapa pun, dan keberatan utama Anda tampaknya didasarkan pada Anda tidak yakin backend mana yang kami gunakan untuk meletakkan python yang dapat dieksekusi di folder. Jika Anda menemukan bug, harap laporkan. Kami benar-benar tidak akan mengubah variabel lingkungan _hanya karena_.

Variabel lingkungan sudah tersedia di dokumen: http://pipenv.readthedocs.io/en/latest/advanced/#configuration -with-environment-variables sehingga Anda mungkin tidak membaca semuanya jika Anda tidak melihatnya dia

@techalchemy Dengan alat lain, saya kira maksud Anda seperti virtualenvwrapper . Saya pergi selama bertahun-tahun tanpa menggunakan virtualenvwrapper . Saya menduga bahwa jumlah pengembang Python yang akrab dengan node_modules pola Node/NPM lebih banyak daripada jumlah pengembang Python yang akrab dengan virtualenvwrapper atau pipenv pola menyembunyikan direktori lingkungan. Tapi itu tebakan. Bagi mereka yang tidak terbiasa dengan alat-alat ini, saya pikir akan membingungkan untuk tidak mengetahui di mana file yang diinstal berakhir. Anda menunjukkan bahwa ini hanya dijelaskan di bagian lanjutan dari dokumen di bawah subbagian variabel lingkungan, saya pikir itu harus dijelaskan dalam dokumen jauh lebih awal dari itu. Mungkin saya akan mengajukan permintaan tarik.

Saya telah mengomentari referensi membingungkan ke venv alih-alih virtualenv dalam penamaan PIPENV_VENV_IN_PROJECT dalam edisi lain #1919. Cukuplah untuk mengatakan, saya tidak cukup memegang posisi yang saya pikir Anda pikir saya pegang.

Bagaimanapun, pertanyaan dalam masalah asli dijawab. Saya tidak ingin memperpanjang diskusi ini, jangan ragu untuk memiliki kata terakhir jika Anda menginginkannya.

Saya mengerti ini adalah audiens yang salah, tetapi karena diskusi ini sedang berlangsung... yah, saya tidak berpikir bahwa node_modules adalah inspirasi untuk pipenv , dan bukan untuk virtualenv juga. Dugaan saya mungkin secara historis salah, tetapi harus bekerja dengan rbenv dan virtualenv , saya dapat memberi tahu Anda bahwa virtualenv terasa seperti salinan yang buruk tanpa pemahaman, atau mungkin prototipe awal, yang ditingkatkan oleh rbenv . Dalam kedua kasus, virtualenv adalah bahan tertawaan dibandingkan dengan rbenv , dan inilah alasannya:

Ini menyalin paket untuk setiap lingkungan. Ini bodoh, lambat, dan membingungkan. Itu hanya keputusan desain yang buruk, tetapi kemungkinan besar hanya kurangnya keputusan: itu terjadi begitu saja karena seseorang menulis beberapa kode untuk meletakkan paket-paket ini ke direktori arbitrer. Selain itu, itu tidak bekerja pada Windows benar-benar. Sampai-sampai ia tidak pernah benar-benar diuji pada Windows... Satu hal yang menggelikan tentangnya adalah ia menguji OS, dan begitu ia mengetahui bahwa ia berjalan di Windows, ia menetapkan direktori home ke ~ , default ini nanti mungkin ditimpa oleh beberapa variabel lingkungan, tetapi jika Anda benar-benar mencoba menjalankan otomatisasi Anda di lingkungan yang diawasi dan bersih... virtualenv akan pernah menginstal paket-paket di direktori yang sama.

Jadi... pipenv diduga menjadi alat bagi manusia, seperti requests ... Saya rasa? Jadi, itu harus meningkatkan upaya yang belum matang yang dilakukan oleh para pendahulunya ... yah, sepertinya itu cara yang harus dilakukan, jika Anda ingin membuat program yang melakukan hal yang sama seperti yang sebelumnya, tetapi lebih baik, kan ? Namun, alih-alih membuang sampah virtualenv , ia menggunakannya apa adanya. Pembungkus hanya berbeda dari program yang dibungkus dalam hal itu tidak mengizinkan/membuat lebih sulit untuk menggunakan beberapa fungsi dari program yang dibungkus...

Dalam hidup saya, saya telah melihat banyak upaya untuk melakukan otomatisasi, yang payah, tetapi kalian menembak untuk bintang-bintang, Anda menempatkan semua penilaian yang tidak pantas di situs Anda, bahkan sebelum Anda memasukkan informasi yang berguna. Tapi kamu tidak menepati janji. Pada kenyataannya, Anda hanya memanipulasi opini publik, tanpa melakukan pekerjaan nyata. Dan sekarang programmer yang harus melakukan otomatisasi harus menghadapi kejahatan lain, hanya karena seseorang ingin mendapatkan lebih banyak "suka" di GitHub...

@wvxvw Memang Anda salah. virtualenv mendahului rbenv sekitar lima (empat, lihat di bawah) tahun, dan karena itu tidak akan pernah bisa terinspirasi olehnya. Juga mereka pada dasarnya adalah hal yang berbeda, hanya mencapai tujuan yang sama pada akhirnya. Hal yang Anda cari (alat manajemen runtime yang terinspirasi oleh rbenv) adalah pyenv.

Juga tentang virtualenv yang tidak setara dengan alat lain — tahukah Anda bahwa itu sudah ada selama sepuluh (10) tahun? Persyaratan pengembangan perangkat lunak banyak berubah, dan asumsi yang dibuatnya secara bertahap sudah ketinggalan zaman, dan tidak ada yang peduli untuk menggantikannya. Apakah Anda cukup peduli untuk melangkah?

Saya mengerti bahwa setiap orang berhak mendapatkan kesempatan untuk berbicara, tetapi untuk bergabung dalam diskusi tanpa pemahaman minimal tentang topik tersebut, dan segera mulai menunjuk, ini cukup kasar bagi kontributor sistem pengemasan Pipenv, virtualenv, dan Python secara keseluruhan. Tolong jangan lakukan ini.

Sunting: Saya melakukan penggalian. rilis awal virtualenv, 0.8, dibuat pada 2007, sedangkan rbenv (0.1) adalah 2011, jadi jaraknya empat tahun, bukan lima.

@wvxvw Saya hanya melihat Anda menawarkan penghinaan. Sikap seperti ini sangat tidak diterima di sini. Silakan lihat kode etik kami sebelum Anda melanjutkan posting.

Saya mendapat masalah yang sama setelah mengubah jalur proyek dan kehilangan pemetaan virtualenv asli, lalu saya membaca utas ini. Pertama, saya menghargai kerja tim pipenv. Baru saja mendapat beberapa pendapat yang ingin saya bagikan tentang diskusi ini:

1. Dokumen memang harus menunjukkan mekanisme pemetaan antara jalur proyek dan env, setidaknya memperingatkan pengguna bahwa changing project path would cause unmapping the original env .

2. Apakah akan lebih baik jika Anda dapat mengatur jalur ke env secara manual di Pipfile? Maksud saya orang mungkin memiliki beberapa persyaratan khusus untuk menggunakan env yang sama secara manual.

Hanya pendapat saya untuk berbagi dengan kalian.

Benar-benar tidak jelas cara menggunakan pipenv. Haruskah saya memiliki banyak lingkungan virtual untuk satu proyek? Haruskah saya berbagi lingkungan virtual antar proyek? Bagaimana cara menginstal versi python yang berbeda untuk proyek tertentu dengan pipenv, jika versi python hanya diperlukan untuk proyek itu? Setiap orang begitu penuh dengan diri mereka sendiri di utas ini, mengasumsikan banyak hal tentang orang lain, tidak pernah mencoba memahami dari mana orang lain berasal. Ketika saya membaca pujian pipenv di beranda, saya percaya itu akan membantu saya. Sebaliknya, saya menyia-nyiakan 5 hari bergulat dengannya, dan sekarang saya pikir saya kembali ke pyenv karena itu setidaknya agak deterministik.

jika Anda ingin menggunakan beberapa lingkungan untuk satu proyek, gunakan tox. Gunakan pipenv untuk lingkungan pengembangan utama Anda, dan tox untuk pengujian pada beberapa versi python.

@ashnur Anda jelas perlu melakukan sesuatu. Alih-alih menyebarkan hal negatif di antara proyek open source yang dijalankan oleh sukarelawan, mengapa Anda tidak mencoba menyumbangkan sesuatu yang bermanfaat?

@uranusjr
ini adalah di mana hashing terjadi?

Saya sedang mengerjakan sebuah proyek dan perlu menghitung hash suatu jalur.

@devxpy Yup, tepatnya.

Saya pikir kalian harus meletakkan tutorial dasar tentang cara mengatur virtualenv dengan pipenv sesuatu yang sangat mendasar karena semakin mudah pada orang semakin banyak orang akan menggunakannya tetapi jika itu menyebabkan kebingungan maka lebih banyak orang mungkin tidak menggunakannya dan mungkin mencari yang lain bahasa atau metode untuk membangun proyek di sana

@uranusjr apa alasan Pipenv tidak membuat virtualenv secara default di direktori proyek? Cara saya melihatnya, itu akan menyelesaikan masalah dengan lingkungan yatim piatu ketika proyek diganti namanya/dipindahkan/dihapus. Selain itu, akan kurang membingungkan bagi orang-orang yang (agak berhak) mengharapkannya berfungsi seperti npm.

Apakah ada manfaat untuk memilih pendekatan ini selain mungkin tradisi?

Cukup buat direktori .venv sebelum perintah install pipenv. Opsi —venv atau —dot-venv untuk pemasangan pipenv akan diterima, sebenarnya :)

Mulai tahun 2018.10.9 ada cara lain untuk melakukan ini. Anda dapat menambahkan .venv file yang berisi path untuk lingkungan virtual Anda. (Fitur baru yang licik!)

@andrewpeterprifer Karena kami biasa melakukan ini, dan perlu mengubahnya karena beberapa orang menolak dengan sangat keras. Kita perlu memilih satu pendekatan atau yang lain, dan saya harus mengakui bahwa itu adalah default yang lebih baik untuk tidak menempatkan lingkungan virtual di dalam direktori proyek.

ps Apakah Anda (atau siapa pun) tertarik untuk menulis entri faq tentang ini? Mungkin akan memakan waktu beberapa paragraf, tetapi saya akan dengan senang hati menjelaskan jika seseorang berjanji untuk meluangkan waktu untuk memoles teks dan mengirimkan PR.

@uranusjr Saya sangat ingin tahu mengapa ini adalah default yang lebih baik. Saya relatif noob terhadap python dan sekarang saya merasa seperti kehilangan sesuatu yang jelas tentang praktik terbaik. :) Terima kasih!

PS.: Saya bisa menulis entri FAQ jika Anda menjelaskan mengapa semuanya seperti itu. ;)

Mulai tahun 2018.10.9 ada cara lain untuk melakukan ini. Anda dapat menambahkan .venv _file_ yang berisi path ke lingkungan virtual Anda. (Fitur baru yang licik!)

@andrewpeterprifer Karena kami biasa melakukan ini, dan perlu mengubahnya karena beberapa orang menolak dengan sangat keras. Kita perlu memilih satu pendekatan atau yang lain, dan saya harus mengakui bahwa itu adalah default yang lebih baik untuk tidak menempatkan lingkungan virtual di dalam direktori proyek.

ps Apakah Anda (atau siapa pun) tertarik untuk menulis entri faq tentang ini? Mungkin akan memakan waktu beberapa paragraf, tetapi saya akan dengan senang hati menjelaskan jika seseorang berjanji untuk meluangkan waktu untuk memoles teks dan mengirimkan PR.

Saya minta maaf untuk bertemu ... Saya memiliki kebutuhan yang sama untuk memindahkan folder proyek yang memiliki lingkungan virtual yang dibuat dengan pipenv.

Saat ini saya melakukan hal berikut dan tidak memiliki masalah sama sekali:

• Saya memindahkan folder proyek ke mana pun saya mau
• di C:\Users\user\.virtualenvs saya menghapus folder venv yang terkait dengan proyek yang baru saja saya pindahkan
• Saya menavigasi ke lokasi folder proyek baru melalui cmd dan menjalankan instalasi pipenv (atau shell pipenv dan kemudian sinkronisasi pipenv)

Semuanya bekerja ok. Apakah ini praktik yang buruk?

Mengenai komentar @uranusjr jika saya mengerti benar dengan fitur baru saya harus menambahkan file .venv (berisi path ke lingkungan virtual yang diinginkan) ke dalam folder proyek kan? Dan ini akan menghindari saya dari keharusan melakukan semua langkah yang saya sebutkan sebelumnya? Kalau begitu hebat!!
Jika demikian halnya, bukankah lebih baik jika file seperti itu secara otomatis dibuat di folder proyek ketika lingkungan virtual awalnya dibuat?

PS: Saya juga bersedia menulis FAQ

Sebenarnya, saya pikir ide @gioxc88 bagus, virtualenv yang baru dibuat dapat secara otomatis menghasilkan file .env bawah root proyek, dan berisi konfigurasi env seperti PATH . Ini akan membuat lingkungan lebih transparan bagi pengembang dan cara yang lebih nyaman untuk mengkonfigurasi ulang.

Saya akan mencoba menjawab pertanyaan Anda bersama. Pendekatannya tidak buruk (IMO; saya sendiri juga menggunakan pengaturan yang sama). Namun, lebih mudah bagi pengguna yang tidak sadar untuk tersandung.

Salah satu cara untuk memikirkannya adalah dengan mempertimbangkan untuk menempatkan proyek dalam kontrol versi (katakanlah Git). Jika lingkungan dibuat di root proyek, secara alami akan ada di root repositori. Orang-orang seperti Anda dan saya, yang terbiasa dengan pengaturan ini, jelas tahu bahwa kita harus menambahkan aturan di .gitignore (atau konfigurasi abaikan global) untuk mencegah direktori .venv diperiksa, tetapi pengguna yang tidak curiga tidak akan melakukannya, dan dapat dengan mudah memeriksa lingkungan secara tidak sengaja. Ini tidak hanya buruk untuk manajemen proyek, tetapi (yang lebih penting) menyediakan vektor untuk serangan potensial dengan mengekspos informasi lokal. Oleh karena itu, merupakan aturan umum untuk alat manajemen proyek untuk menghindari meletakkan file yang dihasilkan di dalam direktori proyek . Tidak apa-apa (masih belum optimal IMO) untuk melakukannya jika Anda merancang ekosistem dari awal (misalnya node_modules NPM), tetapi jelas bukan ide yang baik untuk alat yang dibangun untuk ekosistem dengan praktik umum yang mapan, seperti kasus Pipenv.

Jika lingkungan dihasilkan di luar root proyek secara default, ada satu hal yang tidak perlu dikhawatirkan ketika Anda mempublikasikan proyek Anda (misalnya, dorong ke GitHub). Itu membuat hidup kami (yang lebih menyukai lingkungan dalam proyek) sedikit lebih sulit, tetapi dari perspektif risiko, hal terburuk yang dapat terjadi adalah memindahkan proyek secara tidak sengaja dan merusak lingkungan, atau lupa menghapus lingkungan saat proyek dihapus. . Keduanya jauh, jauh lebih mudah dipulihkan daripada secara tidak sengaja mendorong informasi lingkungan Anda yang berpotensi sensitif ke GitHub.

Fitur file .venv masih cukup baru (dirilis hanya beberapa hari yang lalu), dan kami masih mencari cara untuk memanfaatkannya sebaik mungkin. Masih memiliki masalah yang sama dengan direktori .venv , tapi semoga tidak seburuk itu. Saya sendiri sangat menyukai fitur ini, dan tentunya berharap kami dapat menggunakannya untuk meningkatkan pengalaman pengguna, tetapi masih banyak yang perlu dipertimbangkan di sini.

Hai. Bagi saya, direktori .venv (fitur lama) dan file .venv (fitur baru) tidak masalah, tetapi saya akan sangat berterima kasih jika memiliki opsi dalam perintah pemasangan pipenv.

Sesuatu seperti:

pipenv install

Akan dipasang di ~/.local/

pipenv install --venv

Akan dipasang di direktori $PWD/.venv

pipenv install --venv-dir /my/custom-path

Akan menginstal di /my/custom-path .

Jika Anda menginginkan fitur baru, usulkan dengan benar dengan membuat proposal peningkatan ke ~/.peeps . Tolong jangan membuat proposal peningkatan tersebar secara acak di berbagai masalah, itu tidak dapat dilacak.

@uranusjr terima kasih atas jawaban terperinci! Hanya untuk memuaskan rasa ingin tahu saya, informasi lokal (berpotensi sensitif) seperti apa yang dapat diekspos oleh python venv yang diperiksa? Saya setuju bahwa itu menjengkelkan jika node_modules diperiksa, tetapi biasanya itu tidak berisi informasi lokal apa pun.

Lingkungan virtual Python berisi beberapa skrip shell (misalnya activate ). Banyak orang memodifikasinya untuk menambahkan variabel lingkungan untuk menentukan kata sandi basis data, jalur ke file konfigurasi lain, dll. Memodifikasi skrip di lingkungan virtual bertentangan dengan praktik terbaik, tetapi orang tetap melakukan ini (dan bersikap defensif ketika Anda memberi tahu mereka untuk berhenti melakukannya -pengalaman pribadi).

Juga, Anda benar, node_modules mungkin tidak berisi informasi sensitif. Itulah manfaat lain ketika Anda membangun ekosistem dari awal. Lingkungan virtual Python sayangnya ditemukan jauh sebelum ini adalah masalah umum (saat itu Anda sudah menjadi guru jika Anda menggunakan VCS sama sekali).

Saya tiba di sini ketika saya mencoba memahami bagaimana pipenv mengetahui virtualenv yang tepat :)

Terima kasih teman-teman untuk diskusi itu. Mungkin, merupakan ide bagus untuk menentukan di halaman utama (misalnya, di sini ) bahwa mengganti nama jalur proyek merusak mekanisme default pengikatan virtualenv.

Semua halaman dokumentasi terbuka untuk kontribusi. Jangan minta apa-apa, lakukan saja :)

Saya akan!

@uranusjr Ini berarti jika saya mengganti nama direktori, virtualenv proyek saya akan hilang. Itu buruk. Ini bisa menjadi kasus penggunaan umum untuk mengganti nama direktori dan pengguna mungkin jatuh ke dalam ini dan bertanya-tanya bagaimana lingkungan mereka berhenti bekerja.

Saya akan menyarankan untuk memperbaikinya dan membuat entri ke Pipfile jika memungkinkan. Atau buat file .pipenv lain untuk menyimpan metadata tersebut di setiap direktori proyek.

Apa yang Anda sarankan ?

Terima kasih telah menjawab kedua pertanyaan!

terima kasih telah mengajukan kedua pertanyaan itu. saya juga mengalami masalah yang sama,

Jika Anda menginisialisasi pipenv di direktori yang salah dan harus menggunakan direktori virtualenv dari direktori yang benar, Anda bisa mendapatkan jalur virtualenv dengan melakukan pipenv --venv dan memindahkan PIpfile dan Pipfile.lock ke direktori yang benar.

echo ${PATH_OBTAINED_FROM_PREVIOUS_COMMAND} > .venv di direktori yang benar dan seharusnya berfungsi dengan baik.

Saya perhatikan hari ini bahwa jika ada pipfile di direktori induk, pipenv mengabaikan variabel lingkungan export PIPENV_VENV_IN_PROJECT=1 dan menginstal venv di direktori induk sebagai gantinya. Ini pada rilis 2018.11.26 . Jika Anda menghapus pipfile dari direktori induk, pipenv berfungsi seperti yang didokumentasikan.