Virtualenv: Spasi di jalur root dari skrip pemecah virtualenv

Dibuat pada 14 Mar 2011  ·  59Komentar  ·  Sumber: pypa/virtualenv

Saya tidak begitu yakin apakah ini adalah distribut / setuptools / virtualenv tapi,

Jika saya menginstal virtualenv di

/ var / lib / hudson / home / jobs / Minification WebHelpers / workspace / python / 2.4

lalu jalankan ./bin/easy_install:

bash: ./bin/easy_install: "/ var / lib / hudson / home / jobs / Minification: bad interpreter: Tidak ada file atau direktori seperti itu

Sepertinya ada sesuatu yang tidak mematuhi spasi kosong di nama jalur dengan benar.


bug

Komentar yang paling membantu

Seperti yang dikonfirmasi oleh @JLDH dan @gandie , masalah ini kini telah diselesaikan; dengan versi terbaru pip dan virtualenv bekerja sama dengan baik saat root dari virtualenv memiliki spasi di dalamnya.

Menutup ini! Terima kasih atas pekerjaan pada perbaikan mendasar @vsajip!

Semua 59 komentar

+1, dikonfirmasi dengan Mac OS X 10.7.3 dan Python 2.7.1

Agak menjengkelkan, akan lebih baik jika diperbaiki

Kita dapat membuat virtualenv dengan spasi pada namanya (lihat # 278), tetapi easy_install dan pip akan menemukannya nanti:

% virtualenv "foo bar"
New python executable in foo bar/bin/python
Installing setuptools............done.
Installing pip...............done.
% ./foo\ bar/bin/easy_install nose
zsh: ./foo bar/bin/easy_install: bad interpreter: "/tmp/cfl/foo: no such file or directory
127 % ./foo\ bar/bin/pip install nose 
zsh: ./foo bar/bin/pip: bad interpreter: "/tmp/cfl/foo: no such file or directory

Saya juga di sini untuk mengonfirmasi bahwa ini adalah masalah dengan OS X (10.8 di sini). Jika Anda mengedit variabel VIRTUAL_ENV dan shebang di bin Anda bisa membuatnya berfungsi, tetapi env baru tersedak ruang apa pun di jalur. Yang merupakan masalah besar untuk OS X, mengingat drive boot biasanya diberi nama "Macintosh HD", jadi setiap jalur dimulai dengan "/ Volumes / Macintosh HD ..."

Peretasan yang saya gunakan berfungsi sebagai berikut.

bin / aktifkan:

VIRTUAL_ENV='/Volumes/Macintosh\ HD/path/to/my/project'

bin / pip dan bin / easy_install:

#!"/Volumes/Macintosh\ HD/path/to/my/project/venv/bin/python"

Pip tampaknya bekerja setelah keluar dari ruang di jalan setapak.

Mengapa ini ditutup? Ini masih menjadi masalah. edit kesalahanku, itu masih terbuka

masalah ini masih terbuka.

Saya bisa menyiasatinya dengan membuat tautan simbolis dari direktori beranda saya ke yang ingin saya kerjakan (yang sebaliknya memiliki ruang di dalamnya).

Saya melihat ini juga karena Mac. Saya menyiasatinya dengan mengedit baris shebang secara manual di skrip ke! # / Usr / bin / env python dan semuanya berfungsi. Namun, seperti yang disebutkan orang lain, ini harus dilakukan dengan setiap env baru dan skrip tambahan apa pun yang diinstal di env.
Tampaknya ini adalah perbaikan yang mudah dalam kode untuk keluar dari spasi atau gunakan / usr / bin / env if is_darwin. Namun karena saya cukup pemula dalam hal ini, saya bisa saja salah.

Ini bukan hanya untuk mac, ini pada dasarnya adalah bagian dari spesifikasi / perilaku sistem * nix.

Anda tidak dapat memiliki spasi di argumen pertama dari baris shebang (mereka akan diubah menjadi argumen terpisah), dan biasanya tidak ada pelolosan / kutipan yang diizinkan.

http://lists.gnu.org/archive/html/bug-bash/2008-05/msg00053.html

Saya tahu, saya mengalami masalah ini dengan anaconda juga. Ini hanya endemik di Mac karena nama drive memiliki spasi di dalamnya.

Sepertinya ini akan dikoreksi oleh # 611. Apakah sudah ada ulasan tentang keefektifan pull request itu?

Sangat menyebalkan, harus segera diperbaiki.

Lihat tautan @Ivoz yang diposting, ini adalah batasan Unix. # 611 mungkin berfungsi untuk beberapa varian Unix, jika mereka mendukung pelolosan garis miring terbalik dalam baris shebang, tetapi tidak jelas versi mana yang berfungsi (dan kode tersebut secara membabi buta melakukannya tanpa memeriksa - yang memang tidak akan membuat masalah _lebih buruk_, tetapi menang ' tidak membantu jika tidak didukung ...)

Memang benar bahwa ini adalah hasil dari cara unix menangani garis shebang, tetapi jika # 611 memperbaiki masalah untuk beberapa sistem dan tidak memperburuk masalah untuk yang lain, apakah itu masih merupakan peningkatan?

Jika itu benar maka ya. Tetapi saya tidak dapat mengomentari # 611 karena saya bukan pengembang Unix. Mungkin ada kasus di mana itu memperburuk keadaan, saya tidak tahu. Maaf saya tidak bisa lebih membantu.

Cukup adil. # 611 mungkin perlu lebih hati-hati dilihat dan diuji untuk kasus pinggiran.

Lebih buruk lagi: di windows itu rusak di jalur Jenkins default dengan kesalahan yang sama:
FATAL: spasi putih tidak diperbolehkan di jalur interpreter Python: C: \ Program Files (x86) \ Jenkins \ shiningpanda \ jobs \ c3418983virtualenvs \ d41d8cd9

Saya baru saja terpengaruh oleh masalah ini. Mengikuti instruksi yang saya temukan di StackOverflow , saya berhasil membuat pip bekerja hanya dengan mengatur baris pertama menjadi #!/usr/bin/env python

Saya tidak yakin, bagaimanapun, apakah solusi itu berfungsi untuk semua kasus ... Maksud saya, saya tidak yakin tentang Python mana yang akan dieksekusi

Mengubah shebang dari skrip yang diinstal menjadi "env python" berarti bahwa mereka hanya akan bekerja di virtualenv yang diaktifkan. Skrip dibuat dengan jalur absolut eksplisit sehingga mereka akan selalu menggunakan Python di venv, dan dengan demikian menemukan paket terinstal yang dibutuhkan oleh skrip.

Saran saya adalah seseorang (mungkin seseorang yang terpengaruh oleh masalah ini, tetapi setidaknya seseorang di platform yang memiliki masalah dan juga memiliki cara untuk menyelesaikannya) memberikan permintaan tarik yang menerapkan pemeriksaan di sepanjang baris:

  • Jika kita memiliki spasi di pathname,
  • dan kami berada di platform XXX,
  • kemudian tulis baris shebang dengan escaping berikut untuk menangani spasi.
  • Dalam semua kasus lainnya, kembali ke perilaku saat ini.

Penambahan lebih lanjut kemudian dapat dilakukan oleh pihak yang berkepentingan hanya dengan menambahkan pemeriksaan platform tambahan.

Idealnya, alangkah baiknya untuk menyertakan komentar dengan tautan ke dokumentasi yang menegaskan bagaimana platform XXX mendukung jalur dengan spasi, sehingga pengelola di masa mendatang memiliki referensi untuk diperiksa. Secara pribadi, saya tidak jelas perbaikan apa yang berhasil dan di mana:

  1. pembahasan di sini menunjukkan bahwa tanda kutip ganda berfungsi di OSX, tetapi apakah itu bergantung pada versi OSX yang tepat?
  2. Dalam # 611 digunakan spasi untuk keluar dengan garis miring terbalik, tetapi tidak ada konfirmasi untuk OS apa itu (Linux? Versi kernel tertentu? Distro khusus?)

Perhatikan bahwa varian khusus platform semacam itu tidak boleh menggunakan /usr/bin/env . Seperti yang ditunjukkan oleh @merwok , yang menghasilkan perubahan perilaku - shebang sengaja ditulis untuk memungkinkan menjalankan skrip _ tanpa_ mengaktifkan lingkungan.

Menambahkan beberapa pengujian untuk memastikan perilakunya seperti yang diharapkan (termasuk prinsip bahwa ia jatuh kembali ketika kita tidak berada pada platform yang dikenali secara khusus) akan sangat berguna, juga, tetapi juga akan rumit, karena akan melibatkan monkeypatching ke izinkan pengujian untuk platform XXX saat Anda tidak benar-benar menjalankannya di platform tersebut.

@pfmoore Seperti yang saya sebutkan, saya baru saja terpengaruh oleh masalah ini dan saya menjalankan Linux Mint 18. Saya tidak pernah berkontribusi dengan Virtualenv tetapi saat ini saya berada di Python Brasil dan kami akan memiliki satu hari yang didedikasikan untuk sprint, saya mungkin akan memberikannya mencoba!

melarikan diri dengan garis miring terbalik atau tanda kutip tidak akan berfungsi, menurut https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00052.html

Secara eksperimental, saya dapat memverifikasi bahwa melarikan diri dengan garis miring terbalik atau tanda kutip tidak berfungsi dengan OSX 10.11.6.

virtualenv harus menjauh dari shebang yang bergantung pada kernel. Saya telah memeriksa kode sumber Linux, XNU (kernel macOS), FreeBSD, OpenBSD dan NetBSD. Tak satu pun dari mereka dapat menangani ruang di shebang.

Sebelum ada perbaikan, jangan gunakan spasi.

Saya mengirimkan tambalan yang menambahkan peringatan untuk venv baru Python 3, yang sangat mirip dengan virtualenv tetapi ditolak oleh @vsajip : http://bugs.python.org/issue28446. Memang itu bukan kesalahan Python tapi sistem operasi. Mungkin masalah ini bisa ditutup?

Sebagai poin data tambahan, perhatikan perilaku di Windows, yang tampaknya seperti yang diharapkan:

`` C: \ Users \ Vinay> \ python34 \ python -m venv "\ Temp \ aaa bbb"

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" --version
pip 6.0.8 dari C: \ Temp \ aaa bbb \ lib \ site-packages (python 3.4)

C: \ Users \ Vinay> pyzzer -i "\ Temp \ aaa bbb \ Scriptspip.exe"
Ada peluncur.
Shebang: #! "C: \ Temp \ aaa bbb \ Scripts \ python.exe"

Isi arsip:
__main__.py

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scripts \ python" -m pip install -U pip
Anda menggunakan pip versi 6.0.8, namun versi 9.0.1 tersedia.
Anda harus mempertimbangkan untuk mengupgrade melalui perintah 'pip install --upgrade pip'.
Mengumpulkan pip dari https://pypi.python.org/ [...] / pip-9.0.1-py2.py3-none-any.whl # md5 = 297 [...]
Menggunakan pip-9.0.1-py2.py3-none-any.whl yang di-cache
Menginstal paket yang dikumpulkan: pip
Instalasi yang sudah ditemukan: pip 6.0.8
Menghapus instalasi pip-6.0.8:
Berhasil menghapus pip-6.0.8

Berhasil menginstal pip-9.0.1

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" --version
pip 9.0.1 dari C: \ Temp \ aaa bbb \ lib \ site-packages (python 3.4)
``

Ya, skrip virtualenv di Windows berfungsi karena distlib mendefinisikan protokol shebang-nya sendiri di PC / launcher.c. Mungkin POSIX dapat memiliki sesuatu yang serupa - parser shebang ruang pengguna, bukan kernel yang tidak dapat diandalkan.

parser shebang ruang pengguna, bukan kernel yang tidak dapat diandalkan

Saya tidak yakin mengapa Bash tidak dapat melakukan ini (misalnya) - Saya tidak berpikir ini adalah masalah ruang kernel.

Shebang ditangani dalam ruang kernel karena seharusnya dapat digunakan di luar shell.

Detail teknis:
Pada sistem mirip UNIX (Linux, Mac, * BSD, ...), program baru dibuat melalui fork () dan exec (). exec () mirip dengan CreateProcess () di Windows, yang menjalankan program baru. Pada sistem mirip UNIX, exec () akhirnya memanggil panggilan sistem execve (). Fungsi terakhir diimplementasikan di kernel, jadi penguraian shebang dilakukan di kernel.
Ini tidak dapat diterapkan di pustaka C, atau program atau program tertaut statis yang menggunakan panggilan sistem secara langsung (melalui int 80 atau sysenter, dll.) Tidak akan berfungsi.

Mungkin kita sebaiknya melarang pembuatan lingkungan virtual dengan spasi di jalurnya. Ini tidak akan berfungsi seperti yang diharapkan

Shebang ditangani dalam ruang kernel karena seharusnya dapat digunakan di luar shell

Ya, tetapi tidak dapatkah shell melakukan parsing sendiri jika system call mengembalikan ENOEXEC ? Saya menyadari itu mungkin kaleng cacing ...

Berita menarik yang menarik - fungsionalitas kernel di Linux tampaknya telah ditulis oleh pembuat Python lama Martin von Löwis :-)

Halaman ini juga merupakan bacaan yang menarik: http://www.in-ulm.de/~mascheck/various/shebang/

Ya, tetapi tidak dapatkah shell melakukan parsing sendiri jika system call mengembalikan ENOEXEC ?

Semantik IMO yang berbeda antara shell dan kernel yang mendasarinya akan membawa banyak kebingungan bagi pengguna dan juga pengembang. Saat ini setidaknya bash dan zsh melakukan parsing saat execve () gagal, tetapi hanya untuk pelaporan error yang lebih baik, tidak menyediakan fallback.

Berita menarik yang menarik - fungsionalitas kernel di Linux tampaknya telah ditulis oleh pembuat Python lama Martin von Löwis :-)

Menarik! Saya tidak menyadarinya :) Juga terima kasih atas materi ekstra. Meskipun membaca kode sumber kernel adalah cara tercepat, dokumen semacam itu masih berguna.

Tentang ide @fbidu :

Mungkin kita sebaiknya melarang pembuatan lingkungan virtual dengan spasi di jalurnya. Ini tidak akan berfungsi seperti yang diharapkan

Membuat lingkungan virtual dengan jalur yang rapuh berguna untuk menguji kasus sudut dalam penanganan jalur. Dalam contoh ini, ini menunjukkan bagaimana kernel rusak. Ide saya adalah menambahkan peringatan daripada melarang, seperti tambalan yang saya posting ke http://bugs.python.org/issue28446

Saya pikir # 994 "Pip gagal dengan ruang di jalur virtualenv" adalah duplikat dari masalah ini.

Saya ingin mengulangi komentar dari https://github.com/pypa/virtualenv/issues/997#issuecomment -270681253, "virtualenv rusak dengan parsing kernel shebang yang rapuh." Dan dalam semangat itu, # 1014 "Tidak kompatibel dengan direktori yang memiliki emoji di jalurnya" adalah contoh lain dari virtualenv yang rusak oleh parsing kernel shebang yang rapuh. Saya berani bertaruh masalah terjadi dengan karakter non-ASCII di jalur, sebenarnya.

Mungkin kita harus mengumpulkan ketiga aspek parsing kernel shebang yang rapuh menjadi satu masalah, sehingga kita dapat yakin bahwa satu perbaikan dapat mengatasi spasi, panjang, dan karakter non-ASCII di jalur virtualenv? Saya menominasikan masalah ini, karena ini yang tertua.

Sementara kami mengerjakan perbaikan, saya pikir akan baik untuk virtualenv untuk mencetak peringatan ketika diminta untuk membuat lingkungan di jalur yang a) memiliki spasi, b) terlalu panjang, atau c) memiliki karakter non-ASCII. Kalimat dalam beberapa dokumentasi juga akan membantu.

Saya berani bertaruh masalah terjadi dengan karakter non-ASCII di jalur, sebenarnya.

Saya percaya alasan untuk # 1014 ada di virtualenv daripada di kernel. Saya memiliki tambalan yang memperbaiki masalah yang sangat mirip di # 900.

Halo semua,
Ini sangat menjengkelkan dan membuang-buang waktu karena sesuatu yang tampaknya sangat sederhana (setidaknya penyebab sederhana).

Bagaimana dengan mengganti nama (bila memungkinkan), atau menggunakan tautan (membuat direktori seperti /virtualenvs/python3.5 tanpa spasi, lalu membiarkan ini menjadi tautan lunak ke direktori asli?)

membuat direktori seperti /virtualenvs/python3.5 tanpa spasi

Proyek virtualenvwrapper lain telah melakukan sesuatu yang sangat mirip.

sesuatu yang tampaknya sangat sederhana (setidaknya penyebab sederhana).

Tidak ada yang sederhana. Penyebabnya terkait dengan kode parsing kernel dan penyelesaiannya memerlukan penanganan shebang ruang pengguna.

Ini masih menjadi masalah 6 tahun kemudian?

Masalah ini membuat saya tersandung 2 minggu yang lalu. Ya, itu masih menjadi masalah.

Perhatikan bahwa karena ini adalah masalah Unix daripada masalah virtualenv, tidak mungkin itu akan "diperbaiki" kecuali pembatasan kernel Unix dihapus ...

Bug virtualenv pertama adalah bahwa virtualenv memilih untuk mengimplementasikan file yang dapat dieksekusi shell dengan menggunakan fitur kernel Unix tertentu, meskipun fitur tersebut memiliki keterbatasan yang secara rutin menimbulkan masalah bagi pengguna virtualenv. Virtualenv dapat memperbaikinya dengan menggunakan mekanisme berbeda untuk file yang dapat dieksekusi shell. Bug virtualenv kedua adalah tidak memiliki dokumentasi tentang bagaimana pengguna harus menggunakan virtualenv untuk mengatasi bug pertama (buat virtualenv hanya di jalur pendek dengan karakter hanya ASCII dan tanpa spasi). Bug virtualenv ketiga adalah bahwa ia tidak memiliki mekanisme yang mendeteksi kasus di mana pengguna memilih jalur virtualenv yang akan memicu bug pertama, dan mencetak pesan peringatan yang berguna. Ada banyak hal yang dapat dilakukan kontributor virtualenv untuk memperbaiki situasi.

@JDLH Tentang "bug" pertama Anda: ini tidak ditangani oleh virtualenv tetapi distlib, dan ada implementasinya di https://bitbucket.org/pypa/distlib/pull-requests/31/. Saya harap saya bisa punya waktu untuk mempelajari internal distlib dan membalas komentar Vinay Sajip dengan baik tetapi sayangnya saya tidak.

Bug virtualenv pertama adalah virtualenv memilih untuk mengimplementasikan file shell-executable dengan menggunakan fitur kernel Unix tertentu

@JDLH Ini tidak khusus untuk virtualenv - _all_ File skrip Unix (yaitu file dengan baris shebang) menggunakan fitur kernel ini - dan tidak ada alasan kuat untuk virtualenv (atau apa pun) untuk menemukan kembali metode pengiriman skrip yang benar-benar baru, ketika mekanisme yang ada digunakan secara luas dan dipahami dengan baik. Jika Anda menulis skrip dengan tangan yang memiliki spasi di jalur interpreter (tidak melibatkan virtualenv ), ini akan menunjukkan masalah yang sama.

Ada banyak hal yang dapat dilakukan kontributor virtualenv untuk memperbaiki situasi.

Mungkin ada banyak panggilan tentang waktu kontributor. Masalah ini memengaruhi jumlah kasus yang relatif kecil di mana jalur / jalur panjang dengan spasi digunakan. Mungkin beberapa dari pengguna yang terpengaruh dapat membantu kontributor untuk membantu mereka dengan mengusulkan tambalan yang akan membantu dengan deteksi dan pesan peringatan? Hanya sebuah ide.

@ yan12125 distlib memungkinkan seseorang untuk menentukan eksekusi di baris shebang bagaimanapun yang diinginkan. Batasan kernel pada spasi / garis panjang mungkin tidak akan pernah diperbaiki oleh pengembang Linux karena kompatibilitas ke belakang. Seseorang bisa saja menyediakan string khusus untuk shebang yang dapat dieksekusi (menggabungkan ekuivalen umum untuk peretasan skrip Mozilla) dan distlib harus menuliskannya ke dalam skrip, sehingga orang dapat bereksperimen dengannya hanya sebagai distlib user (karenanya tanpa _need_ untuk melihat internal, AFAICT).

Ini tidak khusus untuk virtualenv

@vsajip Ini adalah pernyataan yang benar - perangkat lunak lain menggunakan mekanisme shebang yang sama yang dipilih virtualenv - tetapi melewatkan inti dari masalah ini. Tidak ada tentang nilai yang diberikan oleh virtualenv yang menuntutnya menggunakan shebang. virtualenv dapat menggunakan mekanisme yang berbeda, tetapi memilih shebang, dan dengan demikian virtualenv benar-benar mewarisi batasan shebang.

tidak ada alasan kuat untuk virtualenv (atau apa pun) untuk menemukan kembali metode pengiriman skrip yang benar-benar baru

Saya pikir apa yang Anda katakan adalah bahwa masalah yang dialami oleh orang-orang yang telah menghadapi masalah ini selama bertahun-tahun tidak "memaksa". Saya pikir alasan mengapa begitu banyak orang menemukan dan mengomentari masalah ini selama bertahun-tahun adalah karena mereka menganggap masalah ini "menarik". Saya pasti melakukannya.

Mungkin beberapa dari pengguna yang terpengaruh dapat membantu kontributor untuk membantu mereka dengan mengusulkan tambalan yang akan membantu dengan deteksi dan pesan peringatan? Hanya sebuah ide.

Saya memilih kata "kontributor" untuk menyertakan baik pendukung yang melakukan sebagian besar pekerjaan di virtualenv, dan pengunjung seperti saya yang merasa masalah ini cukup menarik untuk berusaha mengurangi dampaknya. Cukup adil untuk mengatakan bahwa kami yang merasa masalah itu menarik harus menyumbangkan tambalan.

Akan sangat membantu jika pendukung yang memahami virtualenv dengan baik dapat menyarankan pendekatan yang menjanjikan. Jika saya ingin menyisipkan pesan peringatan untuk pengguna yang mengetik virtualenv ~/my\ long\ path\ with\ spaces , di mana sebaiknya kode itu berada? Apakah ada kendala yang tidak jelas pada tambalan seperti itu, yang dapat dibagikan oleh pendukung, untuk menghilangkan hambatan dari pengunjung yang mengerjakan kontribusi pertama mereka? Apakah pendukung memiliki beberapa keberatan historis untuk menerima tambalan seperti itu? (Maksud saya, saya tidak bisa menjadi orang pertama yang berpikir untuk menambahkan pesan peringatan. Pasti ada alasan mengapa hal itu belum terjadi.)

Ada satu jalur terkenal yang berisi spasi dan tidak dapat diubah: /Users/iulian/Library/Mobile Documents/com~apple~CloudDocs . Jadi siapa pun yang ingin menyimpan beberapa skrip yang dikelola dengan virtualenv di iCloud mengalami masalah ini.

Akan sangat membantu jika pendukung yang memahami virtualenv dengan baik dapat menyarankan pendekatan yang menjanjikan.

Nah, jika kami mengetahuinya, kami mungkin tidak akan membiarkan masalah ini tidak terselesaikan begitu lama, mengingat banyaknya kritik yang tampaknya kami dapatkan karena melakukannya :-(

Jika saya ingin menyisipkan pesan peringatan untuk pengguna yang mengetik virtualenv ~ / my \ long \ path \ with \ spasi, di mana sebaiknya kode itu berada?

Anda bisa mulai dengan melihat kode parsing argumen, menambahkan tanda centang setelah jalur ditentukan.

Apakah ada kendala yang tidak jelas pada tambalan seperti itu, yang dapat dibagikan oleh pendukung, untuk menghilangkan hambatan dari pengunjung yang mengerjakan kontribusi pertama mereka?

Mereka sebagian besar dapat ditemukan dengan mencari daftar masalah di sini untuk berbagai komentar yang dibuat pada ini dan masalah lain selama bertahun-tahun, tetapi untuk memulai dengan, Anda perlu untuk tidak menolak jalan ketika mereka akan bekerja - dan itu berarti bekerja apa keterbatasan OS memaksakan. Ini sangat bervariasi antar sistem. Windows mengizinkan spasi dan nama file yang panjang, beberapa sistem Unix mengizinkan spasi, beberapa memerlukan jalur dengan spasi untuk dikutip, beberapa memiliki batas panjang yang sangat pendek (32 karakter?) Beberapa lagi, ... Banyak batasan tidak terdokumentasi dengan baik, dan sangat sedikit kontributor memiliki akses ke sistem yang memadai untuk dapat menguji semua kemungkinan yang cukup untuk melengkapi dokumen yang tersedia.

Apakah pendukung memiliki beberapa keberatan historis untuk menerima tambalan seperti itu?

Tidak, selain "jangan menganggapnya sesederhana yang Anda pikirkan pada pandangan pertama, dan jangan abaikan semua sistem yang beragam (terkadang sangat tidak jelas) yang harus kami dukung".

Jika seseorang benar-benar ingin mencoba hal ini - dan mereka harus sadar bahwa ini bukan sesuatu yang secara pribadi saya rekomendasikan sebagai "kontribusi pertama" - maka mereka harus mulai dengan membaca semua riwayat yang tersedia dalam berbagai masalah (beberapa ditautkan dari yang satu ini, yang lain mungkin tidak, beberapa mungkin di pip tracker dan mungkin bahkan pelacak distlib atau setuptools) dan meringkas dalam PR baru kendala yang diberlakukan oleh berbagai OS. Mengusulkan bahwa sebagai tambalan dokumentasi yang menyatakan "kecuali kondisi ini terpenuhi, header shebang yang digunakan oleh virtualenv tidak akan berfungsi seperti yang diharapkan, sehingga virtualenv tidak mendukung pembuatan lingkungan di direktori yang tidak cocok dengan kondisi yang dinyatakan". PR dapat menyertakan perubahan kode untuk memperingatkan jika kondisi yang didokumentasikan tidak terpenuhi, atau dapat mengusulkan ini sebagai pekerjaan di masa depan (seperti yang saya ingat, cukup sulit untuk introspeksi detail sistem dengan cukup tepat untuk mengetahui batasan apa yang berlaku - pertimbangkan "Ubuntu dengan kernel yang ditambal "...). Secara pribadi, saya akan baik-baik saja dengan peringatan yang hanya menandai kasus yang diketahui di mana sesuatu akan gagal, dan diam jika tidak yakin. Tapi saya juga akan baik-baik saja dengan tambalan khusus dokumen pada tahap ini.

Anda kemudian perlu mendapatkan review dari patch Anda dari orang-orang yang memiliki akses ke sistem yang Anda cakup - seperti disebutkan, pengembang inti tidak dapat membantu di sini karena tidak ada dari kita yang menggunakan (misalnya) FreeBSD, atau OpenBSD, atau Solaris, atau ...

Anda juga bisa melakukan sebagian pekerjaan, dan membuat PR yang menambahkan dokumen dan peringatan hanya untuk (katakanlah) OSX. Saya tidak tahu apakah itu akan menghentikan keluhan tentang masalah ini (saya tidak tahu sistem apa yang paling sering muncul ini) tetapi mungkin itu sudah cukup. Mungkin salah satu pengembang inti yang menggunakan OSX akan baik-baik saja dengan menggabungkannya.

Apakah itu membantu?

Mungkin saya tidak memahami sesuatu, tetapi tidak bisakah masalah ini diselesaikan dengan memiliki (misalnya) bin/pip berisi

#!/bin/sh
"/my/long path/with spaces/pythonx.y" "/path/to/my project/with spaces/venv/bin/real-pip" "$@"

dan kemudian memindahkan skrip pip ke real-pip ? Saya tidak mengerti mengapa kita harus menggunakan shebang secara langsung.

@ raxod502 Saya berasumsi bahwa Anda sadar ini tidak akan bekerja pada Windows. Juga, saya pikir mantera "normal" yang diperlukan pada baris kedua lebih kompleks daripada yang Anda berikan (meskipun secara pribadi saya tidak tahu mengapa). Anda mungkin dapat menemukan pendekatan yang tepat melalui pencarian web. Dengan pendekatan Anda, apa yang akan terjadi untuk jalur dengan karakter " atau $ ?

Dengan asumsi Anda dapat mengatasi masalah semacam ini, saya kira langkah selanjutnya adalah Anda mengirimkan PR (sesuai komentar di atas) dan kami dapat memperdebatkan secara spesifik tentang itu. Anda harus melibatkan setidaknya satu dari pelaku inti virtualenv yang bekerja pada Unix - sebagai pengguna Windows saya tidak akan bersedia untuk menggabungkan PR khusus Unix seperti ini sendiri.

@prima
solusi yang diusulkan oleh @ raxod502 juga dapat bekerja pada windows dengan file script bat, afaik?

@gst Jawaban singkat, tidak. Jawaban panjang di http://paul-moores-notes.readthedocs.io/en/latest/wrappers.html Ada banyak diskusi tentang hal ini selama bertahun-tahun, dan setiap kali seseorang memiliki datang dengan solusi selain exe wrapper, ada masalah.

Dalam kasus ini, harap diingat bahwa masalah ini tidak ada di Windows . Jadi sama sekali tidak ada alasan untuk mengubah apa pun di lingkungan Windows - perubahan apa pun harus dibatasi hanya untuk Unix.

terima kasih untuk jawaban yang bagus :)

selain pembungkus exe, ada masalah.

secara pribadi saya bisa hidup dengan itu (jika harus).

Saya telah memperbarui distlib untuk menangani jalur panjang dan jalur dengan spasi. Saya tidak menggunakan patch Harald Nordgren secara langsung (ada beberapa masalah - misalnya tidak ada pengujian) tetapi pendekatannya sama - menggunakan '/ bin / sh' sebagai executable. pip / virtualenv pengelola mungkin ingin menguji setelah secara lokal menjual versi terkini dari repositori distlib .

Versi pengembangan pip sekarang tidak menjadi vendor versi distlib yang lebih baru ini, yang berarti pip sekarang menangani spasi dalam nama direktori dengan baik.

Seperti yang saya pahami, setelah rilis pip dan rilis virtualenv berikutnya dibuat, masalah ini akan diperbaiki - setiap virtualenv baru yang dibuat akan mendukung ruang di jalur, seperti biner yang diinstal oleh pip (kecuali mungkin dalam beberapa kasus unik seperti setuptools 'pembungkus yang tidak langsung dipasang oleh pip).

Saya baru saja mulai menggunakan gvfs untuk me-mount share samba di ruang pengguna dan menemukan virtualenv / pip dll dihapus karena punction di jalur mount yang dihasilkan oleh gvfs.

Tidak ada spasi di jalur, tetapi banyak hal lain untuk membuat virtualenv / pip dll bertekuk lutut mencoba berlari di dir seperti

/run/user/1000/gvfs/smb-share:server=bolt,share=eng/projects/msp/mrfbus/land

Sejauh yang saya lihat tidak ada opsi saat ini di gvfs untuk mencegah tanda baca di jalur titik kait yang dihasilkannya. Satu-satunya solusi saya adalah tidak pernah membuat virtualenv pada gvfs mount, yang tampaknya sedikit menyedihkan

@pradyunsg Apakah ada jadwal untuk rilis pip berikutnya? Yang terakhir sudah lebih dari setahun yang lalu , dan tampaknya agak bodoh menunggu begitu lama untuk perbaikan yang sangat sederhana ini muncul di virtualenv.

Hai @ raxod502!

Ya, kami ingin segera mengeluarkannya. Masalahnya adalah kami kekurangan waktu pengembang untuk mengeluarkan PEP 518, yang merupakan sesuatu yang ingin kami lakukan. Mungkin saja ada pip 10 tanpa PEP 518 tetapi sekali lagi, itu tergantung pada menemukan waktu untuk menyelesaikan rencana itu.

Tampaknya bug ini diperbaiki oleh pip 10.0.0 , dirilis 14-04-2018. Sebenarnya, perbaikannya ada di distlib 0.2.6 , yang di pip dengan PR4819 mereka pada Oktober 2017, yang pertama kali muncul di pip 10.0.0b2.

Perbaikan yang mendasarinya tampaknya berada di komit distlib 9285cca . Seperti yang dikomentari vsajip di sini pada 28 Mei 2017 , pendekatannya mengikuti ide Harald Nordgren: tetap gunakan shebang sederhana untuk kasus sederhana (OS bukan Posix, atau jalur cukup pendek dan tidak memiliki spasi), tetapi untuk kasus non-sederhana gunakan perintah /bin/sh exec sebagai gantinya, yang dapat menangani path yang berisi spasi atau panjang.

Saya melakukan tes cepat di Mac OS X 10.11.6, membuat virtual env di jalur yang panjang dengan spasi di dalamnya, kemudian meminta pip3 install , dan tampaknya berhasil. Saya belum sepenuhnya menguji bahwa semua yang dijelaskan dalam bug ini diperbaiki di setiap OS.

Setelah memutakhirkan pip dari 9.0.1 ke 18.1 (mereka beralih ke versi berbasis kalender) dan virtualenv dari 15.0.1 ke 16.0.0 menggunakan Ubuntu 16.04.5 LTS, masalahnya tampaknya hilang:

sudo pip install --upgrade pip
sudo pip install --upgrade virtualenv

Sekarang semua pip perintah bekerja dengan baik di virtualenv yang memiliki spasi di jalur root mereka.

Seperti yang dikonfirmasi oleh @JLDH dan @gandie , masalah ini kini telah diselesaikan; dengan versi terbaru pip dan virtualenv bekerja sama dengan baik saat root dari virtualenv memiliki spasi di dalamnya.

Menutup ini! Terima kasih atas pekerjaan pada perbaikan mendasar @vsajip!

Tiket lama: tapi kenapa tidak

! / usr / bin / env python?

@rirl , menurut saya meninggalkan komentar pada Masalah tertutup sepertinya tidak akan menarik perhatian ide Anda. Masalahnya diberi solusi. Jika Anda berpikir bahwa virtulenv baru, dengan solusi ini, akan ditingkatkan dengan melakukan sesuatu secara berbeda, maka Anda mengusulkan perubahan baru. Pertimbangkan untuk membuka Masalah baru, katakan perubahan apa yang menurut Anda harus terjadi, dan buat alasan mengapa perubahan itu lebih baik daripada virtualenv baru.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat