Pip: `pip install -U` mengupgrade dependensi yang sudah terpenuhi

Menurut penilaian saya ini adalah perilaku yang diketahui, tidak tahu apakah itu benar-benar bug - saya kira easy_install memiliki perilaku yang sama.

Saya ingin melihat pendapat orang lain.

NB: Ada pertanyaan di StackOverflow terkait dengan ini: http://stackoverflow.com/questions/5937756/why-is-pip-look-for-download-cache-if-the-same-exact-package-is -sudah-instal

Terkait dengan masalah # 49

Ini adalah bug, dan ini adalah duplikat dari # 49.

Saya tidak berpikir itu adalah duplikat dari # 49. Saya membaca # 49 yang mengatakan bahwa install -U foo tidak boleh menginstal ulang _ foo sendiri_ jika sudah di versi terbaru - yang berbeda dari apakah harus menginstal ulang foo dependensi yang sudah terpenuhi.

Perbedaan ini penting untuk pustaka yang sulit dibangun yang memiliki rilis sering tetapi API yang cukup stabil - untuk sebagian besar, satu instalasi sudah cukup baik - saya hanya ingin menginstal ulang jika dependensi saya mulai menggunakan fitur yang lebih baru dari itu dependensi bersarang (yaitu jika persyaratan tidak lagi terpenuhi) - misalnya:

• foo 0.1 tergantung pada lxml>=2.3.0
• foo 0.2 dirilis, dan bergantung pada lxml>=2.3.0 (ketergantungan yang sama)
• lxml 2.4.0 dilepaskan

Jika saya sudah menginstal foo 0.1 dan lxml 2.3.0 , dan saya pip install -U foo , saya tidak ingin menginstal lxml 2.4.0 . Seharusnya hanya menginstal lxml 2.4.0 ketika foo mulai bergantung pada lxml>=2.4.0 .

Ah, ya, itu sedikit berbeda. Meskipun # 49 telah diperbaiki, akan ada beberapa kode tambahan yang diperlukan untuk mencapai perilaku yang Anda inginkan saat dependensi tidak pada versi terbarunya, tetapi masih memenuhi persyaratan dependensi.

Saya pikir jika kita membuat perubahan ini, beberapa orang akan terkejut. Saya dapat melihat mengapa ini diinginkan dalam kasus tertentu - tetapi saya juga dapat melihat kasus di mana perilaku saat ini (minus # 49) lebih disukai. Jadi saya di pagar yang satu ini.

Apakah opsi baris perintah tambahan sesuai? pip install foo --upgrade vs pip install foo --upgrade-recursive ? (Atau --upgrade-nonrecursive jika mempertahankan perilaku saat ini yang kompatibel dengan mundur itu penting)

membuat upgrade menjadi non-rekursif secara default akan memberikan konsistensi dengan manajer paket lain, seperti APT dan Portage. dan saya pikir ada alasan bagus untuk perilaku seperti itu, yaitu menghindari efek samping yang tidak diinginkan - jika saya ingin memutakhirkan paket P, maka saya ingin memasukkan perintah di sepanjang baris upgrade P , bukan upgrade P --but-not-other-things .

di sisi lain, saya berpikir bahwa perintah "upgrade all" (lihat # 59) harus rekursif secara default, karena "all" seharusnya benar-benar berarti "semua" secara default. dalam kasus ini, perilaku non-rekursif berarti "memutakhirkan semua paket yang diinstal secara langsung, tetapi bukan semua dependensi yang tidak diinstal secara langsung" (seperti emerge --update @world Portage tanpa --deep ).

Masalah terkait adalah jika paket yang diupgrade memiliki ketergantungan pada paket lain yang sudah diinstal tetapi tidak tersedia dari repositori, Pip akan gagal dan tidak dapat mengupgrade paket yang diminta, meskipun dependensinya terpenuhi.

Ini tampaknya terjadi dengan -I serta -U.

Karena -I adalah singkatan dari --ignore-installed , dan dimaksudkan untuk membuat pip beroperasi seolah-olah tidak ada yang diinstal saat ini, menginstal ulang semuanya adalah perilaku yang benar untuk -I . Jadi perilaku di sini hanyalah bug untuk -U , bukan untuk -I .

easy_install tidak memiliki perilaku yang sama. easy_install tidak akan menginstal ulang dependensi jika sudah terpenuhi.

ini bukan fitur atau perilaku, ini bug.

ini juga sangat mengganggu - menguji distribusi PIP untuk paket kerangka kerja, atau memperbarui pengaya kerangka kerja tunggal, berarti perlu menginstal ulang seluruh kerangka kerja dan semua dependensinya. unduhan dan pemasangan yang tidak perlu ini hanya membuang-buang waktu dan sumber daya.

bagi mereka yang hanya ingin cara untuk melakukan ini _sekarang_, singkatnya perubahan perilaku / kode menjadi "-U"

Saya pikir ini mencapai hasil yang diinginkan, bukan?

tingkatkan hanya persyaratan tingkat atas:

• pip install -U --no-deps REQS // hanya meningkatkan level teratas
• pip install REQS // Pass kedua ini akan menginstal dependensi _new_ apa pun dari upgrade

Untuk kasus paling sederhana yang sudah cukup, tapi saya rasa itu tidak berfungsi untuk file requirement.txt, atau jika ada dependensi yang memiliki update ke install_requires mereka. Kami memiliki skrip rumit yang melakukan perbedaan pada requirement.txt kami dan lebih-atau-kurang melakukan apa yang Anda gambarkan, tetapi tidak menangani kedalaman peningkatan> 1.

Apa yang memperumit masalah adalah bahwa banyak paket django mengomentari atau menghapus baris install_requires mereka karena bug ini; jika tidak, mereka berakhir dengan beberapa versi alpha dari django yang terinstal (yang telah kami alami, dan saya telah melihatnya di masalah github dari banyak paket django terkemuka.

Hai @fdintino , saya membuat tes dasar dengan persyaratan, -U, dan --no-deps dan tampaknya berhasil, yaitu item dalam file persyaratan ditingkatkan, tetapi tidak ada ketergantungan. yang konsisten dengan pemahaman saya tentang apa yang dilakukan kode tersebut. itu membosankan di sana, jadi mungkin ada kegagalan dengan ide ini.

untuk kasus di mana persyaratan tingkat atas memiliki ketergantungan "install_requires" baru, itulah mengapa saya menyebutkan perintah pass ke-2 untuk menginstalnya.

untuk kasus di mana ada "dependensi yang memiliki update ke install_requires mereka", saya tidak yakin saya mengikuti Anda di sana. Anda hanya akan menemukan dan ingin menindaklanjutinya, jika Anda ingin melakukan peningkatan rekursif penuh, bukan?

Hanya jika Anda tidak lagi memenuhi persyaratan. Jadi, misalnya, jika saya memperbarui django-sentry, dan django-sentry memerlukan django-celery>=2.5.4,django-celery<3.0 yang sebelumnya memerlukan django-celery>=2.5.3,django-celery<3.0 (mungkin karena perbaikan bug atau fitur baru), dan saat ini saya punya django-celery==2.5.3 , maka saya mengharapkannya untuk memperbarui django-celery untuk memenuhi persyaratan, seperti yang dilakukan tambalan saya. Namun, jika saya kebetulan memiliki django-celery==2.5.4 saya tidak akan mengharapkannya untuk memperbarui seledri. Dalam kasus seledri itu bukan masalah besar, tetapi ketika paket memiliki Django>1.2,Django<=1.4 , dan proyek sering ditulis untuk menargetkan Django 1.2, 1.3, atau 1.4, pemutakhiran django yang tidak terduga bisa menjadi sangat memusingkan.

terima kasih @fdintino . Saya ikuti sekarang. Anda tidak ingin menghentikan semua perilaku rekursif (yang akan melakukan peningkatan yang diperlukan untuk memenuhi persyaratan), hanya ingin menghentikan peningkatan "paksa" rekursif.

btw, komentar Anda dipotong karena pemformatan. mungkin ingin memperbaikinya untuk orang lain.

Saya memposting intisari yang memecah pencapaian perilaku yang diinginkan menggunakan 2 perintah secara berurutan yang disebutkan di atas.
Bukan karena itu membatalkan keinginan untuk tiket atau penarikan ini, tetapi itu membantu saya untuk mengonfirmasi caranya
itu berfungsi saat ini dan apa yang mungkin saat ini.
(petunjuk: dalam contoh, "b" adalah paralel dengan django yang disebutkan sebagai perhatian)

https://gist.github.com/3088149

komentar dihargai pada intinya jika ini bukan skenario.

Saya perhatikan ini sudah lama dibuka.

Saya menemukan bahwa versi pip saya sekarang memiliki opsi untuk dilakukan

pip install --upgrade --upgrade-strategy=only-if-needed package

Ini tampaknya merupakan perilaku yang diinginkan, meskipun agak bertele-tele. Secara pribadi saya pikir akan sangat bagus jika ini adalah default, tapi mungkin sudah terlambat untuk mengubahnya sekarang.

Jika terlambat untuk mengubah default, lalu saya pikir ini bisa ditutup?

Di https://github.com/pypa/pip/issues/3871#issuecomment -247789343 saya menyebutkan apa yang saya yakini sebagai cara kita akan bergerak maju dalam hal ini, dengan mereproduksi di sini:

Berputar kembali ke ini sekarang. Inilah yang menurut saya harus kita lakukan:

1. Tambahkan --upgrade-strategy = [eager / non-eager] di pip vX yang defaultnya adalah eager , dan izinkan orang untuk ikut serta ke strategi non-eager. Ini akan memungkinkan kami untuk mendapatkan beberapa pengujian dunia nyata dari orang-orang tanpa memaksa perubahan pada semua orang sekaligus.
2. Setelah kami membahas umpan balik apa pun dari 1., alihkan default --upgrade-strategy menjadi non-eager dalam pip vX + 1. Ini akan membuat kita banyak digunakan di dunia nyata dengan memaksakan perubahan pada setiap orang, tetapi memberikan jalan keluar bagi orang-orang yang, untuk alasan apa pun, dirusak oleh perubahan itu.
3. Setelah kami menangani masukan apa pun dari 2., lihat penghentian --upgrade-strategy dalam pip vx + 2 (untuk dihapus mengikuti kebijakan penghentian normal kami).

Ini akan memiliki waktu tunggu yang lebih lama sebelum non-eager ditetapkan secara default, tetapi ini memungkinkan kita untuk mengaturnya secara bertahap untuk memastikan tidak ada kasus penggunaan yang akan berubah drastis. Idealnya saya pikir kami pada akhirnya ingin menyingkirkan bendera --upgrade-strategy . Bendera semacam itu terasa seperti hanya meminta masalah dengan hal-hal yang rusak karena pada dasarnya mengharuskan kami untuk menduplikasi pengujian peningkatan kami untuk benar-benar menguji semuanya. Saya pikir itu adalah bendera yang bagus untuk ditambahkan untuk saat ini, untuk memungkinkan fase masuk dan menangani kerusakan apa pun.

Oke kedengarannya bagus, saya akan menunggu langkah 2 selesai. Tampaknya masalah lain adalah duplikat, tetapi sudah ditutup.

@xavfernandez @dstufft Bisakah ini ditutup atau akankah kita menunggu sampai saklar default?

Kami mungkin akan menunggu sampai sakelar default.

Menutup, sejak # 4500 digabungkan