Virtualenv: - alternatif yang bisa direlokasi

Bendera yang dapat direlokasi selalu eksperimental, dan tidak pernah benar-benar berfungsi; kami tidak lagi mendukungnya dan fitur tersebut telah dihentikan seluruhnya (karenanya rilis utama). Jelaskan kasus penggunaan Anda, dan kami mungkin dapat menyarankan pendekatan alternatif.

CMD export branch && cd /build_dir && \
 apt-get update -y && apt-get upgrade -y && \
 pip3 install virtualenv && \
 virtualenv --always-copy --python=python3 env && \
 git clone http://user:pass@gitlab/dev/repo.git && \
 cd /build_dir/veil-repo/code/veil-common && \
 git checkout $branch && \
 python3 install.py -p /build_dir/veil-repo/code/cli-app/ -v /build_dir/env && \
 python3 install.py -p /build_dir/veil-repo/code/controller/ -v /build_dir/env && \
 python3 install.py -p /build_dir/veil-repo/code/node/ -v /build_dir/env && \
 cd /build_dir/ && \
 ./env/bin/pip3 install -r requirements.txt && \
 virtualenv --relocatable env

Ini adalah kutipan dari Dockerfile. Akankah kode bekerja dengan benar jika saya menghapus flag --relocatable? Artinya, saya perlu membuat lingkungan terisolasi saya sendiri, yang dapat saya salin dengan cara apa pun.

Di dalam buruh pelabuhan, saya akan mengatakan 90% itu akan. Tetapi untuk memastikan Anda harus berhubungan dengan siapa yang memelihara kode buruh pelabuhan itu, mungkin benar-benar perbedaan halus tentang bagaimana kami menangani relokasi.

Kami terkadang menggunakan fitur ini karena sistem CI kami akan membuat virtualenv di direktori dengan nama yang panjang. Namanya akan cukup panjang sehingga #! akan menjadi terlalu panjang dan kita tidak dapat mengeksekusi skrip di env.

@ Nitori- untuk kasus tersebut, disarankan untuk menggunakan format python -m untuk menjalankan alat secara umum 🤔

Itu adil. Meskipun banyak paket Python berperilaku buruk dan tidak membiarkan dirinya dipanggil seperti itu.

@ Nitori- bahkan jika itu masalahnya, Anda selalu dapat memaksa pemanggilan dengan menjalankan executable melalui interpreter python di dalam folder biner; misalnya

{venv}/bin/python {venv}/bin/bad-bad-tool

di mana {venv} bisa panjang secara sembarangan 👍

Di perusahaan saya, kami menggunakan bendera --relocatable di pipelines kami untuk membantu kami menggunakan kembali virtualenv dan menghemat waktu - kami menggunakan GitLab, membangun virtualenv pada langkah awal, menyimpannya sebagai artefak dan kemudian menggunakannya kembali untuk menjalankan banyak tes paralel.

Kami bermaksud untuk menyematkan versi virtualenv tetapi karena bug kami akhirnya menarik yang terbaru sehingga pipeline kami rusak pagi ini. Kami memperbaiki bug itu sehingga disematkan dan semuanya berjalan sekarang, dan kami akan menemukan cara lain untuk menghapus bendera tersebut. Tapi, saya pikir saya akan mencatat di sini untuk menyampaikan pengalaman saya meskipun masalah telah ditutup dan saya tidak berharap bendera akan didukung di masa mendatang.

Dengan seeder data aplikasi baru yang membuat virtualenv hanya membutuhkan waktu kurang dari 100 md, pendekatan ini lebih disukai dalam kasus penggunaan Anda.

Kami menggunakan --relocatable untuk memaketkan venv dalam sebuah rpm. virtualenv dibuat di $ DESTDIR dan akhirnya dipindahkan di /opt/company .

Ini kasus saya.

Jadi, akan membantu untuk dapat lulus di awal target akhir untuk jalur yang dihasilkan?

@gaborberberarti ya!

Masih @gaborbernat , virtualenv harus dapat digunakan selama fase build, sebelum menerapkan di lokasi akhir.

Tidak yakin apa solusi yang baik di sini 🤔 Saya terbuka untuk proposal.

@gaborbernat untuk kasus seperti itu, perilaku standarnya adalah untuk membedakan builddir dan prefiks.

virtualenv memiliki argumen DEST_DIR yang mungkin menyesatkan dalam kasus ini. DEST_DIR adalah lokasi venv sebenarnya, yang secara efektif merupakan prefiks (seperti / usr, / usr / local, dll.). Jadi mungkin, mendokumentasikan virtualenv LOCATION seharusnya membuat ini lebih jelas.

Kemudian Anda dapat menambahkan opsi --destdir atau --root yang defaultnya adalah / . Dengan cara ini, virtualenv dapat bekerja terisolasi di destdir (agak seperti chroot). Saya tidak tahu bagaimana python, pip, dan skrip lain harus mengatasi ini.

AFAIK masalahnya adalah bahwa semua skrip konsol yang dihasilkan hardcode jalur selama pembuatan untuk shebang tersebut. Tidak ada cara standar untuk membuat skrip konsol yang dihasilkan ini dengan shebang di dalamnya berfungsi selama pembuatan dan selama proses setelah diterapkan. Itu kecuali setelah membangun seseorang memperbaiki shebang. Tapi itu sekarang di luar ruang lingkup pembuatan lingkungan virtual, jadi di luar kendali kami.

@gaborbernat maksud Anda kita harus mengimplementasikan ini di setuptools? Shebang apa yang dapat digunakan baik diisolasi pada waktu pembuatan maupun di lokasi target saat runtime?

Saya berpikir untuk menulis skrip virtualenv-relocate yang mengedit shebang pada virtualenv yang ada, membuatnya dapat digunakan di lokasi barunya. Sesuatu seperti :

$ virtualenv-relocate /build/dir/venv /opt/company/app/venv
Rewriting shebang of bin/pip.
Rewriting shebang of bin/pip3.5.
...
$

Saya tidak berpikir setuptools adalah tempat yang baik untuk ini juga. Ini adalah fitur yang harus menjadi bagian dari sistem build yang dibangun di lokasi A tetapi kemudian diterapkan ke lokasi B.

Nah, proyek C memungkinkan untuk membangun terisolasi hanya dengan mengedit PATH dan LD_LIBRARY_PATH. Tidak peduli sistem build apa yang Anda gunakan.

Saya tidak terbiasa dengan bagaimana C mencapai ini, mungkin seseorang dapat menjelaskan, menautkannya? Apa yang telah terjadi sebelumnya ada di sini https://github.com/pypa/virtualenv/blob/legacy/virtualenv.py#L1880 -L1894; pada dasarnya kami telah mencoba membuat beberapa jalur relatif: yaitu skrip dan pth / egg-files.

Repositori saya juga menggunakan --relocatable dan saya menggunakan skrip (setelah virtual env relocatable dibuat) untuk menyalin pustaka tambahan ke virtualenv. Dengan ini, dimungkinkan untuk membuat virtualenv yang sepenuhnya dapat direlokasi. Misal kita menggunakan ini di windows dan menambahkan virtualenv ke installer kita. Setelah instalasi, program python3 bekerja dengan baik dengan paket virtualenv.

Usecase yang sama juga berfungsi di mac dan linux untuk kami ....

@ Gagi2k apa yang Anda lakukan di sana sudah menunjukkan kerapuhan implementasi yang dapat direlokasi saat ini; Anda perlu melakukan beberapa skrip tambahan setelah env dibuat untuk membuatnya dapat dipindahkan sepenuhnya. Masalahnya adalah bagaimana Anda dapat membuat sebuah paket dapat direlokasi sepenuhnya sangat bergantung pada lingkungan target Anda. Jadi idenya di sini adalah bahwa virtualenv sendiri menyerah untuk mencoba membuat lingkungannya sepenuhnya dapat direlokasi (karena tidak dapat berhasil dalam banyak kasus) ... dan sebaliknya mendelegasikan pekerjaan sepenuhnya pada orang yang menulis skrip kustom ini, yang mencapai ini; skrip yang memiliki pengetahuan tentang lingkungan target, jadi tahu persis apa dan berapa banyak perubahan yang diperlukan untuk membuat sesuatu dapat direlokasi.

Benar, hal yang adil.

Masalah saya kurang lebih bahwa sekarang saya perlu membuat ulang fungsionalitas yang Anda berikan sebelumnya dan mengujinya di semua platform + beberapa distro untuk melakukan hal yang sama persis dengan fungsi lama.

Saya pikir saya akan mencoba untuk tetap menggunakan versi virtualenv yang lebih lama untuk saat ini sampai saya atau orang lain memiliki waktu untuk menerapkan ini.

@ Gagi2k lihat komentar saya di atas tentang ide proyek virtualenv-relocate . Saya akan senang bekerja sama dalam hal ini dengan yang lain. https://github.com/spotify/dh-virtualenv/ mungkin merupakan titik awal yang baik.

@bersace thx, saya sudah menyalin kode lama sekarang dan membuat skrip python mandiri darinya. Saya pikir saya akan menggunakannya untuk saat ini sebagai solusi drop-in, tetapi saya senang untuk beralih ke sesuatu yang lain di masa depan atau menyumbangkan skrip yang saya miliki.

@ Gagi2k maukah Anda membagikannya?

@bersace Masih dalam proses: https://codereview.qt-project.org/c/qt/qtivi/+/290859

Seluruh pembaruan virtualenv 20 menyebabkan lebih banyak masalah daripada yang diantisipasi. Menggunakan kembali fungsi lama untuk membuat skrip dapat direlokasi bukanlah masalah besar, tetapi karena sekarang didasarkan pada venv dan dengan pyvenv.cfg itu menjadi jauh lebih rumit. Misalnya pada windows, virtualenv lama menyalin banyak file base py ke/ lib / python(atau menghubungkannya). Sekarang mereka tidak disalin sama sekali tetapi pyvenv hanya menunjuk ke lokasi aslinya. Setelah lokasi asli diperbarui, virtualenv Anda perlu menanganinya dan Anda harus berharap bahwa semua yang diperlukan masih ada. Masalah yang lebih besar adalah https://bugs.python.org/issue39469 , yang membuatnya sulit untuk diberikan ke lokasi relatif di mana Anda mengatur segalanya untuk membuat virtualenv dapat direlokasi ...

Untuk saat ini, saya rasa itu tidak bisa dilakukan (tanpa pyvenv.cfg mendukungnya).

@gaborbernat Saya mungkin menyalahgunakan virtualenv untuk tujuan aslinya, tetapi apa cara resmi untuk menyediakan salinan python3 Anda sendiri dengan aplikasi Anda, karena Anda ingin mengizinkan orang untuk memperpanjangnya menggunakan pip?

@ Gagi2k Saya yakin saya melewatkan sesuatu di sini; tetapi tidak bisakah Anda mengubah pyenv.cfg hone sebagai bagian dari fase penginstalan pada mesin tertentu?

@gaborbernat Saya mungkin menyalahgunakan virtualenv untuk tujuan aslinya, tetapi apa cara resmi untuk menyediakan salinan python3 Anda sendiri dengan aplikasi Anda, karena Anda ingin mengizinkan orang untuk memperpanjangnya menggunakan pip?

lingkungan virtual dirancang untuk selalu menjadi referensi ke beberapa interpreter python di mesin. Asumsi dasarnya adalah bahwa Anda memiliki lingkungan python yang berfungsi penuh pada mesin, dan Anda hanya ingin memiliki beberapa site-packages untuknya. Saya dapat melihat beberapa nilai dalam membuat tautan tidak sepenuhnya eksplisit (seperti sekarang dengan jalur yang sepenuhnya eksplisit), tetapi jika Anda mengikuti jalur itu mengapa tidak pergi jauh-jauh dan menggunakan PyInstaller atau pex untuk mengemas kode Anda dengan python dieksekusi dimuka, tanpa referensi yang mudah rusak?

@gaborbernat Tentu, itu akan berhasil, masalah terbesar adalah bahwa sebagian besar pengguna terbiasa hanya mengganti nama folder setelah instalasi dan itu terus berfungsi ...
Tetapi saya baru tahu bahwa pengaturan PYTHONHOME juga melakukan triknya, setidaknya di windows saya membuatnya berfungsi tanpa referensi ke instalasi asli.

pex terlihat menarik dan saya akan melihatnya lebih dekat, terima kasih untuk petunjuknya.

@ gaborbernat lagi, bagaimana cara membangun virtualenv di builddir dan mengirimkannya ke .deb atau .rpm?

@gaborbernat Tentu, itu akan berhasil, masalah terbesar adalah bahwa sebagian besar pengguna terbiasa hanya mengganti nama folder setelah instalasi dan itu terus berfungsi ...

Tidak yakin mengapa mereka mengharapkan ini. Ini tidak pernah terjadi; bahkan dengan flag yang dapat direlokasi, itu benar dalam subset dari kemungkinan kasus. Oleh karena itu mengapa itu dipecat dengan v20.

@ gaborbernat lagi, bagaimana cara membangun virtualenv di builddir dan mengirimkannya ke .deb atau .rpm?

@bersace ini tergantung pada banyak kasus penggunaan Anda. Apakah deb / rpm menjamin bahwa python akan tersedia di lokasi yang sama pada mesin target? Jika demikian perbaiki jalur shebang selama instalasi 👍

@gaborbernat tergantung pada sistem python sudah cukup untuk memastikan python ada di lokasi tertentu.

Memodifikasi file yang diinstal di postinst adalah ide yang sangat buruk. Ini memerlukan untuk mengecualikan semua skrip dari dpkg realm, sehingga dpkg tidak akan menyentuhnya saat peningkatan. Itu tidak bisa diterima.

AFIAK, solusi terbaik adalah virtualenv-change-prefix yang mengedit semua shebang untuk menghapus destdir , untuk dieksekusi sebelum mengarsipkan paket terakhir.

@bersace dan apa yang akan Anda atur shebangsnya?

@gaborbernat lokasi target mutlak. misal #!/opt/company/app/venv/bin/python .

Itu sekarang akan menyiratkan bahwa menerapkan paket itu ke refroot baru selain / sekarang tidak didukung, bukan?

@gaborbernat ya, sesuai desain. File yang dikelola oleh dpkg / rpm tidak boleh dipindahkan oleh pengguna.

Ini agak berbeda dari relocatable . Tujuannya bukan untuk membuat venv relatif , tetapi untuk membedakan builddir (debian / build / ... atau% builddir) dan rundir (/).

Menutup ini karena tidak ada item yang dapat ditindaklanjuti di pihak kami. Saya akan merekomendasikan melanjutkan diskusi di sini, atau tentang proyek potensial yang mencoba menangani ini di atas virtualenv.

Sebenarnya, alternatifnya adalah dengan agak bergantung pada vendor, tanpa memversikannya.

Dalam kasus saya, saya harus zip paket python dengan dependensi yang dibutuhkan dan meneruskannya sebagai 'arsip' ke Spark on Yarn untuk mendukung program saya berjalan pada cluster Spark terdistribusi. Meskipun operasi ini dapat diselesaikan oleh Anaconda, perangkat lunak perusahaan tidak dapat digunakan di perusahaan saya. relocatable dapat menyelesaikan masalah ini di masa lalu, tetapi sekarang masalah ini hilang.

Dalam kasus saya, saya harus zip paket python dengan dependensi yang dibutuhkan dan meneruskannya sebagai 'arsip' ke Spark on Yarn untuk mendukung program saya berjalan pada cluster Spark terdistribusi. Meskipun operasi ini dapat diselesaikan oleh Anaconda, perangkat lunak perusahaan tidak dapat digunakan di perusahaan saya. relocatable dapat menyelesaikan masalah ini di masa lalu, tetapi sekarang masalah ini hilang.

Hai @jackhhh , apakah Anda menemukan solusi untuk kasus penggunaan yang sudah ada?
Kami mengalami masalah yang sama.