Pipenv: Memperbarui hanya satu dependensi yang terkunci

Itu juga bisa berguna untuk pipenv install , karena terkadang saya ingin memasang ketergantungan baru tanpa memperbarui yang lain.

Ada sedikit hal yang perlu dipertimbangkan di sini: Mengubah satu dependensi dapat mengubah keseluruhan rangkaian persyaratan.
Contoh: Memperbarui foo dari 1.0 ke 2.0 mungkin memerlukan pembaruan bar menjadi> = 2.0 (sebelumnya <2.0), dan seterusnya.

Saya tahu bahwa dalam konteks pip-tools itu sendiri (dari mana pipenv mengambil algoritma resolusi ketergantungannya), menjalankan resolusi ketergantungan hanya akan "memperbarui" paket yang diperlukan saat "mengunci kembali" jika ada file kunci yang ada. Ini dilakukan dengan memeriksa apakah pin yang ada di lockfile adalah kandidat yang valid terlebih dahulu saat memilih kandidat dalam penyelesaian. pipenv mungkin bisa melakukan hal yang sama.

Saya pikir itu ide yang masuk akal. Jika tidak, jika Anda hanya ingin memperbarui satu dependensi, pipenv harus memiliki mode untuk memblokir jika mengubah dependensi menyebabkan perubahan lain, atau Anda akan kehilangan jaminan lingkungan yang valid.

Saya harap ini membantu!

Memang itulah yang saya maksud dengan:

Itu akan menghasilkan Pipfile.lock dengan pembaruan hanya untuk my-awesome-dep dan dependensinya.

Setuju 100% - dan saya akan melangkah lebih jauh: ini harus menjadi default.

Artinya, pipenv install foo tidak boleh menyentuh apapun selain foo dan dependensinya. Dan pipenv lock seharusnya tidak pernah meningkatkan apa pun - seharusnya hanya mengunci apa yang sudah terpasang.

AFAICT, ini adalah cara kerja npm , yarn , gem , dll. tidak masuk akal untuk memiliki file kunci yang tidak benar-benar mengunci paket, tetapi mempercayai pembuat paket untuk tidak merusak sesuatu dalam rilis patch, dan karena itu memutakhirkannya tanpa diminta. Saya dapat melihat penggunaan mengizinkan peningkatan, tetapi itu harus ikut serta, karena itu lebih mengejutkan daripada tidak memutakhirkannya.

Saya minta maaf jika saya membajak masalah ini karena sesuatu yang lain, tetapi karena ini sangat erat kaitannya dengan masalah yang akan saya buat, saya pikir saya akan memulai percakapan di sini. Jangan ragu untuk memberi tahu saya bahwa saya harus membuat yang baru.

Baru saja menemukan masalah terkait ini juga: https://github.com/kennethreitz/pipenv/issues/418

Mampu menentukan pipenv install --upgrade-strategy=only-if-needed tampaknya seperti yang saya cari, meskipun tentu saja seperti yang saya sebutkan, saya pikir itu harus menjadi default, karena menjadi di pip 10. Tetapi dapat menentukannya secara semi-permanen melalui env var akan menjadi sesuatu.

Saya akan terkejut jika perubahan itu merusak alur kerja seseorang ( kata terakhir yang terkenal ), karena ini lebih konservatif daripada --upgrade-strategy=eager .

Mencoba untuk mengatasi ini dengan menyetel export PIP_UPGRADE_STRATEGY=only-if-needed di konfigurasi shell saya. Ini tidak berhasil, dan pipenv lock menunjukkan perilaku mengejutkan ini:

1. Ini "meningkatkan" paket yang tidak perlu ditingkatkan (tapi ...)
2. Itu sebenarnya tidak meningkatkan versi yang diinstal! yaitu pip freeze dan Pipfile.lock menunjukkan versi yang berbeda!

Menebak pipenv mendelegasikan ke pip untuk penginstalan, dan pip mengikuti pengaturan variabel lingkungannya, tetapi pipenv lock tidak.

@ k4nar Apa yang terjadi sekarang karena Anda merasa tidak diinginkan? Karena jika Anda mengupgrade dependensi yang memiliki persyaratan berjenjang jelas itu akan memiliki konsekuensi untuk dependensi lainnya. Apakah Anda menyarankan semacam logika resolver untuk menentukan versi terbaru dari paket tertentu _dalam konteks lockfile_ saat ini? Saya ragu untuk mendorong terlalu banyak peretasan ke logika resolusi, yang sudah rumit dan sulit untuk di-debug.

@brettdh Saya rasa saya bisa menjelaskan karena Anda memiliki sebagian besar bagian. pipenv lock tidak memasang apa pun, dan tidak mengklaim. Ini hanya menghasilkan file kunci yang diberikan lingkungan host Anda, versi python, dan Pipfile disediakan. Jika Anda memanipulasi lingkungan Anda dengan cara lain atau jika Anda menggunakan pip secara langsung / memanipulasi pengaturan pip di luar pipenv / tidak menggunakan pipenv run atau menggunakan pip freeze di dalam subkulit pipenv, itu cukup mudah untuk file kunci tidak sinkron dari pip freeze . Keduanya tidak benar-benar berhubungan.

Untuk lebih jelasnya:

1. Pipfile.lock adalah resolusi dependensi yang disematkan dengan ketat menggunakan resolver pip-tools berdasarkan Pipfile
2. Jika Anda ingin mempertahankan pin yang ketat dari semuanya sambil meningkatkan hanya satu paket, saya yakin Anda dapat melakukan ini dengan menyematkan semua yang ada di Pipfile kecuali untuk satu hal yang ingin Anda tingkatkan (perbaiki saya jika saya salah @bayu_joo

Adapun lockfile Anda dan pip freeze tidak setuju satu sama lain, saya harus mengetahui lebih banyak informasi, tetapi saya yakin kami memiliki masalah terbuka mengenai resolver lockfile kami saat menggunakan versi non-sistem python untuk menyelesaikannya.

@techalchemy : Jika saya memiliki Pipfile.lock dengan A, B, dan C di mana B adalah ketergantungan A, saya ingin dapat memperbarui A dan B tanpa memperbarui C, atau C tanpa memperbarui A dan B.
Sekali lagi tentu saja saya dapat menyematkan semua dependensi saya & dependensinya di Pipfile saya untuk melakukan itu, tetapi itu akan menjadi beban untuk dipertahankan (seperti kebanyakan requirements.txt are).

Saya setuju dengan semua yang ditulis @ k4nar . Tentu, saya bahkan bisa memasang pin
semua yang ada di requirement.txt dan tidak menggunakan pipenv. Inti dari pipenv adalah
memiliki satu alat yang membuatnya (dan perangkat virtualenv, tentu saja)
lebih sederhana untuk dikelola; yaitu semua paket dikunci secara default ke sebuah versi
yang diketahui berfungsi, tetapi seharusnya mudah untuk meningkatkan versi tertentu
sedikit (tanpa meningkatkan orang lain secara tidak terduga).
Pada Kamis, 26 Okt 2017 pukul 04.28 Yannick PÉROUX [email protected]
menulis:

@techalchemy https://github.com/techalchemy : Jika saya memiliki Pipfile.lock
dengan A, B dan C di mana B adalah ketergantungan dari A, saya ingin bisa
memperbarui A dan B tanpa memperbarui C, atau C tanpa memperbarui A dan B.
Sekali lagi tentu saja saya bisa menyematkan semua dependensi saya & dependensinya di file
Pipfile untuk melakukan itu, tetapi itu akan menjadi beban untuk dipertahankan (seperti
sebagian besar persyaratan.txt adalah).

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kennethreitz/pipenv/issues/966#issuecomment-339591307 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAFlnqUOEKARiFD8kEk3GVczF3NXBdVOks5swEKcgaJpZM4QEf--
.

Hm saya mengerti apa yang kalian katakan. Premis untuk meneruskan pengaturan ke pip bukanlah yang saya khawatirkan, itu menyelesaikan dengan pip-tools yang menjadi perhatian saya. Seperti apa perilaku ini sekarang?

@techalchemy Saya menyebutkan perbedaan pip freeze sebagai singkatan dari "versi paket yang menginstal pipenv install berbeda dari versi paket yang disimpan pipenv lock menjadi Pipfile.lock ."

Benar, ini hanya terjadi ketika saya telah mengubah argumen default pip melalui variabel lingkungan; Saya baru saja menunjukkan bahwa mengejutkan bahwa pipenv didelegasikan ke pip untuk penginstalan tetapi tidak untuk penguncian versi; yaitu, alih-alih mengunci apa yang terpasang, ia mengunci apa yang menurutnya harus dipasang, kemungkinan besar dengan pemutakhiran yang tidak diminta.

Bisakah Anda menjelaskan sedikit pertanyaan Anda? Saya pikir "menyelesaikan dengan pip-tools" mengacu pada apa yang dilakukan pipenv lock , dan alasan mengapa hal itu tidak terpengaruh ketika saya menetapkan default pip? Dan dapatkah Anda lebih spesifik tentang apa yang Anda maksud dengan "perilaku ini"?

@brettdh Mekanisme penguncian menyertakan gagasan tentang "resolusi ketergantungan" yang tidak ada di pip . Ditangani oleh pip-tools (atau lebih tepatnya, versi patchnya, terintegrasi dengan cara khusus oleh pipenv yang membawa beberapa perbedaan dengan alat aslinya). Singkatnya, mekanisme penguncian membaca Pipfile dan melakukan resolusi dependensi penuh untuk memilih satu set lengkap paket yang akan memenuhi setiap batasan yang ditentukan oleh paket yang diperlukan dan dependensinya .

@tokopedia

[...] ini diselesaikan dengan alat pip yang menjadi perhatian saya.

Saya tidak yakin bagaimana --upgrade-strategy akan mempengaruhi pip-tools , karena ini bekerja pada beberapa internal level rendah pip . Saya merasa ini tidak akan memberikan hasil yang diharapkan, karena opsi ini memperhitungkan apa yang diinstal, dan bukan itu yang ditangani dalam mekanisme itu. Tetapi kami memiliki pendekatan lain untuk ini di pip-tools yang dapat dilakukan di sini.

Perilaku "asli" pip-tools adalah bahwa ia hanya memperbarui apa yang diperlukan di lockfile (dalam konteksnya, ini adalah persyaratan.txt), tetapi ini "hilang" dalam cara resolver diintegrasikan dalam pipenv . Izinkan saya menjelaskan alasannya.

Menunjuk kembali ke resume saya tentang cara kerja pip-tools : https://github.com/kennethreitz/pipenv/issues/875#issuecomment -337717817
Ingat bagian "pilih kandidat"? Itu dilakukan dengan menanyakan objek Repository .
Di pipenv , kita langsung mengkonfigurasi PyPIRepository untuk Resolver , tetapi pip-tools melakukan sesuatu yang lain, menggunakan objek LocalRequirementsRepository , yang mana menyimpan pin yang ada dari requirements.txt sudah ada sebelumnya (jika ditemukan), dan "fallback" pada PyPIRepository .

Jadi di pip-tools , hal berikut terjadi saat memilih kandidat:

1. Kueri LocalRequirementsRepository untuk kandidat yang cocok dengan foobar>=1.0,<2.0 .
2. Periksa apakah pin yang ada memenuhi persyaratan itu:
   
   
   
   • Jika ya, kembalikan pin tersebut sebagai kandidat.
   
   
   • Jika tidak, tanyakan proxied_repository ( PyPIRepository ) untuk kandidat.
   
   
3. Gunakan kandidat yang dikembalikan

Secara efektif, ini berarti pin yang ada diberi "prioritas" sebagai kandidat untuk dicoba terlebih dahulu.

Tapi di pipenv , saat ini, itu hanya

1. Kueri PyPIRepository (langsung) untuk kandidat yang cocok dengan foobar>=1.0,<2.0 .
2. Gunakan kandidat yang dikembalikan.

Jadi, saya pikir perilaku yang sama untuk penguncian pipenv dapat dilakukan dengan mengurai Pipfile.lock untuk mendapatkan pin yang ada dan menggunakan LocalRequirementsRepository , seperti pip-tools tidak dalam perintah pip-compile .

@vphilippon, apakah Anda tahu betapa sulitnya penerapannya?

@tokopedia

• Parsing Pipfile.lock untuk mengekstrak pin yang ada: Belum melihat itu. Tergantung pada bagaimana hal-hal disusun dalam pipenv . Kita membutuhkan satu set InstallRequirements yang mewakili pin di Pipfile.lock .
• Menggunakan LocalRequirementsRepository : Cukup mudah: ubah PyPIRepository kami saat ini menjadi LocalRequirementsRepository .

Tapi, saat saya melihat ini, dan mengikuti komentar @brettdh , saya menyadari beberapa hal:

1. Perilaku default pipenv install tidak cocok dengan perilaku pipenv lock . Melakukan pipenv install requests saja tidak akan memperbarui requests jika versi baru keluar (seperti pip install ). Namun, melakukan pipenv lock akan memperbarui Pipfile.lock dengan versi terbaru requests yang cocok dengan penentu Pipfile , dan batasan ketergantungan.
   Ada 2 cara utama untuk melihat ini:
   
   
   
   • A) Pipfile.lock harus tetap stabil secara default, tidak mengubah pin kecuali diperlukan, agar tetap seperti lingkungan saat ini, dan hanya berubah jika kita mengubah lingkungan.
   
   
   • B) Pipfile.lock harus mendapatkan versi terbaru yang menghormati batasan lingkungan / dependensi untuk mendapatkan keuntungan bebas dari rentang terbuka di dependensi Pipfile dan lib, memungkinkan untuk terus memperoleh versi baru yang kompatibel di lingkungan Anda. Anda kemudian dapat menjalankan pipenv update untuk mendapatkan keuntungan dari kunci baru.
   
   

IMHO, I would align the default behavior, which would be to go with A) by default. Because right now, everytime a lock is performed (i.e. after each installation), new versions can come in, which make the lockfile *drive the update of the environment*, which seems weird. But, this is arguable of course. While in development, I might want to continuously update my requirements to no get stale, like with B), so that should also be easily doable.

1. Bahkan jika kita menggunakan LocalRequirementsRepository untuk menghindari memperbarui pin yang ada dengan benar, dan akhirnya menyelaraskan perilaku default, kita kemudian perlu menangani yang setara dengan --upgrade dan --upgrade-strategy untuk bagian penguncian . Saat ini, mendefinisikan beberapa variabel lingkungan (seperti PIP_UPGRADE dan PIP_UPGRADE_STRATEGY ) akan mempengaruhi perilaku pipenv install , tetapi tidak akan mempengaruhi pipenv lock , karena tidak mempengaruhi perilaku pip-tools (Saya mengkonfirmasi itu, karena saya tidak yakin pada awalnya).
   Jika tidak, tidak akan ada cara untuk memperbarui lingkungan tanpa menghapus Pipfile.lock (terasa kikuk, dan "semua atau tidak sama sekali") atau memerlukan versi yang lebih baru (maksud saya melakukan pipenv install requests>2.18.4 secara eksplisit, yang mengharuskan Anda mengetahui bahwa versi baru telah keluar, dan mengubah penentu di Pipfile itu sendiri, meningkatkan batas bawah), yang mana itu salah. Karena "asli pip-tools " tidak tunduk pada pip untuk menangani ini (karena tidak terkait dengan apa yang saat ini diinstal), ia menawarkan opsi untuk menentukan dependensi yang akan diperbarui di lockfile, dan cukup hapus pin untuk paket-paket ini (atau semua) dari daftar existing_pins, secara efektif kembali ke kueri PyPI. Saya tidak yakin bagaimana kita bisa mencocokkan gagasan "--upgrade-strategy" dengan ini.

@tokopedia
Jadi sementara saya mengatakan itu cukup mudah untuk hanya "menyelaraskan perilaku default", sekarang saya menyadari bahwa ini akan menyebabkan beberapa masalah besar dengan kemampuan untuk memperbarui paket (seperti dalam: cukup ambil versi terbaru yang sesuai dengan batasan saya saat ini) .

Jika ada sesuatu yang tidak jelas, tanyakan saja, banyak pengeditan terjadi saat menulis ini.

(Resolusi ketergantungan tidaklah mudah. ​​Resolusi ketergantungan yang baik dan praktis bahkan lebih buruk)

@vphilippon itulah yang saya maksud. Menjaga hal-hal yang diinstal pip selaras dengan hal-hal yang diselesaikan pip-tools bukanlah hal yang sepele kecuali Anda mendorong prosesnya mundur, menggunakan lockfile yang telah diselesaikan untuk melakukan penginstalan. Saya cukup yakin itulah mengapa hal-hal dirancang sebagaimana adanya.

B) Pipfile.lock harus mendapatkan versi terbaru yang menghormati batasan / dependensi lingkungan untuk mendapatkan keuntungan bebas dari rentang terbuka di dependensi Pipfile dan lib, yang memungkinkan untuk terus memperoleh versi baru yang kompatibel di lingkungan Anda. Anda kemudian dapat menjalankan pembaruan pipenv untuk memanfaatkan kunci baru.

Alur kerja ini mungkin dapat bekerja dengan konfigurasi saat ini. Anda dapat menggunakan pipenv lock untuk membuat file kunci, tetapi pipenv update akan menginstal ulang seluruh lingkungan. Saya cukup yakin kami dapat menggunakan salah satu dari berbagai format output kami untuk menyelesaikan grafik ketergantungan (kami sudah memiliki format json seperti yang Anda ketahui) dan hanya menginstal ulang hal-hal yang tidak selaras dengan lockfile. Ini mungkin lebih masuk akal, tetapi saya ingin tahu tentang masukan dari @nateprewitt atau @erinxocon sebelum membuat keputusan

@vphilippon Setuju pipenv lock mungkin menghasilkan file kunci yang tidak benar-benar cocok dengan lingkungan - Saya terutama mendengar ini bahwa yang satu perlu "menjalankan pipenv update untuk mendapatkan manfaat dari kunci baru "- seolah-olah gembok tersebut" di depan "dari lingkungan daripada mencocokkannya.

Terlepas dari apakah Anda berada dalam alur kerja A atau alur kerja B, beberapa hal tampak konstan bagi saya, dan saya pikir ini juga sesuai dengan apa yang dikatakan @techalchemy :

• Hasil dari pipenv lock harus selalu berupa file kunci yang cocok dengan lingkungan.
• Hasil dari pipenv install harus selalu berupa lingkungan yang cocok dengan file kunci.

Saya mengabaikan detail implementasi, tapi itu semacam perilaku dasar yang saya harapkan dari manajer paket dengan fitur lockfile.

Menjalankan pipenv update secara berkala memungkinkan Anda untuk tetap dalam mode B selama Anda ingin semuanya segar, dan memiliki kemampuan untuk pipenv install --upgrade requests akan memungkinkan pembaruan spesifik dari satu paket dan ketergantungannya, tanpa mempengaruhi paket yang tidak perlu ditingkatkan jika tidak perlu.

Apakah saya melewatkan kasus penggunaan apa pun? Saya dapat memikirkan pengoptimalan untuk B - misalnya sebuah flag atau env var yang memberitahukannya untuk selalu mengupdate dengan penuh semangat - tapi saya pikir itu mencakup dasar-dasarnya. Saya juga tahu saya vulkanisir tanah yang telah Anda tutupi; hanya membantu saya untuk memastikan bahwa saya memahami apa yang Anda bicarakan. :)

Beberapa frase Anda di sekitar B sedikit membingungkan saya, meskipun, sepertinya mengatakan bahwa kunci pipenv dapat menghasilkan file terkunci yang sebenarnya tidak sesuai dengan lingkungan

@brettdh ini benar - resolver pip-tools kita gunakan untuk menghasilkan Pipfile.lock tidak menanyakan virtualenv daftar paket yang telah diinstal. Sebaliknya, ia mengkompilasi daftar paket yang memenuhi kriteria yang ditentukan dalam daftar pin dari Pipfile . Karena resolver itu sendiri berjalan menggunakan sistem atau instalasi python / pipenv / pip-tools luar, kami melakukan beberapa kesalahan besar untuk meyakinkannya untuk menyelesaikan paket dengan versi python yang sama yang digunakan di virtualenv. Asumsinya adalah bahwa pip install akan menyelesaikan hal-hal dengan cara yang sama, tetapi itu tidak selalu terjadi, meskipun saya tidak 100% yakin tentang itu. Tapi ya, pipenv lock tidak dibuat berdasarkan virtualenv, ini dibuat berdasarkan Pipfile . Ini adalah lockfile resolusi ketergantungan, bukan pin status lingkungan.

Sebagai resolusi potensial untuk ini: sesuatu yang saat ini didukung oleh pip itu sendiri, tetapi pip-compile tidak, adalah gagasan dari file batasan.

File batasan berbeda dari file persyaratan, yang mengatakan " Jika komponen ini diinstal, maka harus memenuhi batasan versi ini". Namun, jika paket tertentu dalam file batasan tidak muncul di pohon ketergantungan di mana pun, itu tidak ditambahkan ke kumpulan paket yang akan diinstal.

Ini adalah fitur yang saat ini hilang dari pipenv , karena masukan yang diinginkan ke generasi Pipfile.lock adalah:

1. Konten Pipfile diperbarui sebagai file input persyaratan baru
2. Set lengkap dependensi yang ada dari Pipfile.lock sebagai file batasan, tidak termasuk paket yang secara khusus dinamai dalam perintah saat ini

Dukungan file batasan pada tingkat resolver pip-tools akan cukup untuk pipenv untuk mendukung mode di mana upaya peningkatan implisit dari dependensi akan gagal sebagai pelanggaran batasan, memungkinkan pengguna untuk memutuskan apakah mereka ingin menambahkan atau tidak paket itu ke set yang sedang diperbarui.

saat ini tidak didukung, terima kasih atas umpan baliknya

@tokopedia

Maksudmu:

1. Perilaku ini harus diubah, tetapi saat ini tidak menjadi prioritas,
2. Perilaku ini harus ditambahkan sebagai sesuatu yang opsional, tetapi saat ini tidak menjadi prioritas, atau
3. Perilaku ini tidak boleh ditambahkan?

Ini adalah ketidaknyamanan yang cukup mengingat ketidakkonsistenan dengan cara kerja manajer paket penguncian serupa lainnya sehingga akan lebih baik untuk tetap membuka ini sebagai ajakan untuk PR.

Jika sebaliknya (3), dan ini tidak akan ditambahkan, maka saya pikir beberapa dari kita tentang masalah ini perlu menyesuaikan rencana kita untuk pilihan alat manajemen paket Python kita.

Maksud saya ini saat ini tidak didukung, dan saya menghargai umpan baliknya.

Saya mengerti bahwa itu tidak didukung. Apakah Anda juga mengatakan bahwa Anda tidak akan menerima PR baik mengubah perilaku ini atau menambahkan ini sebagai opsi?

Saya tidak punya ide.

@ k4nar masih tertarik melakukan PR untuk ini? Secara khusus, sesuatu seperti pipenv install --only <dep-to-update yang mencegah departemen yang tidak terkait untuk diperbarui. Karena @kennethreitz tampaknya tidak tertarik untuk berdiskusi lebih lanjut, menurut saya itulah satu-satunya cara untuk mengetahui apakah penambahan / perubahan perilaku tersebut dapat diterima (dan, dengan ekstensi, apakah orang-orang seperti @taion dan saya dapat terus menggunakan pipenv).

Saya tertarik tapi saya tidak yakin bagaimana cara terbaik untuk menerapkan ini. Ada banyak komponen yang bekerja (pip, pip-tools, pipfile, pipenv…) dan mungkin banyak solusi yang mungkin.

Menurut https://github.com/kennethreitz/pipenv/issues/966#issuecomment -339707418, ini seharusnya relatif mudah. Logika resolusi dep sebagian besar hanya dari pip-tools. Saya berencana untuk mengirimkan PR, tetapi saya tidak dapat membenarkan pengeluaran pekerjaan jika kita tidak mau berbicara tentang bagaimana kita ingin tampilan API sebelum kita menghabiskan waktu menulis kode.

Saat ini saya sedang mengambil pendekatan alternatif - karena Pipfile adalah standar, interaksi dengannya tidak perlu melalui pipenv, dan saya ingin mengatasi beberapa semantik aneh lainnya di sini seperti menghapus virtualenv yang ada per https : //github.com/kennethreitz/pipenv/issues/997.

Maaf untuk mengomentari masalah tertutup, tetapi saya ingin menunjukkan bahwa, menurut pemahaman saya, menggunakan pipenv dalam proyek saya saat ini membutuhkan alur kerja seperti ini:

pipenv install foo
vim Pipfile.lock  # Manually remove all the unwanted updates
git add && git commit && git push

Saya merasa sangat menjengkelkan harus mengkomunikasikan ini kepada anggota tim saya. Alternatifnya adalah menyematkan semuanya ke versi yang tepat di Pipfile , tetapi itu mengalahkan sebagian besar tujuan penggunaan pipenv di tempat pertama.

IIUC, perilaku ini setara dengan apt melakukan implisit apt dist-upgrade setiap kali Anda menjalankan apt install foo .

Hal ini diperparah oleh fakta bahwa pipenv install memperbarui barang-barang di Pipfile.lock , tetapi tidak menginstal pembaruan ke virtualenv lokal. Jika pengembang tidak dengan hati-hati memeriksa perbedaan Pipfile.lock , mereka masih menggunakan versi yang lebih lama secara lokal, tetapi begitu mereka berbagi kode, semua lingkungan lain melihat pembaruan yang mengejutkan. Orang cenderung mengabaikan perbedaan Pipfile.lock karena dianggap sebagai file yang dibuat secara otomatis.

Saya sangat yakin bahwa "perbarui semuanya ke versi terbaru yang diizinkan oleh Pipfile " harus merupakan operasi yang diminta secara eksplisit dan terpisah dari "install foo".

harus diperbaiki di master

Perilakunya masih ada, saya mengujinya di pipenv 11.8.3 , @kennethreitz.

@ marius92mc Komentar "diperbaiki di master" mengacu pada opsi --selective-upgrade dan --keep-outdated ditambahkan dalam rilis terbaru: https://docs.pipenv.org/#cmdoption -pipenv-install-keep -kedaluwarsa

Itu memungkinkan orang-orang yang membutuhkan atau menginginkan lebih banyak kendali atas tepat ketika pemutakhiran terjadi untuk memilih perilaku itu, sementara perilaku bawaan terus menghormati OWASP A9 dan mendorong pemutakhiran yang bersemangat di setiap kesempatan.

@ncoghlan Saya pikir satu hal yang diperlukan (mudah untuk meminta, tidak semudah melakukannya) adalah FAQ tentang _how_ opsi-opsi tersebut berperilaku (setidaknya masih membingungkan bagi saya).

Sebagai contoh: Menggunakan --selective-upgrade dan --keep-outdated akan tetap menyebabkan perpustakaan usang di Pipfile.lock diperbarui, jika mereka tidak terkait langsung dengan paket "yang dipilih" untuk diperbarui .

Sepertinya ada bug implementasi.

Mereka dimaksudkan untuk membiarkan pipfile.lock apa adanya, kecuali untuk perubahan baru.

Beri tahu saya jika memberikan pengujian Pipfile + .lock.

Saya rasa Anda telah memberikan informasi yang cukup untuk kami selidiki. Saya akan mencoba melakukannya sekarang.

Sebenarnya, pipfile / kunci Anda akan bagus, jika berisi hasil yang sudah ketinggalan zaman.

@ncoghlan , terima kasih telah memberikan detailnya.
Saya mencoba lagi dengan opsi yang Anda sebutkan dan hasilnya tampaknya sama, masih memperbarui paket lain juga, mengubahnya dalam file Pipfile.lock .

@kennethreitz https://github.com/simonpercivall/pipenv-selective-upgrade-test

Ada pembaruan tentang masalah ini, @kennethreitz?

Maaf atas jawaban lambat ini. Kami belum menemukan akar penyebab kemunduran di sini (saya tahu saya pribadi telah menangani migrasi pusat data akhir pekan ini jadi saya agak lambat) tetapi kami akan menyelesaikannya dalam beberapa hari ke depan.

Kontribusi diterima seperti biasa!

Saya rasa ada kasus penggunaan yang hilang yang dapat menggunakan perubahan yang sama ini: ketika saya mengembangkan aplikasi, saya sering kali perlu memutakhirkan versi ketergantungan tunggal. Langkah-langkah yang ingin saya ikuti adalah:

1. Perbarui batasan versi untuk ketergantungan di setup.py
2. Jalankan pipenv lock --selective-upgrade ; pipenv sync atau pipenv install --selective-upgrade "-e ."

@wichert Jika Pipfile telah diedit dengan cara yang meningkatkan versi minimum yang dibutuhkan melebihi apa yang ada di file kunci saat ini, maka --keep-outdated seharusnya sudah mencakup apa yang Anda butuhkan. --selective-upgrade adalah untuk kasus di mana Pipfile belum berubah, tetapi Anda tetap ingin memperbarui ke versi baru yang disematkan.

@ncoghlan Pipfile tidak berubah dalam skenario ini, hanya setup.py dengan mengubah persyaratan versi minimum untuk ketergantungan, biasanya ke sesuatu yang lebih baru dan saat ini dalam Pipfile.lock .

@wichert pipenv tidak menangkap perubahan pada setup.py secara otomatis karena ini bukan alat penyiapan. Anda harus menjalankan pipenv lock jika Anda ingin hal itu terjadi.

Apa status saat ini? Pada tanggal 25 Maret seseorang mengatakan mereka mengira masalah implementasi akan diselesaikan "dalam beberapa hari mendatang", dan laporan bug lainnya telah ditutup karena sedang dilacak di sini; tetapi pada 2018.7.1 Saya masih melihat bug yang dilaporkan oleh Simon Percivall (dependensi tidak langsung selalu diperbarui) dan bug itu belum dibahas sejak laporan asli. Apakah masalahnya masih dilacak?

(Saat ini saya tinggal di kota lapis kedua di Senegal sehingga Internet saya buruk dan akan menjadi perubahan besar untuk tidak meledakkan batasan data saya untuk memperbarui dependensi tidak langsung jika memungkinkan: P)

PS: Terima kasih sudah membuat Pipenv, luar biasa <3

Ya tentu saja. Kami sedang menulis ulang resolver untuk mendukung ini sekarang. Apakah itu mendarat di rilis ini atau rilis berikutnya masih harus dilihat

Saya tidak begitu yakin dengan keterampilan pengkodean saya untuk memperkirakan kapan resolver akan mendarat: p Serius, ini adalah proyek yang sepenuhnya sukarela, dan kami tidak memiliki mekanisme tenggat waktu seperti yang Anda lakukan dalam pengaturan komersial (kami bahkan tidak memiliki bos atau manajer proyek atau apa pun yang Anda miliki di perusahaan Anda yang memutuskan kapan sesuatu perlu dilakukan). Jika Anda ingin sesuatu diselesaikan dalam jangka waktu yang Anda inginkan, Anda perlu melakukannya sendiri, atau setidaknya memberikan motivasi nyata bagi orang lain untuk melakukannya.

@uranusjr FWIW, saya tidak melihat adanya permintaan untuk kemanfaatan dalam komentar @benkuhn di atas - hanya pertanyaan tentang di mana keadaan; yaitu pekerjaan apa yang telah dilakukan, sehingga pengamat luar dapat membuat perkiraan / keputusan mereka sendiri.

Saya memahami bahwa pipenv adalah proyek sukarela dan non-kontributor tidak dapat meminta sesuatu untuk diselesaikan sebelum tanggal tanpa mendaftar untuk mewujudkannya. Saya bertanya-tanya, apakah masih ada ruang untuk transparansi yang lebih besar dalam proses pengembangan proyek, atau apakah saya tidak mencari di tempat yang tepat. Biasanya jawabannya adalah "jika masalah belum diperbarui, tidak ada pergerakan" atau "lihat permintaan penarikan WIP ini", tetapi masalah ini secara khusus tampaknya telah memicu upaya yang jauh lebih besar, sehingga titik-titiknya bisa menjadi sulit untuk menghubungkan mereka yang tidak terlibat langsung.

Seperti biasa, terima kasih banyak kepada Anda dan semua orang yang telah memberikan waktu berharga mereka untuk peningkatan pipenv. 👏

Yang pasti, yang satu ini tidak ada aktivitas atau pekerjaan yang sedang dikerjakan PR karena jauh lebih rumit dari itu. Kami berbicara secara internal kebanyakan tentang bagaimana kami bahkan ingin menyusun ini sehubungan dengan proyek yang lebih besar, dan bekerja secara berulang untuk menetapkan pendekatan yang bahkan mungkin mulai bekerja dengan baik. Setelah kita bisa menyelesaikannya, kita bisa membangun logika resolusi.

Sementara itu, tumpukan resolver di pipenv sangat berbelit-belit dan saya tidak akan nyaman meminta orang untuk menginvestasikan terlalu banyak upaya untuk mencoba melepaskannya untuk tujuan ini. Bahkan kasus penggunaan yang paling sederhana di sini akan membutuhkan refaktor yang signifikan. Kami akan dengan senang hati meninjau / mendiskusikan refactor yang diusulkan jika seseorang tertarik untuk membantu mengatasi hal ini, tetapi kedua hal tersebut terkait erat.

Jika seseorang memiliki keahlian dalam resolusi ketergantungan dan penyelesaian duduk, kami pasti akan tertarik pada masukan tetapi belum ada satu pun ide konkret. Kami telah melalui beberapa iterasi yang tidak pernah kami rencanakan untuk dilanjutkan sebagai lebih dari sekadar bukti konsep. Tidak semua kode menjadi PR, dan tidak semua keputusan organisasi kode terjadi di pelacak masalah. Terkadang kami mengobrol secara serempak dan mengusulkan serta membuang ide dalam waktu nyata.

Sesuatu yang saya _going_ sarankan sebagai alur kerja alternatif yang mungkin mengatasi hal ini adalah mempermudah penyematan ke versi tertentu di _Pipfile_ saat menginstal.

Saya pikir itu sedikit mengejutkan tetapi tidak sepenuhnya tidak masuk akal bahwa pipenv mengartikan foo = "*" berarti "Saya hanya perlu memastikan versi _some_ dari foo diinstal, pengguna tidak peduli yang mana". Untuk itu, memiliki sesuatu seperti pipenv install --pin foo yang menghasilkan foo = "==1.2.3" alih-alih foo = "*" di Pipfile (di mana 1.2.3 adalah versi terbaru dari foo) sepertinya mungkin Tolong.

Masalah dengan ini adalah bahwa perilaku banyak paket dapat banyak berubah berdasarkan ketergantungannya (misalnya, versi pylint yang sama dapat melakukan hal yang sangat berbeda tergantung pada versi astroid apa yang digunakannya), dan paket tidak pin deps mereka sendiri persis. Jadi saya tidak berpikir ini benar-benar membawa siapa pun jauh. : /

(Baru sadar saya telah mengomentari masalah yang salah. Maaf atas kekacauannya, tolong abaikan saya) 😞

Kasus penggunaan aktual yang saya perjuangkan selama beberapa jam sekarang: Saya ingin mengukur cakupan pengujian dalam proyek Django 2.0. Bahkan pipenv install --keep-outdated --selective-upgrade --dev coverage bersikeras memperbarui paket Django non-dev ke versi 2.1, yang karena kerusakan di tempat lain saya sama sekali tidak dapat menggunakan. Pasti ada cara untuk mengubah set paket yang diinstal tanpa memutakhirkan paket yang sama sekali tidak terkait ke versi yang mungkin melanggar. Kemungkinan kerusakan pada versi terbaru akan selalu ada.

Saya akan mencoba solusi @rfleschenberg , tetapi saya tidak tahu apakah memiliki properti _meta hash dianggap salah akan merusak apa pun.

@ l0b0 Jika aplikasi Anda benar-benar tidak dapat menangani versi tertentu dari Django, saya pikir masuk akal untuk menyatakan pembatasan itu dalam Pipfile Anda?

@AlecBenzer Kedengarannya seperti sesuatu untuk setup.py bagi saya.

@wichert Itu mungkin masuk akal juga (saya sebenarnya tidak sepenuhnya jelas dalam situasi apa Anda ingin memiliki setup.py dan Pipfile), tetapi jika Anda memiliki baris di Pipfile Anda yang mengatakan:

Django = "*"

Anda memberi tahu pipenv bahwa Anda ingin memasang versi _any_ dari Django. Jika yang Anda benar-benar ingin lakukan adalah menginstal 2.0 atau lebih rendah, katakan itu sebagai gantinya:

Django = "<=2.0.0"

Sementara dalam kasus khusus ini pipenv sedang memutakhirkan Django tanpa alasan yang sebenarnya, bisa jadi di suatu tempat Anda mencoba memasang paket yang membutuhkan Django> 2.0.0, di mana pipenv akan dengan senang hati menginstalnya jika Anda belum memberi tahu itu yang Anda butuhkan <= 2.0.0.

Jika yang Anda benar-benar ingin lakukan adalah menginstal 2.0 atau lebih rendah, katakan saja

@AlecBenzer pada refleksi, sekarang terpikir oleh saya bahwa inilah yang npm / yarn lakukan secara default ketika Anda menginstal sebuah paket; mereka menemukan versi mayor.minor terbaru dan menentukan ^major.minor.0 dalam package.json, yang mencegah pemutakhiran versi mayor yang tidak terduga, bahkan ketika pemutakhiran-ke-terbaru secara eksplisit diminta. Saya ingin tahu apakah Pipenv harus melakukan hal yang sama - tetapi itu akan menjadi masalah terpisah.

Tentu saja, file kunci mereka juga mencegah peningkatan yang tidak disengaja dari versi minor dan patch, yang diminta di sini.

Saya pikir ini telah dibahas di atas dan di tempat lain, tetapi ada ketegangan / pertukaran dalam ruang desain antara npm / benang dan pipenv. Setiap pengelola paket berpura-pura memiliki tujuan ini, dengan beberapa prioritas relatif:

• Permudah penginstalan dan peningkatan paket
• Persulit kerusakan aplikasi Anda secara tidak sengaja dengan peningkatan versi dependensi yang salah

Masalah dengan menyematkan versi yang tepat di Pipfile adalah lebih sulit untuk memutakhirkan paket; inilah mengapa pip-tools ada (meskipun itu untuk Requirement.txt).

Bendera --keep-outdated tampaknya tidak berfungsi sebagaimana mestinya, seperti yang dinyatakan saat masalah dibuka kembali. Apakah perilaku itu harus atau tidak harus menjadi default dan bagaimana itu selaras dengan manajer paket lain sebenarnya bukan masalah utama di sini. Mari kita perbaiki dulu.

@tokopedia

pada refleksi, sekarang terpikir oleh saya bahwa inilah yang npm / yarn lakukan secara default ketika Anda menginstal sebuah paket; mereka menemukan versi major.minor terbaru dan menentukan ^ major.minor.0 di package.json, yang mencegah peningkatan versi mayor yang tidak terduga, bahkan ketika peningkatan-ke-terbaru secara eksplisit diminta. Saya ingin tahu apakah Pipenv harus melakukan hal yang sama - tetapi itu akan menjadi masalah terpisah.

Ya, itu sejalan dengan apa yang saya coba sarankan di https://github.com/pypa/pipenv/issues/966#issuecomment -408420493

Sangat senang mendengar ini sedang dikerjakan!

Sementara itu, apakah ada yang memiliki solusi yang disarankan yang kurang melelahkan dan rawan kesalahan daripada menjalankan pipenv lock dan mengembalikan secara manual perubahan lockfile yang dihasilkan yang tidak ingin saya terapkan?

@benkuhn Bukan berarti saya tahu - Saya melakukan kunci yang sama & mengembalikan tarian sepanjang waktu.

Ah ok, Anda setidaknya kadang-kadang bisa menghindari hand-reverting:

1. pipenv lock
2. git commit -m "FIXME: revert"
3. pipenv install packagename
4. git commit -m 'Add dependency on packagename'
5. git rebase -i
6. Jatuhkan komitmen FIXME: revert

Sayangnya, masih mungkin untuk membuat Pipfile.lock tidak konsisten jika Pipfile.lock mulai berisi versi paket yang terlalu tua untuk memenuhi persyaratan packagename , tetapi mungkin pipenv akan mengeluh tentang ini jika itu terjadi?

--keep-outdated tampaknya secara sistematis membuat hanya dependensi eksplisit yang dispesifikasikan (tidak disematkan) di Pipfile, sementara semua dependensi implisit diperbarui.

Apakah saya benar bahwa tidak mungkin memperbarui / menginstal ketergantungan tunggal menggunakan pipenv==2018.7.1 tanpa memperbarui ketergantungan lainnya? Saya mencoba kombinasi yang berbeda dari --selective-upgrade dan --keep-outdated tidak berhasil.

Mengedit Pipfile.lock secara manual tidaklah menyenangkan ...

Sama dengan @ max-arnold, ini hari pertama saya menggunakan alat ini dalam proyek yang sudah ada, dan saya harus mengatakan saya sangat kecewa , sebelum saya mulai menggunakannya, saya memeriksa situs dokumen dan demo videonya, itu tampak mengesankan bagi saya, dan sekarang ini: dalam proyek nyata, bekerja dengan pip atau pipenv hampir sama, saya tidak mengerti maksudnya, seperti yang dikatakan banyak orang lain di utas, jika saya punya file kunci, mengapa Anda memperbarui dependensi saya yang lain jika tidak perlu memperbaruinya.

Tentu saja, ### jika pembaruan itu wajib, tidak masalah untuk memperbarui semua dependensi yang diperlukan, tetapi hanya itu, tidak semua yang sudah ketinggalan zaman.

Juga opsi --selective-upgrade dan --keep-outdated tidak jelas untuk apa yang berguna, ada masalah lain yang menyoroti ini di sini # 1554, dan tidak ada yang dapat menanggapi apa yang dilakukan opsi ini, luar biasa.

Tetapi kekecewaan utama saya adalah mengapa paket ini direkomendasikan oleh dokumentasi resmi Python itu sendiri, rekomendasi ini harus dilakukan lebih hati-hati, saya tahu ini bisa menjadi proyek yang hebat dalam fiturnya, memiliki banyak potensi, tetapi hal-hal sederhana seperti ini (kami tidak berbicara tentang bug atau fitur kecil), membuat proyek ini tidak memenuhi syarat untuk lingkungan produksi, tetapi tiba-tiba karena direkomendasikan oleh dokumen Python, semua orang mencoba menggunakannya, daripada mencari alat lain yang mungkin bekerja lebih baik, atau tetap dengan pip , itu juga tidak menyelesaikan masalah ini, tapi setidaknya sangat minimalis dan sebagian besar disertakan dalam lingkungan apa pun (tidak menambahkan ketergantungan tambahan).

@mrsarm Terima kasih atas pendapat Anda. Maaf, hal-hal tidak berhasil untuk Anda. Saya tidak mengerti dari mana datangnya kekecewaan itu. Tidak ada yang memaksa Pipenv pada siapa pun; jika tidak berhasil untuk Anda, jangan gunakan. Begitulah cara kerja rekomendasi.

Kata-kata kasar Anda juga tidak ada hubungannya dengan masalah ini. Saya mengerti bahwa membutuhkan sedikit pengendalian diri untuk tidak membuang sampah pada orang-orang ketika segala sesuatunya tidak berjalan sesuai keinginan Anda, tetapi tolong tunjukkan rasa hormat, dan jangan melakukannya.

@uranusjr itu bukan sampah, itu pendapat, dan kadang itu bukan pilihan, seperti kasus saya, di mana seseorang memilih pipenv untuk membuat proyek di mana saya mulai bekerja sekarang, dan saya harus berurusan dengan ini.

Tapi keadaan menjadi lebih buruk sekarang, dan yang akan saya katakan itu bukanlah opini, itu fakta.

Setelah mencoba menambahkan satu ketergantungan yang baru saja saya abaikan untuk menghindari masalah ini (karena ini adalah ketergantungan dev, jadi saya membuat lingkungan kedua dengan pip dan pendekatan requirements-dev.txt , hanya dengan alat itu), saya perlu menambahkan ketergantungan lain.

Dependensi baru adalah PyYAML, katakanlah versi terbaru. Jika Anda menginstalnya di lingkungan baru dengan pip , Anda akan melihat bahwa library tidak menambahkan dependensi apa pun, jadi hanya PyYAML yang diinstal, sesederhana itu dalam kasus ini dengan Pip. Tetapi menambahkan ketergantungan dengan Pipenv (karena proyek yang tidak saya buat dikelola dengan Pipenv) masalah yang sama terjadi, meskipun PyYAML tidak memiliki ketergantungan apa pun, dan tidak diinstal sebelumnya dalam proyek (versi yang lebih lama), pipenv memperbarui semua dependensi saya di file kunci dan lingkungan virtual, tetapi saya tidak ingin memperbarui dependensi lain, saya hanya menambahkan satu modul baru tanpa ketergantungan apa pun.

Jadi kesimpulannya (dan sekali lagi pendapat, bukan fakta seperti pipenv merusak semua dependensi saya) adalah bahwa Pipenv alih-alih membantu saya menangani manajemen dependensi, malah mengubahnya menjadi neraka.

Saya telah mengikuti utas ini selama berbulan-bulan, dan saya pikir setiap proyek nyata pada akhirnya akan tersandung pada masalah ini, karena perilakunya tidak terduga, kontra-intuitif, dan ya: berbahaya.

Sekitar sebulan yang lalu saya mencoba alternatif yang lebih komprehensif untuk pipenv , poetry ; itu memecahkan masalah _I_ yang diperlukan untuk menyelesaikan:
1) mengelola satu set dependensi (setup.py, setup.cfg, pip, dan pipfile -> pyproject.toml)
2) berorientasi masa depan, kompatibel dengan mundur (lagi-lagi pyproject.toml )
3) cukup tidak beropini ( tidak, saya benar-benar tidak meminta untuk menginstal redis )
4) dan solusi untuk masalah Pipenv klasik: "Selain itu, Anda harus secara eksplisit memberitahukannya [pipenv] untuk tidak memperbarui paket yang terkunci saat Anda menginstal yang baru. Ini harus menjadi default." [[1] (https://github.com/sdispater/poetry#what-about-pipenv)] [[2] (https://github.com/pypa/pipenv/issues/966#issuecomment-339117289)]

Saya mempertimbangkan untuk berbagi pemikiran ini tentang masalah pipenv , tetapi seperti yang dikatakan @uranusjr , "tidak ada yang memaksa Pipenv pada siapa pun", dan saya tidak memaksakan Puisi. Saya suka, ini berfungsi dengan baik, dan menyelesaikan masalah saya, tetapi saya hanya membagikan solusi alternatif yang lebih komprehensif untuk masalah yang saya alami. Ambil saja semua itu sebagai 2 ¢ saya.

• sebagai penafian, saya bukan anggota tim Puisi atau berafiliasi dengan mereka.

ps Saya rasa kekhawatiran tentang Pipenv sebagai solusi "resmi" adalah karena integrasi kelas satu - sesuatu yang Anda, @uranusjr , mungkin melihatnya sebagai rekomendasi sederhana - industri pada umumnya menganggapnya sebagai "pendekatan yang diberkati meneruskan". Sejujurnya, rekomendasi itu lebih berwibawa di masyarakat daripada PEP tertentu yang sudah ada lebih dari setahun.

Tidak ada yang memaksa Anda untuk berpartisipasi dalam pelacak masalah kami; jika Anda tidak memiliki komentar yang produktif, silakan temukan forum yang bukan untuk memrioritaskan masalah.

Untuk pengguna yang tertarik untuk mencoba resolver alternatif @uranusjr dan saya sendiri telah mengimplementasikan selama beberapa minggu sekarang, silakan coba https://github.com/sarugaku/passa yang akan menghasilkan file kunci yang kompatibel. Puisi melakukan banyak hal yang berbeda, tetapi puisi juga memiliki keterbatasan dan masalah itu sendiri, dan kami memiliki perselisihan filosofi desain tentang ruang lingkup.

Ini adalah proyek yang kami kelola di waktu luang kami; jika Anda ingin melihat sesuatu diperbaiki atau Anda memiliki pendekatan yang lebih baik, kami dengan senang hati menerima kontribusi. Jika Anda di sini hanya untuk memberi tahu kami bahwa kami telah merusak hari dan proyek Anda, saya akan meminta Anda hanya sekali untuk melihat diri Anda sendiri.

Kami tidak melupakan atau mengabaikan masalah ini, kami memiliki implementasi penuh untuk perbaikan di resolver yang ditautkan di atas. Bersabarlah, bersikap sopan, atau cari tempat lain untuk berbicara. Kepada mereka yang telah menunggu dengan sabar untuk perbaikan, silakan coba resolver yang disebutkan di atas — kami sangat ingin melihat apakah itu memenuhi kebutuhan Anda. Ini mengimplementasikan backtracking dan resolusi yang tepat dan seharusnya tidak menangani strategi peningkatan ini

Dalam jangka pendek saya pikir kita bisa mendapatkan bantuan pita untuk ini menjadi pipenv jika kita tidak memotongnya terlebih dahulu.

@ pdfee Saya tidak begitu yakin bahwa garis kabur antara aplikasi dan perpustakaan adalah jawaban yang benar untuk manajemen ketergantungan, jadi saya tidak melihat pendekatan puisi sebagai keuntungan. Saya tidak terlibat dalam masalah apa pun yang Anda hadapi dengan mesin rekomendasi, tetapi kami telah mengatasinya beberapa waktu lalu ...

@tokopedia

Saya tidak begitu yakin bahwa garis kabur antara aplikasi dan perpustakaan adalah jawaban yang benar untuk manajemen ketergantungan, jadi saya tidak melihat pendekatan puisi sebagai keuntungan.

Kenapa sih? Saya tidak pernah mengerti gagasan ini bahwa Anda harus mengelola dependensi perpustakaan dan aplikasi secara berbeda. Satu-satunya perbedaan antara keduanya adalah file kunci yang diperlukan aplikasi untuk memastikan lingkungan yang dapat direproduksi. Selain itu, itu sama saja. Ini adalah standar di sebagian besar bahasa lain dan Python tampaknya pengecualian di sini untuk beberapa alasan dan ini buruk dari sudut pandang pengalaman pengguna karena ini membuat segalanya lebih kompleks dari yang seharusnya.

itu juga memiliki keterbatasan dan masalah itu sendiri

Yang mana Saya sangat ingin tahu tentang masalah atau batasan yang Anda temui saat menggunakan Puisi.

Maafkan saya untuk bersikap kasar. Sekarang membaca komentar saya, saya menyadari bahwa meskipun info yang saya berikan dan beberapa opsi saya masih valid (IMHO), itu tidak sesuai dengan cara saya menulis apa yang ingin saya katakan.

Saya memahami bahwa pelacak masalah sebagian besar merupakan tempat untuk membahas bug dan perbaikan, dan mendiskusikan apakah ini bug atau kesalahan menurut desain tidak jelas di utas, tetapi sekali lagi saya minta maaf.

Saya pikir ada dua topik kuat di sini:

• Haruskah pipenv memperbarui semua dependensi lama Anda di mana Anda mencoba hanya untuk menginstal dependensi baru: yang tidak perlu diperbarui karena paket / versi baru yang kami coba instal dapat bekerja dengan dependensi yang ada, dan bahkan yang tidak dependensi dari paket baru yang kami coba instal? Mungkin ini di luar cakupan tiket ini, tetapi ini adalah topik yang sangat penting untuk didiskusikan.
• Apakah salah satu dari parameter --keep-outdated --selective-upgrade memungkinkan kita menghindari perilaku ini? Tidak jelas apa yang dilakukan opsi-opsi ini, ada kekurangan dokumentasi tentang mereka, dan bahkan dalam masalah terkait (# 1554) tidak ada yang menjawabnya.

Jika itu adalah bug di salah satu parameter ini --keep-outdated --selective-upgrade , saya masih berpikir bahwa tidak mengatur parameter apa pun yang memecahkan pembaruan dependensi yang tidak perlu sebagai default itu ide yang sangat buruk.

Untuk membandingkan dengan skenario serupa, bayangkan Anda mengeksekusi apt-get install vim untuk hanya menginstal alat vim di sistem Anda (dan dependensi atau pembaruan vim yang diperlukan jika berlaku), tetapi bayangkan juga dalam situasi ini apt memperbarui semua dependensi lain dari sistem Anda: python, sistem QT, kernel Linux ... dan seterusnya. Bukannya apt seharusnya tidak mengizinkan kita untuk memperbarui dependensi lain, tetapi ada perintah yang jelas untuk melakukannya: apt-get upgrade , sementara apt-get install PACKAGE cukup instal / perbarui PAKET dan dependensinya.

@sdispater perbedaannya adalah inti dari setiap perselisihan yang pernah kami alami dan itu sangat halus, tetapi saya akan mengarahkan Anda ke https://caremad.io/posts/2013/07/setup-vs-requirement/ atau yang baik artikel untuk kasus penggunaan elixir: http://blog.plataformatec.com.br/2016/07/understanding-deps-and-applications-in-your-mixfile/

pyproject.toml tidak benar-benar didukung untuk metadata definisi perpustakaan - dan sama sekali tidak oleh versi pip apa pun yang tidak mengimplementasikan peps 517 dan 518 (keduanya masih memiliki detail implementasi yang berhasil) sebagai otoritatif file deklarasi perpustakaan. setup.cfg ada untuk tujuan itu (penerus sebenarnya dari setup.py ) dan IMHO keduanya harus benar-benar didukung. Sebuah perpustakaan diterbitkan dan dimaksudkan untuk konsumsi dengan dependensi abstrak sehingga mereka bisa bermain bagus di sandbox dengan yang lain; aplikasi biasanya berukuran besar, binatang yang kompleks dengan terkadang ratusan ketergantungan langsung. Jadi salah satu perbedaan utama kami adalah ketika kami merancang dan membangun perkakas kami, kami juga memperhitungkannya

@mrsarm Untuk pertanyaan pertama Anda, perilaku pembaruan disengaja (dan dibahas secara ekstensif pada saat itu, / cc @ncoghlan dan terkait dengan masalah keamanan OWASP). Pada poin kedua, perilaku saat ini tidak diterapkan dengan benar, itulah sebabnya masalah masih terbuka, yang membuat kami menulis ulang resolver dukungan di belakang pipenv, yang saya sebutkan di atas. Itu sama sekali tidak mendukung perilaku ini. --selective-upgrade seharusnya mengupgrade secara selektif hanya hal-hal yang merupakan dependensi dari paket baru, sedangkan --keep-outdated akan menahan apapun yang memenuhi dependensi yang dibutuhkan oleh paket baru. Sedikit berbeda, tetapi saya cukup yakin tidak ada yang berfungsi dengan benar saat ini.

pyproject.toml tidak benar-benar didukung untuk metadata definisi perpustakaan - dan sama sekali tidak oleh versi pip apa pun yang tidak mengimplementasikan peps 517 dan 518 (keduanya masih memiliki detail implementasi yang berhasil) sebagai file deklarasi perpustakaan resmi . setup.cfg ada untuk tujuan itu (penerus sebenarnya dari setup.py) dan IMHO keduanya harus benar-benar didukung.

Ini jelas di luar topik tetapi ini adalah diskusi penting jadi saya tidak bisa menahan diri.

Sebenarnya tidak ada standar sekitar setup.cfg saat ini selain konvensi yang dibuat oleh distutils dan setuptools. pyproject.toml mutlak untuk metadata perpustakaan sebagai penerus setup.py atau komunitas akan menempatkan persyaratan pembangunan di setup.cfg sebagai gantinya.

pyproject.toml menjelaskan bagaimana membangun sebuah proyek (PEP 518), dan bagian dari bangunan menjelaskan metadata. Saya TIDAK mengatakan bahwa pyproject.toml membutuhkan lokasi standar untuk metadata ini, tetapi PEP 518 menggunakan file ini untuk menginstal alat pembangunan dan dari sana sangat masuk akal untuk mengharapkan bahwa alat pembangunan akan menggunakan konfigurasi deklaratif dari tempat lain di file untuk menentukan cara membangun proyek.

Bagaimanapun, kembali ke pipenv vs puisi - tampaknya ada beberapa gagasan yang beredar bahwa aplikasi tidak memerlukan fitur tertentu yang didapat perpustakaan, seperti titik masuk, dan ini tidak benar. Harus mudah bagi aplikasi untuk menjadi paket python.

Satu-satunya perbedaan nyata antara aplikasi dan perpustakaan menurut pengalaman saya dengan python dan ekosistem lain adalah apakah Anda menggunakan lockfile atau tidak. Tentu saja ada kasus ketiga di mana Anda benar-benar hanya menginginkan requirements.txt atau Pipfile dan tidak ada kode sebenarnya dan tampaknya itulah yang menjadi fokus pipenv sejauh ini ( pipenv install -e . jatuh ke dalam kategori ini karena pipenv masih takut untuk mencoba dan mendukung metadata paket). Sayangnya, meskipun desain pipenv lebih bersih dengan pendekatan ini, ini juga kurang berguna untuk sebagian besar aplikasi karena PEP 518 memutuskan untuk membahas cara menginstal proyek ke mode yang dapat diedit sehingga untuk terus menggunakan pipenv kita akan terjebak pada alat-alat setup. sementara Anda tidak dapat menggunakan pyproject.toml untuk beralih dari setuptools dan masih menggunakan pipenv install -e . .

Sebenarnya tidak ada standar seputar setup.cfg saat ini selain konvensi yang dibuat oleh distutils dan setuptools. pyproject.toml mutlak untuk metadata perpustakaan sebagai penerus setup.py atau komunitas akan menempatkan persyaratan membangun di setup.cfg sebagai gantinya.

Distutils adalah bagian dari pustaka standar dan setuptools diinstal dengan pip sekarang, jadi mengatakan bahwa tidak ada standar agak konyol. Belum lagi menggunakan standar yang diuraikan di pep 345 untuk metadata, antara lain, dan juga bisa digunakan untuk menentukan persyaratan build.

komunitas akan menempatkan persyaratan build di setup.cfg sebagai gantinya.

Apakah yang Anda maksud penulis pep? Anda dapat bertanya mengapa mereka membuat keputusan, mereka menguraikan semuanya dengan semangat.

pyproject.toml menjelaskan bagaimana membangun sebuah proyek (PEP 518), dan bagian dari bangunan menggambarkan metadata. Saya TIDAK mengatakan bahwa pyproject.toml memerlukan lokasi standar untuk metadata ini, tetapi PEP 518 menggunakan file ini untuk menginstal alat pembangunan dan dari sana sangat masuk akal untuk mengharapkan bahwa alat pembangunan akan menggunakan konfigurasi deklaratif dari tempat lain dalam file. untuk menentukan bagaimana membangun proyek.

Ini muncul di milis baru-baru ini - tidak ada yang menyatakan standar sekitar pyproject.toml selain itu akan digunakan untuk menyatakan persyaratan sistem build. Yang lainnya adalah asumsi; Anda bisa menyebutnya "metadata definisi perpustakaan", tetapi sebenarnya tidak. Cobalah hanya mendefinisikan sistem build tanpa informasi tambahan tentang proyek Anda (yaitu, tanpa metadata yang sesuai dengan pep-345) dan unggah ke pypi dan beri tahu saya bagaimana kelanjutannya.

Bagaimanapun, kembali ke pipenv vs puisi - tampaknya ada beberapa gagasan yang beredar bahwa aplikasi tidak memerlukan fitur tertentu yang didapat perpustakaan, seperti titik masuk, dan ini tidak benar. Harus mudah bagi aplikasi untuk menjadi paket python.

Siapa bilang aplikasi tidak memerlukan titik masuk? Pipenv memiliki keseluruhan konstruksi untuk menangani ini.

jadi untuk terus menggunakan pipenv kita akan terhenti di setuptools cukup lama karena Anda tidak dapat menggunakan pyproject.toml untuk beralih dari setuptools dan masih menggunakan pipenv install -e.

Tidak mengikuti di sini ... kami tidak akan meninggalkan pip berjualan di versi 10 selamanya, saya benar-benar telah mendeskripsikan resolver baru kami, dan penginstal yang sebenarnya hanya kembali ke pip secara langsung ... bagaimana ini mencegah orang menggunakan editable menginstal?

Ini muncul di milis baru-baru ini - tidak ada yang menyatakan standar sekitar pyproject.toml

Benar, ini bukan "standar", namun di utas yang sama kenali bahwa dengan menyebutnya pyproject.toml mereka kemungkinan besar meminta orang untuk menggunakan file ini untuk pengaturan / konfigurasi terkait proyek lainnya.

Jadi dengan logika yang sama yang Anda gunakan di sini:

Distutils adalah bagian dari pustaka standar dan setuptools diinstal dengan pip sekarang, jadi mengatakan bahwa tidak ada standar agak konyol.

pyproject.toml adalah standar, dan komunitas telah mengadopsinya sebagai lokasi standar untuk menempatkan informasi yang terkait dengan sistem pembangunan, dan bagian lain dari proyek Python.

Tidak mengikuti di sini ... kami tidak akan meninggalkan pip berjualan di versi 10 selamanya, saya benar-benar telah mendeskripsikan resolver baru kami, dan penginstal yang sebenarnya hanya kembali ke pip secara langsung ... bagaimana ini mencegah orang menggunakan editable menginstal?

PEP 517 memanfaatkan penginstalan yang dapat diedit ... yang berarti tidak ada cara standar untuk menginstal proyek dalam mode yang dapat diedit jika Anda tidak menggunakan alat penyiapan (yang memiliki konsep yang dikenal sebagai mode pengembangan yang menginstal proyek dalam mode yang dapat diedit).

Distutils adalah bagian dari pustaka standar dan setuptools diinstal dengan pip sekarang, jadi mengatakan bahwa tidak ada standar agak konyol. Belum lagi menggunakan standar yang diuraikan di pep 345 untuk metadata, antara lain, dan juga bisa digunakan untuk menentukan persyaratan build.

Ya, sistem build diharapkan mengeluarkan file PKG-INFO yang dijelaskan dalam PEP 345. Ini adalah format transfer yang menggunakan sdist atau roda dan dihasilkan dari setup.py/setup.cfg, ini bukan pengganti seperti seperti untuk metadata yang dapat dilihat pengguna. Penggunaan PEP 518 pyproject.toml adalah tentang mendukung alternatif untuk distutils / setuptools sebagai sistem build, tidak ada yang mencoba mengganti format sdist / wheel sekarang. Sistem build pengganti tersebut membutuhkan tempat untuk meletakkan metadatanya dan untungnya PEP 517 menyediakan namespace tool. untuk sistem ini. Ini bukan asumsi - flit dan puisi telah mengadopsi namespace ini untuk "metadata definisi pustaka".

Cobalah hanya mendefinisikan sistem build tanpa informasi tambahan tentang proyek Anda (yaitu, tanpa metadata yang sesuai dengan pep-345) dan unggah ke pypi dan beri tahu saya bagaimana kelanjutannya.

Betapa konstruktifnya.

Siapa bilang aplikasi tidak memerlukan titik masuk? Pipenv memiliki keseluruhan konstruksi untuk menangani ini.

Dimana konstruksi ini? Saya bahkan tidak dapat menemukan kata "entri" di halaman manapun dari dokumentasi pipenv di https://pipenv.readthedocs.io/en/latest/ jadi "keseluruhan konstruksi" terdengar terlalu jauh? Jika yang Anda maksud adalah penginstalan yang dapat diedit maka kita telah mencapai poin yang saya buat di atas - dengan pipenv memutuskan untuk memasangkan dirinya sendiri ke pipenv install -e . sebagai satu-satunya cara untuk menghubungkan dan mengembangkan aplikasi sebagai paket, untuk dukungan pipenv di masa mendatang di sini digabungkan ke setuptools. Saya pikir seluruh kontroversi bermuara pada poin ini dan orang-orang (tentu saja saya) frustrasi karena sekarang kita dapat mendefinisikan pustaka yang tidak menggunakan setuptools tetapi tidak dapat mengembangkannya dengan pipenv. Untuk lebih jelasnya, ini bukan sepenuhnya kesalahan pipenv (PEP 518 memutuskan untuk melakukan punt pada penginstalan yang dapat diedit), tetapi penolakannya untuk mengakui masalah telah membuat frustasi dalam wacana karena puisi memberikan alternatif yang menangani masalah ini dengan cara yang sesuai dengan format pyproject.toml . Pipenv terus mengatakan bahwa puisi membuat keputusan yang buruk tetapi sebenarnya tidak berusaha memberikan jalan ke depan.

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts

Silahkan baca dokumentasinya.

@bertjwgeer :

pyproject.toml adalah standar, dan komunitas telah mengadopsinya sebagai lokasi standar untuk menempatkan informasi yang terkait dengan sistem build, dan bagian lain dari proyek Python.

Hebat, dan kami dengan senang hati mengakomodasi sdists dan roda yang dibangun menggunakan sistem ini dan sampai ada standar untuk penginstalan yang dapat diedit, kami akan terus menggunakan pip untuk membangun sdists dan roda dan menangani resolusi ketergantungan dengan cara itu. Silakan baca tanggapan saya selengkapnya. Penulis dan pengelola pip, dari peps yang dimaksud, dan saya serta @uranusjr cukup

Saya sudah mengatakan ini tidak benar. Jika Anda benar-benar tertarik dengan penerapannya dan memiliki percakapan yang produktif, saya senang memilikinya. Jika Anda hanya di sini untuk mengatakan bahwa kami tidak tahu apa yang kami lakukan, tetapi tidak tertarik untuk mempelajari dulu apa yang kami lakukan, ini adalah satu-satunya peringatan Anda. Kami adalah sukarelawan dengan waktu terbatas dan saya mempraktikkan kebijakan toleransi 0 untuk keterlibatan beracun. Saya tidak berpura-pura bahwa pekerjaan saya sempurna dan saya tidak berpura-pura bahwa pipenv itu sempurna. Saya akan dengan senang hati menyumbangkan waktu dan upaya saya untuk jenis diskusi ini; sebagai gantinya saya meminta agar mereka tetap menghormati, bahwa mereka berpegang pada fakta, dan bahwa mereka yang berpartisipasi juga bersedia untuk belajar, mendengarkan, dan mendengarkan saya. Jika Anda berada di sini hanya untuk kotak sabun, Anda harus mencari platform lain; ini adalah pelacak masalah. Saya akan memoderasinya sesuai kebutuhan.

Diskusi ini sangat diluar topik . Jika ada yang ingin menyampaikan sesuatu yang konstruktif tentang masalah yang sedang dihadapi, silakan lanjutkan diskusi itu. Jika ada yang memiliki masalah atau pertanyaan tentang implementasi sistem build kami, buka masalah baru. Jika Anda memiliki masalah dengan dokumentasi kami, kami menerima banyak permintaan pull seputar dokumentasi dan kami sadar itu perlu diperbaiki. Mohon tunda semua diskusi itu ke masalah baru untuk topik itu. Dan harap diperhatikan: aturan yang sama akan tetap berlaku - ini bukan kotak sabun, ini pelacak masalah.

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts
Silahkan baca dokumentasinya.

Titik masuk adalah konsep yang lebih umum daripada hanya skrip konsol dan tautan ini sepenuhnya salah dalam menangani masalah tersebut. <soapbox> Cekal - Anda bukan satu-satunya pengelola proyek sumber terbuka besar di sini dan tidak ada komentar saya yang merupakan serangan pribadi terhadap Anda atau proyek tersebut. Orang-orang yang berkomentar di sini melakukannya karena mereka ingin menggunakan pipenv dan sangat menghargai fungsinya. Komentar saya bukanlah postingan dari topik pertama di utas ini, namun satu-satunya yang ditandai. Komentar tajam Anda yang menunjukkan bahwa Anda pikir saya tidak tahu apa yang saya bicarakan memalukan dan beracun.

Dalam proyek yang kami pelihara, kami dapat kotak sabun. Dan ya, pip akan mendukung semua sistem build yang sesuai yang Anda berdua pahami dengan baik akan menghasilkan metadata yang dapat dikonsumsi, dan karena pipenv menggunakan pip sebagai alat pendukung untuk mendorong proses instalasinya, seperti yang saya jelaskan, ya, pipenv akan mendukung semua kepatuhan perkakas. Saya sudah mengatakan ini.

Jadi ya, tolong bawa toksisitas Anda ke tempat lain. Sikap Anda tidak diterima di sini. Peringatan terakhir. Upaya terus-menerus untuk memicu konflik tidak akan ditoleransi.