Python 3.3 termasuk dalam pustaka standar paket baru venv. Apa fungsinya, dan apa bedanya dengan semua paket lain yang sepertinya cocok dengan regex (py)?(v|virtual|pip)?env?

Paket PyPI tidak di perpustakaan standar:

• virtualenvadalah alat yang sangat populer yang menciptakan lingkungan Python terisolasi untuk pustaka Python. Jika Anda tidak terbiasa dengan alat ini, saya sangat merekomendasikan mempelajarinya, karena ini adalah alat yang sangat berguna, dan saya akan membuat perbandingan untuk itu untuk sisa jawaban ini.

  Ini bekerja dengan menginstal banyak file dalam direktori (misalnya:) env/, dan kemudian memodifikasi PATHvariabel lingkungan untuk mengawali dengan bindirektori khusus (misalnya:) env/bin/. Salinan pythonatau python3biner yang tepat ditempatkan di direktori ini, tetapi Python diprogram untuk mencari perpustakaan relatif terhadap jalurnya terlebih dahulu, di direktori lingkungan. Ini bukan bagian dari perpustakaan standar Python, tetapi secara resmi diberkati oleh PyPA (Python Packaging Authority). Setelah diaktifkan, Anda dapat menginstal paket di lingkungan virtual menggunakan pip.

• pyenvdigunakan untuk mengisolasi versi Python. Misalnya, Anda mungkin ingin menguji kode Anda terhadap Python 2.7, 3.6, 3.7 dan 3.8, jadi Anda perlu cara untuk beralih di antara mereka. Setelah diaktifkan, ia mengawali PATHvariabel lingkungan dengan ~/.pyenv/shims, di mana ada file khusus yang cocok dengan perintah Python ( python, pip). Ini bukan salinan dari perintah yang dikirimkan oleh Python; mereka adalah skrip khusus yang memutuskan versi Python mana yang akan dijalankan berdasarkan PYENV_VERSIONvariabel lingkungan, atau .python-versionfile, atau ~/.pyenv/versionfile. pyenvjuga membuat proses mengunduh dan menginstal beberapa versi Python lebih mudah, menggunakan perintah pyenv install.

• pyenv-virtualenvadalah plugin untuk pyenvoleh penulis yang sama dengan pyenv, untuk memungkinkan Anda menggunakan pyenvdan virtualenvpada saat yang sama dengan nyaman. Namun, jika Anda menggunakan Python 3.3 atau lebih baru, pyenv-virtualenvakan mencoba menjalankannya python -m venvjika tersedia, alih-alih virtualenv. Anda dapat menggunakan virtualenvdan pyenvbersama-sama tanpa pyenv-virtualenv, jika Anda tidak menginginkan fitur kenyamanan.

• virtualenvwrapperadalah serangkaian ekstensi untuk virtualenv(lihat dokumen ). Ini memberi Anda perintah seperti mkvirtualenv, lssitepackages, dan terutama workonuntuk beralih antara berbagai virtualenvdirektori. Alat ini sangat berguna jika Anda menginginkan banyak virtualenvdirektori.

• pyenv-virtualenvwrapperadalah plugin untuk pyenvoleh penulis yang sama seperti pyenv, untuk mudah mengintegrasikan virtualenvwrapperke dalam pyenv.

• pipenvbertujuan untuk menggabungkan Pipfile, pipdan virtualenvmenjadi satu perintah pada command-line. The virtualenvdirektori biasanya akan ditempatkan di ~/.local/share/virtualenvs/XXX, dengan XXXmenjadi hash dari jalur direktori proyek. Ini berbeda dari virtualenv, di mana direktori biasanya di direktori kerja saat ini. pipenvdimaksudkan untuk digunakan ketika mengembangkan aplikasi Python (sebagai lawan dari perpustakaan). Ada beberapa alternatif pipenv, seperti poetry, yang tidak akan saya daftarkan di sini karena pertanyaan ini hanya tentang paket-paket yang namanya sama.

Perpustakaan standar:

• pyvenvadalah skrip yang dikirimkan dengan Python 3 tetapi ditinggalkan dalam Python 3.6 karena memiliki masalah (belum lagi nama membingungkan). Dalam Python 3.6+, padanan yang tepat adalah python3 -m venv.

• venvadalah paket yang dikirimkan dengan Python 3, yang dapat Anda jalankan menggunakan python3 -m venv(walaupun karena beberapa alasan beberapa distro memisahkannya menjadi paket distro yang terpisah, seperti python3-venvdi Ubuntu / Debian). Ini melayani tujuan yang sama seperti virtualenv, tetapi hanya memiliki sebagian dari fitur-fiturnya ( lihat perbandingan di sini ). virtualenvterus menjadi lebih populer daripada venv, terutama karena mantan mendukung Python 2 dan 3.

Rekomendasi untuk pemula:

Ini adalah rekomendasi pribadi saya untuk pemula: mulai dengan belajar virtualenvdan pip, alat yang bekerja dengan Python 2 dan 3 dan dalam berbagai situasi, dan mengambil alat lain setelah Anda mulai membutuhkannya.

Saya hanya akan menghindari penggunaan virtualenvafter Python3.3 + dan sebagai gantinya menggunakan pustaka yang dikirimkan standar venv. Untuk membuat lingkungan virtual baru, Anda harus mengetik:

$ python3 -m venv <MYVENV>  

virtualenvmencoba untuk menyalin biner Python ke direktori bin lingkungan virtual. Namun itu tidak memperbarui tautan file perpustakaan yang disematkan ke biner itu, jadi jika Anda membangun Python dari sumber ke direktori non-sistem dengan nama jalur relatif, biner Python rusak. Karena ini adalah cara Anda membuat salinan Python yang dapat didistribusikan, ini adalah kelemahan besar. BTW untuk memeriksa tautan file perpustakaan tertanam pada OS X, gunakan otool. Misalnya dari dalam lingkungan virtual Anda, ketik:

$ otool -L bin/python
python:
    @executable_path/../Python (compatibility version 3.4.0, current version 3.4.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)

Akibatnya saya akan menghindari virtualenvwrapperdan pipenv. pyvenvsudah ditinggalkan. pyenvtampaknya sering digunakan di mana virtualenvdigunakan tetapi saya akan tinggal jauh dari itu juga karena saya pikir venvjuga melakukan apa pyenvyang dibangun.

venvmenciptakan lingkungan virtual di shell yang segar dan kotak pasir , dengan pustaka yang dapat diinstal pengguna , dan multi-python aman . Segar karena lingkungan virtual hanya dimulai dengan pustaka standar yang dikirimkan dengan python, Anda harus menginstal pustaka lain lagi pip installsaat lingkungan virtual aktif. Di-sandbox karena tidak ada instalasi pustaka baru ini yang terlihat di luar lingkungan virtual, sehingga Anda dapat menghapus seluruh lingkungan dan memulai lagi tanpa khawatir akan memengaruhi pemasangan pangkalan python Anda. Pustaka yang dapat diinstal pengguna karena folder target lingkungan virtual dibuat tanpasudodi beberapa direktori yang sudah Anda miliki, jadi Anda tidak perlu sudoizin untuk menginstal perpustakaan ke dalamnya. Akhirnya aman multi-python , karena ketika lingkungan virtual aktif, shell hanya melihat versi python (3.4, 3.5 dll) yang digunakan untuk membangun lingkungan virtual itu.

pyenvmirip dengan venvyang memungkinkan Anda mengelola beberapa lingkungan python. Namun dengan pyenvAnda tidak dapat dengan mudah mengembalikan pemasangan pustaka ke beberapa keadaan awal dan Anda mungkin akan memerlukan adminhak di beberapa titik untuk memperbarui perpustakaan. Jadi saya pikir ini juga yang terbaik untuk digunakan venv.

Dalam beberapa tahun terakhir saya telah menemukan banyak masalah dalam sistem build (paket emacs, pembangun aplikasi python mandiri, installer ...) yang akhirnya bermuara pada masalah virtualenv. Saya pikir python akan menjadi platform yang lebih baik ketika kita menghilangkan opsi tambahan ini dan hanya menggunakan venv.

Saya telah pergi ke pipenvlubang kelinci (ini lubang yang dalam dan gelap memang ... ) dan karena jawaban terakhir adalah lebih dari 2 tahun yang lalu , saya merasa sangat berguna untuk memperbarui diskusi dengan perkembangan terbaru tentang topik amplop virtual Python I sudah ditemukan.

PENOLAKAN:

Jawaban ini BUKAN tentang melanjutkan debat mengamuk tentang manfaat pipenv versus venv sebagai solusi amplop - saya tidak mendukung keduanya . Ini tentang PyPA mendukung standar yang saling bertentangan dan bagaimana pengembangan virtualenv di masa depan berjanji untuk meniadakan pilihan salah satu atau keduanya. Saya fokus pada dua alat ini justru karena mereka adalah yang diurapi oleh PyPA .

venv

Sebagai catatan OP, venv adalah alat untuk lingkungan virtualisasi. BUKAN solusi pihak ketiga, tetapi alat asli. PyPA mendukung venv untuk membuat VIRTUAL ENVELOPES : " Diubah dalam versi 3.5: Penggunaan venv sekarang direkomendasikan untuk menciptakan lingkungan virtual ".

pipenv

pipenv - seperti venv - dapat digunakan untuk membuat amplop virtual tetapi juga manajemen paket roll-in danfungsionalitas pemeriksaan kerentanan . Alih-alih menggunakanrequirements.txt,pipenvmemberikan manajemen paket melalui Pipfile . Sebagai PyPA mendukung pipenv untuk MANAJEMEN PAKET , yang tampaknya menyiratkanpipfileadalah menggantikanrequirements.txt.

NAMUN : pipenv menggunakan virtualenv sebagai alatnya untuk membuat amplop virtual, BUKAN venv yang disahkan oleh PyPA sebagai alat bantu untuk membuat amplop virtual.

Standar yang bertentangan:

Jadi jika menyelesaikan solusi amplop virtual tidak cukup sulit, kami sekarang memiliki PyPA mendukung dua alat berbeda yang menggunakan solusi amplop virtual berbeda. Debat Github yang mengamuk tentang venv vs virtualenv yang menyoroti konflik ini dapat ditemukan di sini .

Resolusi konflik:

Debat Github yang dirujuk dalam tautan di atas telah mengarahkan pengembangan virtualenv ke arah mengakomodasi venv dalam rilis mendatang :

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

Kesimpulan:

Jadi sepertinya akan ada beberapa konvergensi di masa depan antara dua solusi amplop virtual saingan, tetapi sampai sekarang pipenv - yang menggunakan virtualenv- bervariasi secara material dari venv.

Mengingat masalah yang dipecahkan pipenv dan fakta bahwa PyPA telah memberikan restunya, ia tampaknya memiliki masa depan yang cerah. Dan jika virtualenv memenuhi tujuan pengembangan yang diusulkan, memilih solusi amplop virtual seharusnya tidak lagi menjadi kasus pipenv ATAU venv .

Pembaruan April 2020

Saya mencari yang sama ketika saya menemukan posting ini . Saya pikir ini masalah alat apa yang digunakan cukup membingungkan dan sulit bagi pengguna Python baru seperti saya. Ini langsung dari situs web PyPA mengenai pipenv:

Sementara tutorial ini mencakup proyek pipenv sebagai alat yang berfokus terutama pada kebutuhan pengembangan aplikasi Python daripada pengembangan pustaka Python, proyek itu sendiri saat ini sedang bekerja melalui beberapa masalah proses dan pemeliharaan yang mencegah perbaikan bug dan fitur baru tidak dipublikasikan ( dengan keseluruhan lewat 2019 tanpa rilis baru). Ini berarti bahwa dalam waktu dekat, pipenv masih menderita beberapa keanehan dan masalah kinerja tanpa jadwal yang jelas untuk penyelesaian isses tersebut.

Meskipun hal ini tetap terjadi, pengelola proyek kemungkinan ingin menyelidiki Alat Lain untuk Manajemen Ketergantungan Aplikasi untuk digunakan alih-alih, atau bersama dengan, pipenv.

Dengan asumsi rilis pipenv April 2020 berjalan seperti yang direncanakan, dan rilis setelah itu juga tetap di jalurnya, maka peringatan pada tutorial ini akan dihapus. Jika rilis itu tidak tetap di jalur, maka tutorial itu sendiri akan dihapus, dan diganti dengan halaman diskusi tentang opsi manajemen ketergantungan yang tersedia.