Hmm, mungkin kita memerlukan perintah untuk membuat daftar semua versi paket yang tersedia di PyPI.
Apa yang Anda pikirkan?

Suka:

$ pip list Django

1.2.4

1.2.3

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

$

Original Comment By: Hugo Lopes Tavares

saya suka ide itu.

Original Comment By: CarlFK

Saya baru saja menerapkannya di garpu saya. Saya ingin pendapat carljm, jezdez dan ianb
sebelum penggabungan.

Periksa di sini: https://bitbucket.org/hltbra/pip-list-
perintah/perubahan/e5c135a46204

Original Comment By: Hugo Lopes Tavares

Saya belum memikirkan ini secara mendalam, tetapi tampaknya lebih baik bagi saya untuk meningkatkan
perintah "search" untuk juga mencantumkan versi (mungkin daftar semua versi dengan tanda -v
atau sesuatu), daripada menambahkan perintah baru yang terpisah. Fungsionalitas ini
tampaknya secara logis menjadi bagian dari pencarian.

Original Comment By: Carl Meyer

Saya akan baik-baik saja dengan menambahkan ini ke pencarian selama ER saya yang lain diterapkan
juga sehingga saya tidak mendapatkan 3000 baris (benar-benar) ketika saya mencari versi Django.
(ada lebih dari 1000 hits untuk "pip search django" karena semua django-foo
paket. )

Original Comment By: CarlFK

Saya pikir tidak perlu menunjukkan versi apa yang akan diinstal selama
ada daftar versi yang tersedia, karena mudah untuk menentukan mana dari
ini adalah yang terbaru. Selanjutnya tidak ada alasan untuk menggunakan bendera baru untuk
aktifkan output dari daftar ini, karena overhead cenderung ke nol. Dia
hanya perubahan kecil:
https://bitbucket.org/jumpa/pip/changeset/62076643cf33

Original Comment By: jumpa

Hai Carl, saya ingin menambahkan opsi untuk perintah pencarian, tetapi ketakutan saya
terjadi apa yang terjadi dengan menginstal perintah: jika Anda ingin "meningkatkan" a
paket, Anda perlu menggunakan opsi "instal" - itu aneh, dan kami tahu itu.

Dan jika kebanyakan orang berpikir menambahkan opsi untuk mencari lebih baik, saya juga tidak mengerti
banyak masalah tentang menggunakan search --versions atau search -v.

Original Comment By: Hugo Lopes Tavares

Saya pikir mencantumkan semua versi yang tersedia secara default terlalu bertele-tele. Beberapa
paket memiliki banyak versi yang tersedia di pypi - sepuluh atau dua puluh tidak jarang
sama sekali. Mencantumkan versi terbaru secara default dan semua versi dengan bendera
tampaknya masuk akal.

Dan saya setuju dengan CarlFK bahwa kami juga membutuhkan perbaikan untuk pencarian membuatnya
lebih mudah menyempit. Masalahnya adalah kita bergantung pada apa yang diberikan API PyPI kepada kita,
yang tidak banyak: kami tidak akan mengunduh semua PyPI dan melakukan regex
cari secara lokal! Saya akan menyukai sesuatu seperti --exact flag untuk dicari sebagai
bagian dari perubahan ini, sehingga Anda dapat mencari misalnya "--exact Django" dan hanya mendapatkan
Django sendiri dalam hasil Anda.

Original Comment By: Carl Meyer

Hai jumpa, Ide bagus untuk menampilkan versi menggunakan yang didapat dari xmlrpc
koneksi!

Saya mendapat snip berikut mencari pip:

pip                       - pip installs packages.  Python packages.  An

penggantian easy_install (versi: 0.2, 0.2.1, 0.3, 0.3.1, 0.4, 0.5, 0.5.1,
0.6, 0.6.1, 0.6.2, 0.6.3, 0.7, 0.7.1, 0.7.2, 0.8, 0.8.1, 0.8.2)

Ini akan menjadi daftar paket yang besar, menggunakan banyak versi -
karena pencarian kami peduli dengan nama dan ringkasan. Haruskah kita peduli tentang itu?

Original Comment By: Hugo Lopes Tavares

Sebagai pengguna akhir, saya menyukai gagasan memiliki perintah daftar yang terpisah*. Seiring waktu
menjalankan perintah terpisah mungkin lebih mudah untuk dimodifikasi dan ditingkatkan secara terpisah. Ke
membuat perintah daftar terpisah lebih berguna, Anda dapat menunjukkan versi mana, jika
apapun, saat ini diinstal.

pip list Django


1.2.4

1.2.3 installed

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

Catatan: Banyak manajer paket populer seperti YUM(RedHat), pkglist(BSD),
dpkg(Debain) memberikan tanda daftar atau perintah terpisah.

Original Comment By: Kelsey Hightower

Carl, saya sedang memikirkan hari lain tentang masalah ini, dan saya harus setuju dengan
Kelsey: perintah lain tidak buruk.

Pikirkan tentang kita menggunakan bendera untuk menunjukkan bahwa saya hanya menginginkan nama paket itu, dan
bendera lain untuk menunjukkan saya ingin mengambil semua versi yang tersedia.

Ini agak aneh.

Mari kita coba ilustrasikan:

$ pip search -v --exact Django

melawan

$ pip list Django

Gagasan Kelsey untuk menunjukkan versi apa yang diinstal hanya meningkatkan daftar
memerintah.

Original Comment By: Hugo Lopes Tavares

Saya membuat perubahan menjadi perintah pencarian.

Karena perintah pencarian sudah menunjukkan versi terinstal dan terbaru yang tersedia, mungkin lebih masuk akal untuk menambahkan perintah pencarian ke daftar juga semua versi yang tersedia juga.

Inilah perubahan saya: https://github.com/phuihock/pip/commit/46bad23b5bf31850a02803ea1ca18be5deca9db3

Apa statusnya dengan ini? Bisakah seseorang melihat versi terbaru yang tersedia di PyPI dengan menggunakan pip?

Apakah ini sudah diterapkan? Ini telah mengganggu saya selama sekitar dua tahun sekarang, dan saya akan senang melihat ini diselesaikan.
Pencarian terbatas yang dikombinasikan dengan tanda untuk versi tampak seperti solusi yang sangat berguna.

Hanya ingin menambahkan di sini bahwa saya baru saja menemukan utas ini saat melakukan pencarian untuk cara menampilkan versi... Saya mencoba pip search -v package -- entah bagaimana itu akan masuk akal secara intuitif bagi saya: deskripsi verbose dari paket ke diinstal, termasuk info versi ...

Saya _just_ menyadari bahwa fungsi ini masih belum diterapkan setelah seorang rekan saya menanyakannya kepada saya. Apakah ada rencana yang akan tersedia di versi pip yang akan datang?

Saya yakin PR ini mungkin relevan, yang sedang dikerjakan?

Anda mungkin juga tertarik dengan pembicaraan Linuxconf 2014 "Python Packaging 2.0: Bermain Baik Dengan Orang Lain" tentang situasi saat ini, serta masa depan, kemasan python. Pembicara mengatakan (jika saya mengerti dengan benar) bahwa beberapa batasan metadata dalam pip adalah konsekuensi dari desain PyPI, yang awalnya didasarkan pada CPAN, dan pengerjaan ulang backend PyPI (sementara tetap kompatibel dengan yang sekarang menggunakan tes) harus memperbaiki situasi. Dia kebanyakan berbicara tentang "integrator sistem" yaitu pembuat paket hilir, tetapi saya kira itu akan memengaruhi hal-hal seperti masalah ini, membuatnya lebih mudah untuk diselesaikan.

+1,000,000

dan bagaimana sekarang?

Sekarang, apakah ada cara untuk menunjukkan versi mana yang terbaru tanpa menginstalnya?
Masalah ini terbuka sejak 2011 dan tambalan yang saya lihat di atas hanya satu baris. :(

Ini sepertinya fitur kecil untuk diaktifkan, bagaimana tidak ada opsi yang setara dengan mengatakan apt-cache madison pada saat ini?

Saya sangat ingin melihat versi terbaru dari paket PyPi saat mencari juga. Memiliki kecocokan yang tepat berfungsi, tetapi saya menggunakan awk sebagai solusinya.

Ini membuat saya frustrasi juga dan melihat bahwa ada sedikit atau tidak ada harapan dalam hal ini, saya memutuskan bahwa menciptakan alternatif mungkin sepadan dengan waktu saya. Bersamaan dengan masalah ini, saya menerapkan beberapa fitur lain yang diminta (seperti pencarian regex dan keluaran berwarna, dll.). Jika Anda tertarik, Anda dapat memeriksanya di sini

wget -qO- https://pypi.python.org/pypi/uWSGI | egrep -o "uwsgi-[0-9].[0-9].[0-9][0-9].tar.gz" | urutkan -u

wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep '"version"'

@andreif Ini tidak akan selalu menemukan versi yang benar (pip mengabaikan alfa, beta, kandidat rilis, dll kecuali --pre disediakan). Ini lebih dekat (tetapi tidak ada jaminan juga):
wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep -E ' {8}"[0-9."]*": \[' | sort -V | tail -n 1 | tr -d ' ":['

Oke, maka respons JSON harus menyertakan sesuatu seperti "pre-version": "1.2.3a4" , sehingga seseorang dapat memahami keduanya dengan ekspresi sederhana.

Saya tidak begitu mengerti masalah ini... Tentang apa ini?

• Menambahkan opsi baru pada pip install yang akan membuat pip hanya berjalan hingga resolusi paket dan mencetak paket yang dipilih dan keluar (melewatkan instalasi)?
• Menampilkan versi terbaru di sebelah nama paket saat menggunakan pip search ?
  
  
  
  • Mampu melihat versi terbaru dari sebuah paket di PyPI?
  
  

Yang terakhir tampaknya telah diselesaikan untuk saya dan yang pertama mungkin harus mendapatkan masalah khusus baru.

@pradyunsg Nah, jika saya ingat dengan benar, saya membutuhkan cara sederhana untuk memeriksa versi apa yang saat ini tersedia (baik rilis maupun pra-rilis). Versi ini akan diinstal oleh pip install -U [--pre] .

Saya membutuhkannya untuk skrip yang mengatur virtualenv. Ketika ada versi paket yang lebih baru, ia bertanya apakah akan memperbarui atau menyimpan versi saat ini. Jadi kasus penggunaan ini dicakup oleh pencarian pip baru.

pkg="foo"; pip install --download /dev/null --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

Posting --download - versi penghentian...

pkg="foo"; tmp="$(mktemp -d)"; pip download -d "$tmp" --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | tr A-Z a-z | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

Menggunakan sesuatu seperti:

pip install foo==

memberikan daftar semua versi yang tersedia (untuk paket pypi yang valid, molekul dalam kasus ini):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

tapi alangkah baiknya bisa mendapatkan versi yang akan diinstal menggunakan pip tanpa benar-benar mengunduh dan/atau menginstalnya ke dev/null :-)

Sepakat. Manajer paket tanpa fungsi ini adalah semacam lelucon. Bahkan contoh Anda mendapatkan daftar versi adalah peretasan lengkap untuk mengimbangi fitur lain yang tidak dimiliki manajer paket ini. Saya tidak mengatakan itu kejam, tetapi ini adalah hal-hal yang seharusnya sudah tersedia jauh sebelum delapan tahun yang lalu ketika bug yang sama sekali diabaikan ini dibuat. Saya berasumsi pip hanya akan digantikan oleh sesuatu yang sebenarnya memiliki lebih banyak fitur, tetapi juga sangat mengerikan, sangat besar & terlalu rumit. Yah, kita selalu bisa menulis sendiri.

pip-tools adalah alat berdasarkan pip yang saya yakini dapat membantu dengan beberapa hal yang ditanyakan oleh orang-orang di utas ini: https://github.com/jazzband/pip-tools

Jika Anda memberikan daftar dependensi abstrak (yaitu tanpa versi yang ditentukan), ia akan memberi tahu Anda versi spesifik dari setiap persyaratan dan dependensi yang akan diinstal.

pkg="django"; echo "$pkg" | pip-compile - --output-file - | egrep -i '^'"$pkg"'=' | cut -d '=' -f 3- sama konyolnya (lebih konyol jika Anda menghitung bahwa itu adalah hal lain yang harus Anda instal [lebih konyol jika Anda membutuhkan dukungan python2)

Selain itu, inti dari pip-tools (& pipenv) dapat diselesaikan dengan pip biasa dan file kendala. ( pip install -r reqs -c constraints; pip freeze > constraints ).

Menambahkan opsi baru pada pip install yang akan membuat pip hanya berjalan hingga resolusi paket dan mencetak paket yang dipilih dan keluar (melewatkan instalasi)?

Saya baru saja melakukan beberapa pembersihan yang signifikan di sini, dan masalah ini sekarang untuk melacak/mendiskusikan kasus penggunaan ini + jika/bagaimana pip akan berubah untuk mengakomodasi permintaan fungsi baru ini.

Saya telah menyembunyikan banyak komentar, mulai dari komentar yang sangat lama yang tidak lagi memiliki konteks yang relevan, hingga yang menyertakan "potensi peretasan/nugget skrip" untuk melakukan 90% pekerjaan untuk ini. Untuk grup yang terakhir, harap jangan memposting lebih banyak yang terakhir di sini -- ada forum dukungan pengguna lain di mana saran tersebut akan lebih sesuai, bukan di forum untuk membahas cara menerapkan perbaikan di alat itu sendiri. :)

Permintaan maaf kepada siapa pun yang komentarnya yang sebenarnya masih relevan dan berguna disembunyikan; Saya benar-benar tidak dapat menemukan konteks untuk banyak komentar dan komentar Anda mungkin tersembunyi dalam kerusakan tambahan.

Karena tiket ini diblokir oleh pengembangan pemecah ketergantungan (#988), saya pikir saya akan menyebutkan di sini bahwa tim sedang mencari bantuan dari komunitas untuk melanjutkan topik itu.

Kami perlu lebih memahami keadaan di mana resolver baru gagal, jadi kami meminta pengguna pip dengan dependensi kompleks untuk:

1. Coba resolver baru (gunakan versi 20.1, jalankan --unstable-feature=resolver )
2. Hancurkan :P
3. Ajukan masalah

Anda dapat menemukan informasi lebih lanjut dan instruksi lebih rinci di sini

Satu kasus penggunaan yang ingin saya soroti yang muncul dari eksperimen di #7819 yang belum saya lihat disebutkan di utas ini secara khusus merekam URL untuk mengunduh dan menginstal paket nanti , yang merupakan fungsionalitas sedikit ortogonal untuk file kunci yang dibahas di atas, dan secara khusus berguna untuk mengonsumsi hasil pip resolve tanpa harus mengunduh file besar apa pun.

Kami telah mengembangkan metode pengemasan untuk aplikasi pembelajaran mesin yang besar dan biasanya di Twitter yang kami sebut "ipex" yang dapat dikirimkan tanpa mengandung kode pihak ketiga hingga aplikasi tersebut dijalankan pertama kali (yang sangat mengurangi ukurannya). Dalam kasus pantsbuild/pants#8793, kami menghasilkan arsip pex yang dapat dieksekusi yang memanggil pustaka runtime pex untuk menyelesaikan persyaratan (pex mengeksekusi pip di bawah selimut). Saat ini saya sedang mengerjakan prototipe yang menggantikan langkah penyelesaian pex/pip penuh saat runtime dengan pengganti yang hanya mencatat URL untuk mengunduh dist dari ( req.link ). Ini sangat cepat dalam praktiknya (dan dapat di-cache dengan sangat terperinci), karena unduhan dan penyalinan file untuk membuat file pex "terhidrasi" dapat dilakukan seluruhnya secara paralel.

Kemampuan itu (mengunduh dan memasang berton-ton roda/non-roda secara paralel) bergantung pada tambahan hanya dengan mengekspos URL roda atau non-roda apa pun yang akan kami masukkan ke dalam file kunci, yang belum saya lihat disebutkan di sini. Itu memungkinkan celana untuk memanggil pip tepat sekali (untuk menyelesaikan URL unduhan) ketika file ipex dehidrasi dibuat, dan kemudian hasil dari langkah "penyelesaian" dengan URL dapat digunakan untuk mengunduh persyaratan ketika file ipex pertama kali dipanggil pada sepenuhnya mesin yang berbeda tanpa harus memanggil pip lagi.

Dibutuhkan banyak usaha di #7819 untuk menyebarkan URL dari isi resolver v1 ke output. Itu jauh lebih sedikit usaha ketika saya terakhir mencoba membuatnya bekerja dengan resolver v2. Saat ini kami mungkin berencana untuk mengirimkan beberapa versi eksperimental dari perintah --dry-run atau resolve secara internal yang mengeluarkan URL unduhan -- jika kami berhasil melakukannya, semoga membantu memunculkan masalah yang tersisa dengan --unstable-feature=resolver sementara itu! :DD

Seperti yang Anda sebutkan, desain format file kunci ortogonal dengan implementasi resolver. Namun, itu juga berarti di luar cakupan proyek pip saat ini. Telah ada diskusi tentang topik tersebut (peringatan: utas yang sangat panjang), tetapi mengingat kurangnya waktu pengembang yang tersedia, ini pada gilirannya berarti bahwa diskusi serius kemungkinan tidak akan terjadi sebelum penyelesai setidaknya distabilkan.

Terima kasih atas tautannya!!

Pada hari Minggu, 24 Mei 2020 pukul 19:34 Tzu-ping Chung [email protected]
menulis:

Seperti yang Anda sebutkan, desain format file kunci ortogonal dengan
implementasi penyelesai. Namun, itu juga berarti itu di luar jangkauan untuk
proyek pip saat ini. Telah ada diskusi tentang topik ini
https://discuss.python.org/t/structured-exchangeable-lock-file-format-requirements-txt-2-0/876/1
(peringatan: utas sangat panjang), tetapi mengingat kurangnya waktu pengembang
tersedia, ini pada gilirannya berarti bahwa diskusi serius kemungkinan tidak akan terjadi
terjadi sebelum resolver setidaknya distabilkan.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/pypa/pip/issues/53#issuecomment-633346918 , atau
berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAJ6UT3IK65CUQGUIOGBNVDRTHKMVANCNFSM4AIQRXLA
.

@cosmicexplorer Sudahkah Anda mengirimkan versi eksperimental dari perintah --dry-run atau resolve secara internal? Jika demikian, bagaimana kelanjutannya?

Anda mungkin telah memperhatikan bahwa saya sangat tertarik dengan fitur ini

Menggunakan sesuatu seperti:

pip install foo==

memberikan daftar semua versi yang tersedia (untuk paket pypi yang valid, molekul dalam kasus ini):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

tapi alangkah baiknya bisa mendapatkan versi yang akan diinstal menggunakan pip tanpa benar-benar mengunduh dan/atau menginstalnya ke dev/null :-)

Trik yang bagus!! Berguna dan nyaman !! Benar-benar mengesankan!!

potensi peretasan/nugget skrip ... tolong jangan memposting lebih banyak yang terakhir di sini -- ada forum dukungan pengguna lain di mana saran itu akan lebih sesuai, bukan di forum untuk membahas cara menerapkan perbaikan di alat itu sendiri. :)

Bukan untuk apa-apa, sungguh, tetapi ini adalah hal yang terjadi ketika Anda membiarkan bug berlama-lama (7,56 tahun dalam kasus "nugget" saya sendiri yang paling baru berkontribusi, meskipun bug yang masih terbuka ini sekarang 9,25 tahun tua). Orang-orang membagikan solusi mereka.

Saya juga ragu menyembunyikan komentar termasuk solusi akan membantu orang menyadari solusi yang akan mereka posting dalam komentar tidak diperlukan (sebagian karena tidak ada yang akan mengklik semua komentar tersembunyi itu untuk melihat apa yang telah dikatakan). Ketika seseorang datang ke bug berumur satu dekade dan tidak menemukan semacam kemajuan atau arahan dari pengelola, atau solusi, saya berani mengatakan mereka akan mempertimbangkan berbagi solusi yang diperlukan, karena membuat orang lain menderita melalui pekerjaan Anda sudah dilakukan sendiri tidak perlu.

Dan ya, komentar ini juga terjadi ketika apa yang Anda lakukan sebagai tanggapan atas bug yang masih terbuka ini terjadi.

Jangan khawatir, saya tidak akan menambahkan komentar yang tidak beralasan kecuali pip memecahkan skrip saya lagi dan bug ini masih terbuka.

Terima kasih untuk apa yang Anda lakukan. :)

@brainwane @ei8fdb Saya ingin menandai masalah ini sebagai penting dari perspektif UX - terkait dengan #8377

Ringkasan tingkat tinggi berdasarkan pemahaman saya:

• dengan penyelesai baru, pip akan kurang permisif dan menolak untuk menginstal dependensi yang saling bertentangan ( ResolutionImpossible )
• konflik ketergantungan dapat terjadi di mana saja di pohon ketergantungan
• alat yang ada (pipdeptree pip-conflict-checker) hanya menampilkan paket yang sudah diinstal, bukan yang telah diminta, tetapi gagal
• Saat ini tidak ada cara bagi pengguna untuk mengetahui di mana konflik ketergantungan _sebelum_ sebuah paket diinstal, atau ketika kesalahan ResolutionImpossible terjadi (selain secara manual memeriksa dependensi setiap proyek)

Singkatnya, kami membutuhkan cara bagi pengguna untuk mendeteksi kemungkinan konflik ketergantungan berdasarkan persyaratan tingkat atas mereka (yaitu paket yang ditentukan dalam requirements.txt atau dimasukkan langsung ke baris perintah).

Jika kami memutuskan untuk melakukan ini, nama flag yang diusulkan ( --dry-run ) harus diteliti/dibahas.

@uranusjr @pfmoore - tolong koreksi saya jika saya ada yang salah, atau melewatkan sesuatu berdasarkan diskusi kami. Terima kasih

@nlhkabu Saya setuju dengan semua komentar Anda di atas. Namun, untuk memperjelas, gaya perintah --dry-run akan memungkinkan pengguna untuk memeriksa apakah akan ada konflik ketergantungan. Tetapi seperti yang dijelaskan, itu tidak akan menawarkan bantuan tambahan apa pun dalam mendiagnosis mengapa konflik itu ada. Jadi pada dasarnya ini adalah perintah instalasi "lihat sebelum Anda melompat", berbeda dengan pendekatan "minta maaf" normal di mana kami menginstal jika kami bisa, tetapi tidak melakukan apa pun dan melaporkan kesalahan jika tidak.

Apa yang tidak disediakan ini, dan yang merupakan sesuatu yang IMO akan sangat berguna (baik sebagai sub-perintah pip, atau sama bergunanya sebagai alat pihak ke-3) adalah cara untuk membuat daftar seperti apa pohon ketergantungan tempat pip bekerja . (Ini tidak memerlukan resolver atau langkah penginstalan yang sebenarnya, ini "hanya" secara transitif mencantumkan metadata dependensi dari sumber paket).

Ini juga bisa berupa perintah pip resolve .

pip resolve adalah yang paling diharapkan, sebut saja Itu juga akan memungkinkan flagnya sendiri pada akhirnya.

Terima kasih atas klarifikasinya @pfmoore. Dari sudut pandang pengguna, saya tidak yakin seberapa banyak kegunaan --dry-run tanpa resolve ?

IMO, itu tidak cukup untuk memberi tahu pengguna bahwa mereka akan mendapatkan kesalahan - kami juga perlu memberi mereka informasi yang cukup untuk menemukan di mana kesalahan itu dan melakukan sesuatu untuk itu.

Jadi, bayangkan seorang pengguna menjalankan --dry-run ... kita dapat menyertakan sesuatu seperti ini dalam respons:

Konflik ketergantungan terdeteksi. pip tidak akan dapat menginstal d 1.0 dan c 1.0.
Konflik tersebut disebabkan oleh:
d 1.0 tergantung pada E==2.0
c 1.0 tergantung pada E==1.0
Jalankan pip resolve untuk memeriksa pohon ketergantungan.

Kami juga dapat menggunakan kembali pip resolve dalam pesan kesalahan ResolutionImpossible (lihat #8377), yang akan menjadi kemenangan besar.

@pradyunsg apakah kita punya tiket terpisah untuk pip resolve ?

@nlhkabu https://github.com/pypa/pip/issues/7819

Juga, untuk memperjelas, saya percaya kasus penggunaan yang dimaksudkan untuk pip resolve adalah untuk keduanya (dengan asumsi berhasil):

1. mengarahkan output ke file (yang biasanya akan dilakukan), atau
2. alat lain akan menggunakan/mengurai output

Untuk Twitter, menggunakan alat "ipex" seperti yang dijelaskan di #7819, kami membuat file pex yang dapat dieksekusi menggunakan perintah pip resolve yang akan menampilkan URL unduhan untuk semua distribusi yang diselesaikan alih-alih mengunduh apa pun (belum digunakan dalam produksi ). Ini, bersama dengan beberapa pengoptimalan lainnya, misalnya #8448, memungkinkan pembuatan file ipex ini dalam hitungan detik. File ipex ini kemudian mengunduh semua output distribusi dari perintah pip resolve saat pertama kali dijalankan, dari dalam pusat data yang sama -- ini memungkinkan file ipex itu sendiri menjadi megabyte, bukan gigabyte, yang meningkatkan waktu unggah dari banyak daerah.

Jadi pada dasarnya kami menyematkan versi json dari keluaran pip resolve sebagai file di arsip pex, dan kami memiliki skrip bootstrap yang membacanya untuk mengunduh distribusi secara paralel.

Ada pembaruan tentang ini?

Seseorang perlu memikirkan bagaimana menyajikan hasil resolusinya terlebih dahulu. Pemelihara pip AFAIK yang terlibat dalam pekerjaan resolver semuanya saat ini sedang berupaya meningkatkan resolver itu sendiri, jadi ini akan membutuhkan bantuan dari luar untuk bergerak maju.

Harap perbaiki saya jika saya salah, tetapi yang berikut ini tampaknya benar:

• Menginstal paket Python melibatkan eksekusi setup.py-nya.
• Tanpa opsi --dry-run , tidak ada cara yang mudah dan andal untuk mengetahui paket mana yang akan dipilih oleh resolver pip untuk diinstal.

Oleh karena itu, menurut saya menjalankan pip install berarti menyetujui menjalankan kode dari pilihan paket PyPI yang agak sewenang-wenang di mesin seseorang tanpa cara yang mudah dan andal untuk mengauditnya. Pilihan itu bergantung secara rekursif pada pilihan ketergantungan dan praktik keamanan masing-masing pembuat paket.

Itu tergantung jika proyek dan versi yang akan diinstal hanya memiliki distribusi sumber (sdist, berisi setup.py) atau juga roda (distribusi yang dibangun, berisi file teks metadata, diinstal oleh salinan file tanpa kode arbitrer dijalankan)

Bahkan dengan --dry-run, kemungkinan pip perlu menjalankan backend build untuk paket (yang untuk setuptools, melibatkan menjalankan setup.py) yang tidak memiliki roda.