Pip: Penyelesai Baru: Peluncuran, Putaran Umpan Balik, dan Alur Pengembangan

Saya tidak tahu bagaimana Anda merencanakannya, tetapi satu komentar adalah saya akan mendorong Anda untuk mencoba membagikan kode sebanyak mungkin antara kode baru dan kode saat ini, dan memfaktorkan ulang kode saat ini saat Anda bekerja memungkinkan lebih banyak berbagi antara jalur kode baru dan saat ini.

Salah satu alasannya adalah jika Anda membagikan lebih banyak kode, akan ada lebih sedikit kemungkinan kerusakan saat Anda mengaktifkan dan menonaktifkan perilaku baru, karena Anda akan menggunakan kode bersama itu di kedua negara bagian dan Anda tidak akan memiliki banyak perbedaan potensial dalam perilaku yang harus dihadapi.

Ini akan melibatkan CTA kepada pengguna untuk meminta mereka mencobanya dan memberikan umpan balik

Rekam jejak kami dalam mendapatkan umpan balik lanjutan tentang fitur-fitur baru sangat buruk. Kami telah mencoba rilis beta, merilis fitur baru dengan tanda "opt out" yang dapat digunakan orang jika mengalami masalah, dorongan publisitas besar untuk melanggar perubahan, dan tampaknya tidak ada yang berhasil.

Perasaan pribadi saya adalah bahwa "sediakan dan minta umpan balik" adalah variasi yang menarik dari apa yang telah kami coba sebelumnya, tetapi pada akhirnya itu tidak akan membuat banyak perbedaan. Terlalu banyak orang menggunakan pip terbaru dengan opsi default di pipeline build otomatis mereka, dan tidak menguji sebelum pindah ke versi pip baru (kami melihat ini dengan PEP 517).

Saya bertanya-tanya - bisakah kita mendapatkan hibah PSF untuk mendapatkan sumber daya untuk melakukan latihan pengujian "dunia nyata" yang besar untuk fitur ini, atau (lebih baik lagi) mengembangkan infrastruktur pengujian untuk kita? Proyek semacam itu dapat menyertakan panggilan proyek untuk memberi tahu kami alur kerja dan konfigurasinya, sehingga kami dapat menyiapkan jalur pengujian yang memastikan bahwa versi pip baru tidak merusaknya. Atau bahkan hanya menggunakan hibah untuk membuat seseorang berpengalaman dalam aspek komunikasi untuk mendapatkan penguji beta untuk fitur baru guna membantu kami menyiapkan program pengujian pengguna yang lebih baik?

Dalam hal git/GitHub, ini mungkin implementasi fitur "eksperimental" pertama dalam pip

Saya tidak 100% yakin apa yang Anda maksud dengan itu. Kami pasti memiliki fitur baru di masa lalu yang telah ditambahkan saat "cara lama" masih ada. Kami tidak cenderung membiarkannya "mati secara default, aktifkan untuk mencobanya", jika itu yang Anda maksud, tetapi itu sebagian besar karena kami tidak pernah menemukan cara yang baik untuk mendapatkan umpan balik (lihat di atas).

Saya menghabiskan ~60 menit (re-re-re-re-re-) menulis posting yang satu ini, jadi sekarang saya akan pergi melihat tempat-tempat di New York! Jika Anda tidak melihat respon cepat dari saya, itu karena saya sedang dalam mode turis.

Saya akan mendorong Anda untuk mencoba berbagi kode sebanyak mungkin antara kode baru dan kode saat ini, dan memfaktorkan ulang kode saat ini saat Anda bekerja untuk memungkinkan lebih banyak berbagi antara jalur kode baru dan saat ini.

Pastinya! Ini adalah 80% alasan mengapa saya menempatkan #5051 di depan ini -- Saya bermaksud untuk membayar banyak hutang teknis yang telah kami kumpulkan dalam logika pembangunan kami sehingga menjadi lebih mudah untuk digunakan kembali (semuanya?). Sekelompok kode harus :fire: dan saya setuju bahwa sisanya pasti harus digunakan kembali sebanyak yang masuk akal.

Kami tidak cenderung membiarkannya "mati secara default, aktifkan untuk mencobanya", jika itu yang Anda maksud

Ya, memang. Saya juga mengisyaratkan alur pengembangan di sini -- IMO boleh saja menggabungkan infrastruktur kosong (kelas dengan sekelompok metode yang hanya raise NotImplementedError() yang akan disempurnakan dalam PR berikutnya) atau tidak mencakup semua kasus (implementasi setengah matang) ke dalam cabang master selama itu hanya digunakan di belakang bendera yang secara eksplisit dicatat sebagai "eksperimental/alfa".

re: umpan balik

Saya masih muda, bodoh, dan optimis -- saya ingin menjadikan peluncuran ini sebagai pilihan, untuk mendapatkan umpan balik proaktif dan menindaklanjutinya. Dengan "proaktif", maksud saya dari orang-orang yang bersedia meluangkan waktu ekstra untuk mencoba fungsionalitas alfa/beta dan memberi tahu kami tentang fungsinya. Saya pikir jika kita membuat kebisingan yang cukup dan secara strategis menargetkan/menjangkau orang, kita bisa mendapatkan umpan balik "proaktif" yang baik dari orang-orang yang memiliki waktu dan energi untuk mencoba fungsionalitas baru guna membantu menyelesaikan detail/masalah.

Melihat perubahan "utama" kami baru-baru ini, saya pikir sebagian besar umpan balik yang kami terima bersifat reaktif -- dari pengguna yang menyadari masalah dengan alur kerja mereka saat rusak, dan kemudian menghubungi kami untuk memberi tahu kami tentang hal itu. Banyak dari mereka mungkin tidak punya waktu untuk membantu menyelesaikan detail fungsi baru, yang menyebabkan banyak gesekan. Ini juga menghabiskan banyak "anggaran churn" kami [1], yang saya tidak ingin menghabiskan lebih banyak, karena Python Packaging tidak memiliki banyak lagi yang tersisa [2].

FWIW, saya berencana untuk meminjam beberapa ide dari peluncuran PyPI, seperti membuat posting blog di lokasi yang cukup terlihat (yaitu bukan blog pribadi saya), mungkin membuat podcast, email yang dapat ditindaklanjuti dengan tepat waktu, dll. Saya juga mencari lebih banyak karya sebelumnya /avenues untuk berkomunikasi melalui. Salah satu (banyak!) hal yang saya pelajari di PyCon, adalah bahwa ada saluran yang tidak kami gunakan, yang akan membantu menyebarkan informasi tetapi tidak akan mencari untuk memeriksa apakah kami memiliki saluran untuk disebarkan.

Untuk lebih jelasnya, saya tidak mengkritik pendekatan peluncuran yang kami ambil untuk PEP 517, saya pikir itu berjalan dengan baik, terutama mengingat fakta bahwa kita semua adalah sukarelawan. Saya mencoba melihat apa yang dapat kita pelajari dan item yang dapat ditindaklanjuti untuk mencoba menghindari masalah yang kita miliki. Sebagian besar item ini memang melibatkan lebih banyak pekerjaan dari pengelola dan alasan utama saya menghabiskan waktu selama ini untuk memikirkan hal ini, adalah karena saya melihat ini sebagai latihan pembelajaran yang menyenangkan tentang bagaimana melakukan manajemen perubahan.

re: hibah

Ya, saya pikir kita pasti dapat menggunakan hibah/orang yang lebih berpengalaman untuk membantu kita mengetahui infrastruktur komunikasi, peluncuran, dan pengujian. Namun itu membutuhkan seseorang untuk melakukan pekerjaan penulisan hibah dan mencari tahu lebih banyak rencana konkret daripada yang dapat saya buat sekarang, karena saya tidak memiliki jumlah jam / minggu yang lebih stabil yang dapat saya jamin.

FWIW, PSF memiliki kontrak berkelanjutan untuk membantu mencari tahu komunikasi terkait PyPA/Packaging dengan Changeset Consulting, jadi mungkin kita bisa memanfaatkannya?

Saya sengaja tidak @-menyebut orang karena ini cukup awal dalam tahap perencanaan untuk menambahkan lebih banyak orang dalam percakapan.

Catatan kaki:

1. Istilah yang sangat bagus yang @ pganssle gunakan yang pasti akan saya gunakan.
2. Inilah mengapa saya menempatkan #3164 di bagian belakang, meskipun ada implementasi dari paket "pip-cli" yang diusulkan di sana dan memiliki konsensus yang masuk akal tentang bagaimana tampilan peluncuran yang kami inginkan.

Saya masih muda, bodoh dan optimis

:-) Dan saya terkadang terlalu tua, lelah dan sinis. Mari kita pergi dengan filosofi Anda, kedengarannya jauh lebih baik :-)

Pastinya! Ini adalah 80% alasan mengapa saya menempatkan #5051 di depan ini -- Saya bermaksud untuk membayar banyak hutang teknis yang telah kami kumpulkan dalam logika pembangunan kami sehingga menjadi lebih mudah untuk digunakan kembali (semuanya?).

Besar!

Dari IRC barusan :

[sumanah] pradyunsg: adakah yang bisa kami lakukan dari komunitas pip & packaging untuk membantu Anda menyelesaikan lebih banyak pekerjaan dengan lebih cepat di resolver?
....
[pradyunsg] Sebenarnya, saat ini, masukan di https://github.com/pypa/pip/issues/6536 mungkin akan membantu saya mencari cara untuk mendekati pekerjaan/mendapatkan umpan balik dari orang-orang, dll.
....
[sumanah] pradyunsg: re: Resolver Baru: Peluncuran, Putaran Umpan Balik, dan Alur Pengembangan #6536 -- masukan yang Anda inginkan adalah seperti: apakah pendekatan flag fitur merupakan ide yang bagus? apakah ide yang baik untuk mendapatkan umpan balik melalui beberapa mekanisme selain masalah pip GitHub? apakah ide yang baik untuk mendapatkan hibah atau serupa untuk mendapatkan pengujian manual dunia nyata & infrastruktur pengujian yang kuat dibangun, dan/atau komunikasi proaktif?
...
[pradyunsg] Yap -- apakah ide yang saya usulkan itu bagus. Juga ide/pendekatan/pemikiran tambahan apa pun yang mungkin membantu peluncuran + umpan balik menjadi lebih lancar akan luar biasa.

Jadi:

Apakah pendekatan flag fitur merupakan ide yang bagus? Ya.

Apakah ide yang baik untuk mendapatkan umpan balik melalui beberapa mekanisme selain masalah pip GitHub? Ya. Kita harus menemukan cara otomatis untuk menerima laporan bug yang kurang terstruktur dari pengguna yang kurang ahli.

Apakah infrastruktur pengujian yang lebih kuat akan membantu? Ya, banyak, dan ini adalah tempat sponsor kami mungkin dapat membantu kami.

Bisakah Changeset (saya), di bawah kontrak yang ada dengan PSF untuk membantu koordinasi/komunikasi PyPA, membantu pip dengan komunikasi proaktif untuk membuat kami melakukan pengujian manual dunia nyata yang lebih sistematis? Dengan asumsi bahwa saya memiliki jam tersisa dalam kontrak saya pada saat kami ingin memulai peluncuran ini, ya.

apakah ide yang baik untuk mendapatkan hibah atau serupa untuk mendapatkan lebih banyak bantuan dengan pengalaman pengguna, komunikasi/publisitas, dan pengujian? Ya. Hibah PSF berpotensi menarik , seperti halnya hibah NLNet (untuk permintaan di bawah 30.000 euro ), berpotensi perangkat lunak sumber terbuka penting Chan Zuckerberg untuk hibah sains , dan MOSS Mozilla . WG Pengemasan dapat menjadi pemohon pencatatan. Jika @pradyunsg atau @pfmoore ingin memberikan anggukan "ya kedengarannya menarik", saya dapat mulai menyelidiki kemungkinan tersebut dengan WG.

Jika @pradyunsg atau @pfmoore ingin memberikan anggukan "yeah kedengarannya menarik",

Itu pasti terdengar menarik bagi saya :-)

@pradyunsg atau @pfmoore ingin memberikan anggukan "yeah kedengarannya menarik"

_nods_ ya kedengarannya menarik

Apakah infrastruktur pengujian yang lebih kuat akan membantu? Ya, banyak, dan ini adalah tempat sponsor kami mungkin dapat membantu kami.

@brainwane Juga relevan di sini adalah https://github.com/pypa/integration-test. Saya pikir menyiapkan ini, adalah area potensial lain untuk pendanaan -- kita harus menambahkan ini ke https://wiki.python.org/psf/Fundable%20Packaging%20Improvements.

OKE! Saya sudah mulai berbicara dengan PSF dan dengan orang-orang Inisiatif Chan Zuckerberg tentang mengajukan hibah CZI melalui Kelompok Kerja Pengemasan. Saya telah menambahkan beberapa detail ke halaman Fundable Packaging Improvements tentang mengapa pip resolver baru itu penting, dan menambahkan proyek integration-test ke daftar itu. Dan saya telah mulai mengumpulkan nama-nama pakar pengalaman pengguna yang memiliki kapasitas untuk meneliti rantai alat distribusi/pemasangan paket all-on-the-command-line kami yang rumit, berbicara dengan pengguna untuk memahami model mental mereka tentang apa yang terjadi dan apa yang seharusnya terjadi , dan menyarankan pengelola.

Jika kami mendapatkan uang melalui hibah dari MOSS, CZI, atau NLNET, saya pikir kami akan mendapatkan uang itu ... paling cepat Oktober, mungkin. Hibah langsung dari PSF mungkin akan lebih cepat tetapi "Fokus kami saat ini adalah lokakarya Python, konferensi (khususnya untuk bantuan keuangan), dan upaya keragaman/inklusivitas Python."

Satu pertimbangan adalah bahwa saya tahu Brett & orang-orang di dewan pengarah berbicara tentang berinvestasi dalam manajemen proyek dan mencari semacam sumber daya berbayar untuk mengelola proyek-proyek ini (triase, manajemen proyek, dll) dan mereka berbicara dengan PSF secara langsung. Mungkin ada baiknya menjangkau dan mencari tahu apa yang mereka lakukan atau pikirkan, karena saya mendengar beberapa pembicaraan tentang keberlanjutan jangka panjang dan akan menjadi hal yang baik untuk terlibat di dalamnya.

Bendera fitur bagus, keikutsertaan bagus. Satu hal yang mungkin Anda pertimbangkan adalah apakah Anda dapat secara acak meminta pengguna untuk mencoba resolver (seperti, sangat sangat sangat jarang dan hanya untuk penginstalan pada satu waktu, yaitu tidak memaksa mereka untuk menyalakannya secara permanen). Kemudian Anda dapat menunjukkan bagaimana resolver itu membantu (misalnya, apa manfaatnya bagi mereka? konflik apa yang dihadapi dan diselesaikannya?)

Orang yang berasal dari javascript atau rust misalnya juga akan mengharapkan semacam file kunci, jadi itu mungkin sesuatu yang perlu dipertimbangkan ...

Maaf untuk melompat, senang melihat ini bergerak maju!

Perasaan pribadi saya adalah bahwa "sediakan dan minta umpan balik" adalah variasi yang menarik dari apa yang telah kami coba sebelumnya, tetapi pada akhirnya itu tidak akan membuat banyak perbedaan. Terlalu banyak orang menggunakan pip terbaru dengan opsi default di pipeline build otomatis mereka, dan tidak menguji sebelum pindah ke versi pip baru (kami melihat ini dengan PEP 517).

Sebagai salah satu orang yang mendapat sedikit masalah PEP 517 karena alasan ini, saya sebenarnya ingin melihat cara opt-in untuk menguji semuanya. Tetapi saya hanya tahu tentang hal-hal semacam ini karena saya berlangganan semua sumber berita pengemasan python yang saya bisa setelah masalah flag --no-use-pep517 . Apa yang saya katakan adalah bahwa menyebarkan berita semacam ini sulit dan mungkin mengapa umpan balik sulit didapat.

Saya pikir lebih banyak orang akan tertarik pada hal ini jika informasinya dapat disebarluaskan dengan lebih baik. Apakah sumber daya yang Anda cari memungkinkan?

Untuk melanjutkan apa yang dikatakan jriddy, saya juga merasa akan sangat sulit untuk membuat orang menguji berbagai tanda fitur jika mereka harus mengetahuinya, membuat perubahan pada pengaturan CI mereka untuk setiap tanda baru, dll.

Apa yang tampaknya jauh lebih bisa dilakukan, bagaimanapun, adalah jika hanya ada _satu_ tanda fitur yang perlu diketahui, untuk menguji "apa yang akan terjadi selanjutnya" dalam hal perubahan yang perlu diuji. Kemudian orang dan perusahaan dapat mengatur CI mereka untuk menjalankannya juga (tanpa gagal membangun kesalahan). Saya sedang memikirkan sesuatu yang mirip dengan Rust, di mana perubahan semacam ini terjadi di saluran "beta" dari rantai alat, dan mudah untuk menyiapkan saluran CI lain untuk menjalankan berbagai hal di rantai alat beta, dan mengirim kesalahan kepada seseorang.

Kuncinya adalah, penyiapan ini perlu dipelajari dan dilakukan _hanya sekali_, daripada harus terus-menerus mempelajari flag fitur individual baru, memodifikasi penyiapan CI, atau mengujinya secara manual.

Apa yang tampaknya jauh lebih bisa dilakukan, bagaimanapun, adalah jika hanya ada _one_ flag fitur yang perlu diketahui,

Dalam arti, bukankah ini sudah ada dalam bentuk --pre ? Mungkinkah saluran rilis beta untuk pip hanya masalah menjalankan pip install --upgrade --pre pip ?

Maaf untuk melompat, senang melihat ini bergerak maju!

@techalchemy tolong, dari semua orang, _you_ pasti tidak perlu menyesal untuk pitching dalam diskusi ini.

Apakah sumber daya yang Anda cari memungkinkan?

Sampai batas tertentu, ya.

reg: rilis beta/"saluran" untuk pip

Terima kasih telah mendengarkan @jriddy dan @chrish42. Sementara saya berpikir bahwa secara umum itu pasti percakapan yang berguna/penting untuk dimiliki, saya juga merasa sedikit OT untuk masalah ini. Tidak kurang, saya akan menjawab di sini sekali; jika kita ingin membahas ini lebih lanjut, mari kita buka masalah baru.

Kami telah mencobanya di masa lalu -- terakhir dengan pip 10 -- tetapi tidak berhasil dengan baik. Saya sedikit skeptis tentang seberapa baik hal itu dapat berjalan ke depan juga, tetapi saya juga dapat membayangkan bahwa beberapa perubahan pada proses kami dapat mengakibatkan ini bekerja dengan lancar bagi kami. Mungkin kita bisa melakukan serangkaian fitur "beta only" atau semacamnya? Saya membayangkan -X all sebagai sintaks untuk itu di #5727. Mungkin kita bisa mengambilnya sebagai bagian dari rencana peluncuran ini? tidak. Kita perlu menginvestasikan waktu dan energi untuk mencari tahu ini. :)

Seperti disebutkan dalam https://github.com/pypa/packaging-problems/issues/25#issuecomment -520167480 , saya pikir penting untuk memiliki penjelasan terkonsolidasi tentang bagaimana pemecah mengubah pengalaman pip. Banyak orang akan frustrasi dengan peralihan ke sistem yang lebih kaku (walaupun semuanya harus lebih dapat diandalkan secara keseluruhan, mereka akan diblokir di tempat-tempat di mana mereka saat ini tidak diblokir.

Memiliki penjelasan utama tentang bagaimana hal-hal telah berubah dan mengapa itu adalah perubahan yang baik akan membuat menanggapi orang-orang yang marah itu jauh lebih sederhana. Posting tautan dan lihat apakah mereka memiliki pertanyaan lebih lanjut.

Pra-rilis adalah ide yang bagus. Di conda, kami memiliki saluran pra-rilis, conda-canary. Kami mendorong orang untuk menyiapkan pekerjaan CI untuk melawan kenari dengan cara yang membantu mereka melihat apakah perubahan conda akan merusaknya. Idealnya mereka memberi tahu kami sebelum kami merilis versi itu. Saluran itu merupakan kegagalan yang cukup menyedihkan. Satu-satunya saat orang benar-benar menggunakannya adalah ketika mereka ingin mendapatkan rilis terbaru untuk memperbaiki beberapa bug yang mereka perjuangkan. Kami tidak mendapatkan banyak laporan dari pengguna awal yang kami tuju. Saya masih berpikir prarilis adalah ide yang bagus, karena ketika rilis berjalan buruk dan orang-orang marah kepada Anda karena melanggar 700 node terkelola mereka, Anda dapat mengatakan "baik, itu tersedia selama seminggu sebelum kami merilisnya. Mengapa tidak Anda menguji hal-hal ini sebelum Anda meluncurkannya ke 700 node?" Anda memberi orang kesempatan untuk membuat segalanya bekerja lebih baik. Bantu mereka menyadari bahwa melewatkan kesempatan itu berarti lebih banyak penderitaan bagi mereka di masa depan. Ini adalah investasi yang berharga bagi mereka, dan jika mereka melakukannya sebagai bagian dari CI mereka, mereka tidak memerlukan waktu selain penyiapan.

Mengenai bendera: Saya pikir lebih baik memiliki opsi konfigurasi (mungkin selain bendera). Saya tidak ingin melewati bendera sepanjang waktu. Saya tidak yakin apakah pip memiliki kemampuan ini - mungkin Anda memberi tahu orang-orang yang menginginkan sakelar yang lebih permanen untuk menggunakan env var yang sesuai?

Mengenai bendera:

opsi CLI pip, secara otomatis dipetakan ke opsi file konfigurasi dan variabel lingkungan, dengan nama yang sesuai.

@marahan Terima kasih telah bergabung, sangat dihargai! :)

Mengenai opsi "biarkan saya melakukan apa yang saya inginkan" untuk mengabaikan dependensi yang rusak, saya pikir akan diinginkan untuk menyusun tanda fitur sedemikian rupa sehingga dapat juga berfungsi sebagai penyisihan setelah resolver diaktifkan secara default (misalnya, mulai dengan --avoid-conflicts sebagai opt-in, akhirnya pindah ke --no-avoid-conflicts sebagai opt-out, tetapi menerima kedua opsi dari awal)

Anda juga ingin mempertimbangkan bagaimana --ignore-installed berinteraksi dengan solver - ketika dilewatkan, Anda mungkin harus mengabaikan semua persyaratan untuk paket yang sudah diinstal.

Di luar itu, menangani hal-hal sebagai tambalan refactoring yang lebih kecil untuk membuat integrasi resolver lebih mudah adalah cara terbaik untuk dilakukan (itulah pendekatan yang memungkinkan API konfigurasi baru untuk CPython: banyak refactoring pribadi yang akhirnya cukup stabil untuk dipublikasikan)

@ncoghlan Apa artinya "memilih keluar" dari resolver? Sepenuhnya menghindari resolusi ketergantungan (dan karenanya resolver) adalah --no-deps . Saya mengerti bahwa ada kebutuhan untuk "abaikan konflik versi pada paket ini" atau sesuatu seperti itu.

Secara pribadi, saya tidak melihat ada gunanya menjaga logika resolusi "tetap terlihat pertama" lebih lama dari periode transisi ke resolver baru.

Namun, jika ada kasus penggunaan yang tidak dapat dicakup oleh kedua opsi ini, saya sangat ingin mengetahuinya. :)

Secara lebih luas, jika ada alur kerja yang memiliki masalah dengan perilaku penyelesai yang ketat, saya ingin tahu seperti apa itu, sedini mungkin, untuk dapat mengetahui apakah/bagaimana mendukungnya.

Secara pribadi, saya tidak melihat ada gunanya menjaga logika resolusi "tetap terlihat pertama" lebih lama dari periode transisi ke resolver baru.

IDK, saya menggunakan "fitur" ini untuk melakukan beberapa hal yang cukup gila dengan build, seperti...

# install just the packages I've built specifically
pip install --no-index --no-deps --find-links=/path/to/my/local/build/cache -r local-reqs.txt

# ...snip to later in a dockerfile, etc...

# install the deps from public PyPI
pip install -r local-reqs.txt

Dalam hal ini saya memintanya untuk menyelesaikan dependensi saya setelah saya menginstal beberapa paket yang telah ditentukan sebelumnya dari ruang kemudi lokal. Saya kira saya bisa membaca versi persis saya ke dalam file local-reqs itu untuk membuat penyelesai senang, tetapi saya sebenarnya menemukan perilaku pip saat ini cukup berguna dalam memungkinkan jenis langkah-langkah injeksi build yang sewenang-wenang ini. Bisa jadi kasus alur kerja pemanas spasi , saya akui.

Tapi mungkin perilaku "resolusi naif" masih berguna.

Saya setuju dengan @pradyunsg. Saya tidak berpikir itu layak untuk mempertahankan kode yang ada dan resolver baru tanpa batas. Tentu saja sebagai pengelola pip saya tidak tertarik melakukan itu.

Dari POV pengguna akhir, saya menerima bahwa mungkin ada skenario aneh di mana resolver baru mungkin tidak melakukan hal yang benar. Dan memiliki bendera darurat "berikan saya kembali perilaku lama" adalah mekanisme transisi yang penting (walaupun dapat diperdebatkan apakah "kembalikan sementara ke versi pip sebelumnya" tidak sama baiknya - meskipun hal-hal seperti penggunaan umum CI itu secara otomatis menggunakan pip terbaru membuat menganjurkan opsi itu bermasalah). Tapi untuk jangka panjang, mengapa kita perlu mempertahankan perilaku saat ini? Saya dapat membayangkan situasi utama berikut:

1. Bug pemecah masalah. Kemungkinan yang jelas, perbaikan mudah - perbaiki bug di rilis pip berikutnya.
2. Kasus di mana resolver lama salah (menghasilkan hasil yang gagal memenuhi batasan). Kami tidak bermaksud untuk mendukung itu ke depan, kan? (Setidaknya tidak melalui sesuatu yang kurang ekstrem daripada pengguna menyematkan apa yang mereka inginkan dan menggunakan --no-deps untuk mematikan resolver).
3. Kasus dimana resolver lama dan baru memberikan hasil yang berbeda, keduanya memenuhi batasan yang diberikan. Pengguna dapat menambahkan batasan untuk memaksakan hasil lama (jika tidak bisa, itu membuat kita kembali ke (2)). Kita harus memberi mereka waktu untuk melakukannya, tetapi kemudian lepaskan resolver lama, sama seperti fungsionalitas usang lainnya.
4. Kasus tepi yang kami anggap terlalu rumit/aneh untuk didukung. Ini seperti (3), tetapi di mana kami tidak menyatakan bahwa resolver baru memberikan hasil yang "benar". Pengguna masih dapat memodifikasi batasan untuk menghindari kasus aneh, atau menyematkan dan menggunakan --no-deps . Tetapi pada akhirnya, kami mengatakan "jangan lakukan itu", dan jika pengguna mengabaikan pesan itu, sekali lagi di beberapa titik kami menghapus resolver lama yang mengatakan "kami memperingatkan Anda".

Apakah ada orang lain yang saya lewatkan? Khususnya di mana mencela dan kemudian menghapus resolver lama tidak mungkin?

Omong-omong, di mana tempat terbaik untuk memposting skenario "ini kasus tepi yang saya pikirkan", sehingga tidak tersesat? Saya pikir akan berguna untuk mengumpulkan sebanyak mungkin situasi aneh sebelumnya, jika saja kita bisa memulai lebih awal dalam menulis kasus uji :-)

PS Kita mungkin juga harus sebagai bagian dari pekerjaan persiapan untuk resolver baru, mensurvei apa masalah kendala "khas" (berdasarkan apa yang ada di PyPI). Untuk bagian saya sendiri, sangat jarang saya memiliki sesuatu yang lebih kompleks daripada "instal pip". Akan sangat memalukan untuk terjebak dalam kasus-kasus kompleks sehingga kita kehilangan sebagian besar kasus yang lebih sederhana.

1. resolver terlalu lambat (lihat conda). Jika saya harus memilih antara 20 menit plus resolver, atau perilaku saat ini, seringkali saya menginginkan perilaku saat ini (atau setidaknya mencoba; dalam banyak kasus itu akan memberikan hasil yang baik-baik saja).

2. metadata salah. tidak banyak masalah hari ini, tapi mudah untuk membayangkan kasus yang harus dipecahkan tetapi tidak. Metadata PyPI dalam kondisi yang lebih buruk daripada metadata conda/conda-forge, dan itu sudah menjadi masalah bagi conda. jika itu salah dan sebagai pengguna saya tidak bisa mendapatkan solusi, saya ingin memilih keluar.

@rgommers Untuk 6, opsi gaya "abaikan versi konflik pada paket ini" dapat berfungsi, bukan?

Terima kasih, @rgommers - itu poin bagus.

Resolver terlalu lambat, saya akan menghitung sebagai bug resolver. Jika itu tidak dapat memberikan hasil yang cukup berkinerja pada kasus-kasus sederhana, itu tidak sesuai untuk tujuan menurut saya. Jika di sisi lain Anda memiliki jaringan kendala yang sangat kompleks yang membutuhkan waktu lebih lama dengan resolver penuh (saya harap 20 menit berlebihan, saya tidak menganggap itu dapat diterima dalam keadaan apa pun!), maka kita masuk ke "hal-hal yang kita mempertimbangkan terlalu kompleks untuk mendukung" wilayah. Dengan kata lain, adakah yang mencoba meminta conda untuk memberikan resolver "cepat dan kotor" yang tidak akurat tetapi cepat? Jika mereka tidak akan melakukan itu (dan saya cukup yakin mereka tidak akan melakukannya) lalu mengapa masuk akal untuk mengharapkan pip?

Metadata yang buruk jelas merupakan sesuatu yang saya anggap sebagai "kami tidak akan mendukungnya" (ingat, saya berbicara tentang "setelah periode penghentian" di sini!). Memberikan waktu kepada pengguna untuk memperbaiki metadata, dan memberikan opsi klausa melarikan diri "abaikan versi konflik pada paket X" adalah IMO yang cukup, kita seharusnya tidak diharapkan untuk mempertahankan semua mesin lama hanya karena beberapa orang tidak akan memperbaiki metadata mereka.

Tapi ya, mempublikasikan fakta bahwa kita membutuhkan metadata yang baik karena resolver yang akurat mengikuti aturan "sampah masuk, sampah keluar", dan memantau bagaimana orang menanggapi pesan itu, merupakan bagian dari proses peluncuran.

saya memintanya untuk menyelesaikan dependensi saya setelah saya menginstal beberapa paket yang sangat ditentukan sebelumnya dari ruang kemudi lokal.

@jriddy Strategi resolusi "gunakan instalasi yang ada jika kompatibel" akan berhasil untuk ini.

di mana tempat terbaik untuk memposting skenario "ini kasus tepi yang saya pikirkan", sehingga tidak tersesat?

https://github.com/pradyunsg/zazo/

Untuk 6, opsi gaya "abaikan versi konflik pada paket ini" dapat berfungsi, bukan?

ya, itu terdengar seperti pilihan yang tepat

(Saya harap 20 menit berlebihan, saya tidak menganggap itu dapat diterima dalam keadaan apa pun!), Kemudian kita masuk ke wilayah "hal-hal yang kita anggap terlalu rumit untuk didukung". Dengan kata lain, adakah yang mencoba meminta conda untuk memberikan resolver "cepat dan kotor" yang tidak akurat tetapi cepat? Jika mereka tidak akan melakukan itu (dan saya cukup yakin mereka tidak akan melakukannya) lalu mengapa masuk akal untuk mengharapkan pip?

Ada banyak orang yang mengeluh tentang kinerja conda , dan mereka mendengarkan - tetapi banyak pekerjaan, lihat posting blog terbaru mereka. Saya tidak tahu apakah akan ada opsi conda cepat dan kotor. Namun, ada solusi terkait (peretasan) seperti conda-metachannel yang memungkinkan Anda memangkas grafik ketergantungan (menyertakan/mengecualikan paket secara manual) untuk mendapatkan solusi lebih cepat. Jadi saya pikir itu sejalan.

Namun, perlu diingat bahwa ini _pasti_ diperlukan kecuali Anda:

• melakukan pekerjaan yang jauh lebih baik daripada conda langsung (tidak terlalu mungkin, itu tidak seperti orang-orang itu tidak tahu apa yang mereka lakukan - itu hanya masalah yang sangat berbulu).
• hanya memiliki masalah yang lebih kecil untuk dipecahkan (semoga tidak benar, PyPI besar dan dengan metadata yang baik masalahnya harus besar)

Metadata yang buruk jelas merupakan sesuatu yang saya anggap sebagai "kami tidak akan mendukungnya"

Cukup adil. Seluruh pendirian tentang "kami tidak menegakkan metadata yang benar" tidak membantu di sini. Kecuali itu berubah baru-baru ini? (dan saya tahu, ini masalah PyPI bukan masalah pip - tapi ini terkait).

Saya tidak yakin Anda benar-benar memiliki pilihan yang Anda pikir Anda miliki.

Apa yang dilakukan oleh resolver cepat dan kotor secara berbeda dari yang akurat? Apa itu turun menjadi lebih cepat? Kendala adalah kendala - mereka tidak datang dalam nilai. Anda memuaskan mereka atau tidak. Mungkin Anda dapat memuaskan mereka hanya dengan nama untuk memulai, kemudian dengan versi, dll.

Ketika orang kesal dengan Conda yang lambat, pada dasarnya selalu karena metadata yang buruk. Ingatlah bahwa Anda akan disalahkan atas kelambatan yang dirasakan, terlepas dari akar masalahnya. Metadata yang buruk terkadang merupakan batasan yang salah, tetapi lebih sering kurangnya batasan yang memungkinkan pertimbangan opsi yang jauh lebih tua dan tidak diinginkan. Conda meningkat secara besar-besaran baru-baru ini dengan melakukan satu hal kecil: menghapus koleksi perangkat lunak lama kami yang memiliki batasan yang tidak memadai (kebanyakan terlalu terbuka). Kendala terbuka ini menyebabkan conda mengeksplorasi solusi yang sangat buruk yang membutuhkan banyak penurunan versi. Di sinilah pemecahan membutuhkan waktu berjam-jam. Downgrade adalah operasi yang sangat, sangat mahal karena cara mereka dapat mengalir, dengan setiap langkah yang semakin berkurang kendalanya dan lebih mahal.

Masalah dengan "sampah masuk, sampah keluar" sebagai mentalitas adalah bahwa sebagai pengelola pemecah masalah, Anda memegang kantong. Kecuali Anda memiliki heuristik yang sangat baik untuk apa itu sampah, Anda tidak berdaya. Anda akhirnya menjadi orang yang harus menyelidiki mengapa pemecahnya lambat, mengisolasi paket masalah, dan kemudian menanyakan sumber masalah untuk memperbaikinya. Ini bukan posisi yang bagus, percayalah. Kami menghabiskan banyak waktu mencoba untuk menjelaskan kepada orang-orang mengapa conda mengambil selamanya atau tidak akan bekerja dengan beberapa campuran conda-forge, bioconda, atau saluran pihak ke-3 lainnya. Kami akhirnya harus melakukan pekerjaan detektif dan memberi tahu saluran pihak ke-3 itu apa yang perlu mereka perbaiki. Menyebalkan sekali.

Setiap perbandingan dengan conda perlu mempertimbangkan bahwa conda mengambil pendekatan yang sangat berbeda untuk masalah tersebut. Conda memiliki satu sumber metadata raksasa dan menyelesaikan semuanya sekaligus, tetapi pip secara rekursif memecahkan dan mengoptimalkan setiap hal pada satu waktu (mundur seperlunya). Itu mungkin memberi Anda jalur pengoptimalan yang berbeda.

@wolfv baru-baru ini dieksplorasi menggunakan libsolv untuk conda. Dia akhirnya frustrasi karena dia tidak bisa memberikan jawaban yang sama seperti conda. Ini bermuara pada perbedaan antara pendekatan ini. Libsolv adalah pemecah backtracking. Ini mungkin berfungsi sebagai tambahan opsional yang dikompilasi ke pip untuk mempercepat, meskipun saya tahu bahwa Anda sensitif untuk tidak memasukkan kode yang dikompilasi secara langsung dengan pip.

( @pradyunsg baru saja memposting pembaruan Agustus di blognya .)

Beberapa pertanyaan dan kebutuhan yang diajukan orang sekarang adalah hal-hal yang perlu kita mulai kumpulkan sekarang, seperti kasus uji.

Tetapi juga: menurut kami, timeline apa yang realistis untuk peluncuran ini? Ini sangat bergantung pada kesehatan dan waktu luang Pradyun, dan ketersediaan tinjauan kode dari pengelola pip lain, dan apakah kami mendapatkan hibah yang kami ajukan, tetapi saya pikir urutannya adalah seperti:

• membangun refactor logika: sedang berlangsung, dilakukan sekitar Desember-Februari
• Penelitian dan desain UX, uji pembangunan infrastruktur, berbicara dengan hilir dan pengguna tentang tanda konfigurasi dan jadwal transisi: kami membutuhkan dana untuk ini; awal paling awal mungkin Desember, akan memakan waktu 2-3 bulan
• memperkenalkan abstraksi yang didefinisikan dalam resolvelib/zazo saat melakukan pengujian alfa: akan memakan waktu beberapa bulan, jadi, memperkirakan secara konservatif, Mei 2020?
• mengadopsi resolusi ketergantungan yang lebih baik dan melakukan pengujian beta: ?

Apakah ini benar? Apa yang saya lewatkan?

Saya bertanya karena beberapa pekerjaan pengumpulan-info adalah hal yang harus dilakukan oleh manajer proyek dan/atau peneliti UX, menurut pendapat saya, dan karena beberapa kemajuan di https://github.com/pypa/packaging-problems/issues/264 dan isu-isu lain mungkin membantu dengan keprihatinan orang telah dibawa di sini.

Metadata yang buruk terkadang merupakan batasan yang salah, tetapi lebih sering kurangnya batasan yang memungkinkan pertimbangan opsi yang jauh lebih tua dan tidak diinginkan.

Karena menggunakan dependensi yang tidak dibatasi atau >= some_old_version adalah aturan daripada pengecualian untuk setup.py / pyproject.toml , ini akan menjadi masalah. Saya tidak terlalu peduli apakah itu "batasan yang salah" atau pemecah perlu membuat pilihan yang berbeda - ini adalah keadaan metadata pada PyPI.

Kendala terbuka ini menyebabkan conda mengeksplorasi solusi yang sangat buruk yang membutuhkan banyak penurunan versi.

Anda ahlinya di sini, tetapi tidakkah ada solusi pragmatis untuk ini? Dalam sebagian besar kasus, tidak diperlukan penurunan versi, jadi coba lakukan itu terlebih dahulu. Kemudian, downgrade hanya 1 versi untuk setiap paket. Jika Anda perlu menurunkan versi lebih lanjut, itu hampir selalu merupakan solusi yang salah (bisa karena metadata yang buruk atau yang lainnya).

Sebenarnya, saya tidak yakin apakah pip _can_ bahkan menurunkan versi. Awalnya memiliki strategi "upgrade segalanya" yang terlalu agresif, sekarang "upgrade sesuai kebutuhan" bekerja dengan cukup baik. Saya belum pernah melihatnya menurunkan versi apa pun, dan dalam praktiknya ini berfungsi cukup baik untuk penggunaan biasa.

Contoh penurunan versi yang harus dihadapi conda, tetapi pip tidak akan melakukannya: pengguna anaconda atau miniconda dengan python 3 mulai dengan python 3.7. Pengguna terkadang perlu menginstal sesuatu yang hanya tersedia untuk python 3.6. Pemecah harus menurunkan versi python dan semua paket non-noarch lainnya. Ini adalah kasus khusus yang mungkin dapat dioptimalkan dengan memiliki perilaku khusus untuk perubahan versi python, tetapi ini menggambarkan titik bagaimana perubahan dalam satu paket mungkin memerlukan penurunan versi ke yang lain. "Ini telah berhasil sejauh ini" adalah keberuntungan yang bodoh, bukan yang sebenarnya berhasil sepanjang waktu.

Adapun untuk membatasi versi, Anda tidak dapat menerapkannya dalam penyelesaian itu sendiri. Anda memiliki kendala, dan segala jenis "pembukaan oleh satu versi" tidak dapat diharapkan cukup umum, karena berbeda untuk setiap paket. Anda dapat memotong metadata berdasarkan versi sebelum pemecah. Itulah "current_repodata.json" conda. Hanya versi terbaru. Itu membuat segalanya berjalan sangat cepat ketika berhasil, tetapi orang akan menjadi sangat marah jika itu adalah satu-satunya repodata. Hal-hal tidak akan dapat direproduksi, dan mereka akan frustrasi karena spesifikasi yang berfungsi suatu hari mungkin tidak berfungsi pada hari berikutnya. Kami menyediakan fallback ke repodata lengkap, dan juga berencana untuk memperkenalkan subset berbasis waktu, dengan hanya versi terbaru yang tersedia pada titik waktu tertentu. Secara bertahap membuka data indeks yang tersedia mungkin merupakan konsep yang lebih berguna dengan pemecah backtracking.

pip _can_ bahkan menurunkan versi.

Bisa -- untuk pip, menurunkan versi hanyalah langkah uninstall-instal seperti peningkatan. Dan itu melakukan downgrade ketika melihat batasan yang diminta untuk dipenuhi.

Berikut ini melakukan downgrade setuptools -- selama itu adalah hal pertama yang dilihat pip:

pip install "setuptools < 20.0"

di mana tempat terbaik untuk memposting skenario "ini kasus tepi yang saya pikirkan", sehingga tidak tersesat?

https://github.com/pradyunsg/zazo/

Terima kasih, saya akan mengingatnya. Meskipun memikirkan kembali, "kasus patologis" saya sebenarnya tidak terlalu patologis. Ini sebagian besar hanya kasus ekstrem dari fakta bahwa untuk mengetahui metadata ketergantungan suatu paket, Anda harus mengunduh dan membongkar paket, dan dalam kasus tertentu ini dapat memicu pengunduhan banyak paket hanya untuk menolaknya. Itu mungkin merupakan batasan penting dari protokol "indeks sederhana" yang perlu kita tangani, tetapi ini bukan masalah penyelesai secara langsung.

Contoh penurunan versi yang harus dihadapi conda, tetapi pip tidak akan melakukannya: pengguna anaconda atau miniconda dengan python 3 mulai dengan python 3.7. Pengguna terkadang perlu menginstal sesuatu yang hanya tersedia untuk python 3.6. Pemecah harus menurunkan versi python dan semua paket non-noarch lainnya. Ini adalah kasus khusus yang mungkin dapat dioptimalkan dengan memiliki perilaku khusus untuk perubahan versi python, tetapi ini menggambarkan titik bagaimana perubahan dalam satu paket mungkin memerlukan penurunan versi ke yang lain. "Ini telah berhasil sejauh ini" adalah keberuntungan yang bodoh, bukan yang sebenarnya berhasil sepanjang waktu.

Ini juga merupakan kasus di mana Anda biasanya _tidak ingin menurunkan versi_. Sebagai pengguna, saya lebih suka mendapatkan pengecualian yang memberi tahu saya bahwa paket tidak tersedia, dan izinkan saya menginstal 3.6 secara eksplisit jika itu yang saya inginkan.

Contoh lain adalah inkonsistensi antar saluran. Contoh terbaru: kami menggunakan Python 3.7.3, lalu base mendapat 3.7.4 . Saya tidak peduli dengan perbedaan versi itu, dan sebagian besar pengguna tidak akan peduli. Standar "tidak melakukan apa-apa" akan jauh lebih baik daripada "hei .4 > .3 , mari tingkatkan itu dan kemudian ubah saluran paket lain ke base jika kita harus (bahkan jika itu menurunkannya)".

Kami menyediakan fallback ke repodata lengkap, dan juga berencana untuk memperkenalkan subset berbasis waktu, dengan hanya versi terbaru yang tersedia pada titik waktu tertentu

Kedengarannya seperti peningkatan yang sangat berguna.

Masalah dengan "sampah masuk, sampah keluar" sebagai mentalitas adalah bahwa sebagai pengelola pemecah masalah, Anda memegang kantong. Kecuali Anda memiliki heuristik yang sangat baik untuk apa itu sampah, Anda tidak berdaya.

Ya itu benar. Saya pikir setiap IDE, distribusi atau "antarmuka umum untuk banyak hal" memiliki masalah ini.

Berikut ini melakukan downgrade setuptools

Itu adalah penurunan versi yang diminta pengguna. Yang tidak langsung adalah apa yang saya maksud (misalnya setuptools<20.0 di pyproject.toml`). Itu akan berhasil juga, saya kira, tetapi jarang dalam praktiknya.

Masalah dengan "sampah masuk, sampah keluar" sebagai mentalitas adalah bahwa sebagai pengelola pemecah masalah, Anda memegang kantong.

100% setuju. Itu adalah sesuatu yang harus ditangani dengan sangat hati-hati. Tetapi sebaliknya, mencoba mencari perilaku yang waras untuk sampah lama tidak dapat dilakukan - kita harus menarik garis di suatu tempat .

Sekedar mengingatkan, diskusi ini dipicu oleh pertanyaan apakah kita perlu mempertahankan resolver yang ada untuk waktu yang tidak terbatas. Saya tidak yakin salah satu dari poin-poin ini benar-benar memengaruhi pertanyaan itu - resolver yang ada tidak benar, yang terbaik yang dapat Anda katakan adalah bahwa itu adalah perilaku rusak yang diketahui orang. Jadi saya mendukung apa yang saya katakan di atas, tidak ada alasan untuk mempertahankan resolver lama di luar periode transisi awal.

Dan sebenarnya, untuk sebagian besar kasus penggunaan, resolver lama dan baru kemungkinan besar akan memberikan hasil yang sama.

"Benar" tidak masalah bagi pengguna ketika mereka dilanggar oleh perubahan Anda. Setiap perubahan perilaku akan benar-benar membuat marah sejumlah pengguna. Memberitahu mereka bahwa alur kerja mereka salah dan bahwa mereka perlu berubah bukanlah strategi yang sangat efektif bagi saya. Saya pikir Anda perlu memainkannya dengan telinga. Saya tentu tidak ingin mempertahankan resolver lama selamanya, tetapi Anda mungkin perlu memberi orang jalan untuk menyimpannya - seperti menjadikannya plugin yang diadopsi dan dipelihara orang lain, dan orang dapat menginstalnya secara terpisah dari pip.

mencoba menemukan perilaku yang waras untuk sampah lama tidak layak - kita harus menarik garis di suatu tempat.

Ya, tapi apa itu "sampah tua?" Apa yang membedakannya? Bagaimana dengan sampah yang buruk vs sampah yang baik (mengingat bahwa yang lebih baru tidak selalu lebih baik)? Saran saya adalah menghabiskan banyak waktu membuat pemecah menjadi sangat dapat di-debug. Permudah pengguna (bukan hanya Anda sebagai ahlinya) untuk melacak ke mana arahnya, untuk memudahkan mengidentifikasi kapan metadata yang buruk menjadi masalah, dan apa metadata buruk itu. Ini adalah keterampilan yang tidak dimiliki sebagian besar pengguna saat ini, dan sejujurnya sebagian besar pengguna yang pernah saya lihat tidak ingin memiliki keterampilan ini. Saya tidak berpikir Anda (atau conda dalam hal ini) akan pernah dapat memiliki heuristik otomatis yang sepenuhnya akurat untuk buruk vs baik.

Ini juga merupakan kasus di mana Anda biasanya tidak ingin menurunkan versi. Sebagai pengguna, saya lebih suka mendapatkan pengecualian yang memberi tahu saya bahwa paket tidak tersedia, dan izinkan saya menginstal 3.6 secara eksplisit jika itu yang saya inginkan.

@rgommers , conda 4.7 pindah ke ini - membutuhkan spesifikasi python eksplisit untuk mengubah versi minor. Orang-orang telah membencinya. Saya tidak tahu berapa bagian dari populasi yang vokal, tetapi banyak orang benar-benar tidak suka bahwa mereka dulu dapat conda install sesuatu, dan sekarang mereka tidak bisa. Mereka tidak terlalu mempedulikan alasannya, dan mereka sebagian besar tenang dengan jawabannya, tetapi kami masih menghadapi permusuhan untuk sementara waktu. Contoh lain dari

"Benar" tidak masalah bagi pengguna ketika mereka dilanggar oleh perubahan Anda.

Contoh lain adalah inkonsistensi antar saluran. Contoh terbaru: kami menggunakan Python 3.7.3, lalu base mendapat 3.7.4. Saya tidak peduli dengan perbedaan versi itu, dan sebagian besar pengguna tidak akan peduli. Standar "tidak melakukan apa-apa" akan jauh lebih baik daripada "hei .4 > .3, mari tingkatkan itu dan kemudian ubah saluran paket lain ke basis jika kita harus (bahkan jika itu menurunkan versi itu)".

Ini adalah poin yang jauh lebih rumit. Anda pada dasarnya mengusulkan kriteria pengoptimalan yang berbeda. Anda mungkin telah melihat 11 langkah saat ini di posting blog kami di https://www.anaconda.com/understanding-and-improving-condas-performance/

Ini sangat rumit, dan tidak ada optimal global yang memenuhi setiap situasi. Mengingat kompatibilitas biner, dan saluran sebagai pulau kompatibilitas tersebut, prioritas saluran yang kuat sangat penting. Python build tidak masalah, Anda benar, tetapi saat ini tidak ada cara untuk mengekspresikan batasan kompatibilitas biner vs. batasan versi sederhana dan sederhana. Anda akan membutuhkan itu untuk memikirkan ide Anda untuk membiarkan semuanya begitu saja. Jika tidak, Anda akan segera berada di neraka ketidakcocokan biner.

Hai, terima kasih @marahan karena telah menyebut saya dalam masalah ini. Saya ingin berpadu lebih awal tetapi belum menemukan waktu.

Memang saya bereksperimen sedikit dengan menggunakan libsolv sebagai pemecah untuk spesifikasi conda. Dan itu berhasil -- perbedaan yang tersisa sekarang adalah bahwa conda tidak terlalu peduli dengan nomor build, tetapi libsolv dalam cara pengkodeannya (dan dengan pemecah backtracking). Bahkan ketika menggunakan repodata penuh, libsolv sangat cepat – saya akan mengatakan bahwa kecepatan libsolv cukup cepat untuk tidak mengganggu :)

Kontribusi besar saya untuk libsolv adalah membuatnya kompatibel lintas platform sehingga sekarang dapat dikompilasi di Windows, OS X dan Linux.

Saya benar-benar akan menganjurkan untuk menggunakan libsolv untuk resolver baru, meskipun itu adalah gumpalan kode yang dikompilasi (setidaknya cepat) dan @mlschroe mungkin tersedia untuk membantu – dia banyak membantu dengan dukungan libsolv untuk conda matchspec.

Di sisi lain saya tidak yakin pada tahap apa pengembangan resolver dan apakah sekarang sudah terlambat, dan apakah kode yang dikompilasi dapat diterima atau tidak.

Anda mungkin telah melihat 11 langkah saat ini di posting blog kami di https://www.anaconda.com/understanding-and-improving-condas-performance/

Memang saya lakukan. Itu adalah posting blog yang bagus.

Anda pada dasarnya mengusulkan kriteria pengoptimalan yang berbeda.

tidak juga. Saya pikir _"batasan kompatibilitas biner vs. batasan versi sederhana dan sederhana"_ hanya menunjuk ke sesuatu yang mungkin saya lewatkan. Apa yang saya harapkan adalah bahwa tidak ada paket yang harus memiliki python >= 3.7.4 atau == 3.7.4 dalam metadatanya, selalu == 3.7 (baru saja memeriksa scipy, meta.yaml mengatakan python dan conda_forge.yml mengatakan max_py_ver: '37' - masuk akal). Jadi memperkenalkan 3.7.4 seharusnya tidak melakukan apa pun - resolver yang memilih 3.7.3 dan tidak mengubah apa pun jauh lebih murah (dan valid menurut 11 langkah Anda) daripada memaksa 3.7.4 dan memicu rantai naik/turun.

Kira bagian ini keluar dari topik untuk rencana peluncuran pip , jadi senang untuk membawa ini ke tempat lain.

Saran saya adalah menghabiskan banyak waktu membuat pemecah menjadi sangat dapat di-debug.

+1

Juga: buat (simpan) sedapat mungkin diperbaiki. Itu hal yang menyenangkan dengan pip sekarang, jika berantakan biasanya seseorang dapat melakukan cd site-packages && rm -rf troublesome_package (mungkin diikuti dengan menginstal ulang dengan --no-deps ) dan semuanya berfungsi kembali. Orang-orang seperti conda , apt dan teman-teman jauh lebih sulit untuk diperbaiki dengan cara itu.

Anda pada dasarnya mengusulkan kriteria pengoptimalan yang berbeda.

Saya rasa Anda tidak cukup mempertimbangkan konsep saluran ke dalam pemikiran Anda. Saya tidak tahu seberapa relevan itu dengan pip. Jelas jauh lebih sedikit daripada conda, tapi saya tidak yakin apakah itu sama sekali tidak relevan. Orang masih dapat mengumpulkan paket dari lebih dari satu indeks sekaligus, bukan?

Paket tidak memiliki python >=3.7.4, atau ==3.7.4. Standar dalam kemasan conda adalah memiliki batas atas dan batas bawah. Ini umumnya secara otomatis ditentukan oleh conda-build menggunakan informasi yang diberikan oleh penulis resep mengenai berapa banyak tempat versi untuk mempertimbangkan rentang yang kompatibel. Paket memiliki batasan seperti >=3.7.2,<3.8.0a0, dengan kecanggungan 0a0 yang ada karena fakta bahwa versi prarilis berada di bawah rilis .0, dan dengan demikian akan cocok dengan spesifikasi <3.8.0 di mana orang tidak sangat mengharapkannya.

Paket juga memiliki saluran yang terkait dengannya. Saluran ini secara efektif merupakan bagian dari pengoptimalan versi: https://github.com/conda/conda/blob/4.6.7/conda/resolve.py#L1074 - saluran ini seperti versi super, satu tempat di depan versi utama paket. Jika pemecahan tidak harus mengubah python, maka spesifikasi python tidak boleh python ==3.7 - itu adalah rentang, dan saluran akan memengaruhi rentang itu. Secara khusus, memiliki spesifikasi python ==3.7 dan dimulai dengan instalasi dari saluran defaults , kemudian menambahkan saluran conda-forge akan menghasilkan banyak churn, karena Anda telah memperkenalkan paket python baru yang lebih tinggi di "versi" (termasuk saluran), dan spesifikasi python Anda mengizinkan perubahan itu.

Conda 4.7 memperkenalkan "pembekuan" spesifikasi yang jauh lebih agresif, dan saya cukup yakin bahwa perilaku itulah yang Anda cari. Itu cukup rumit. Ini bermuara pada hanya membekukan hal-hal yang tidak bertentangan dengan spesifikasi eksplisit Anda. Bagaimana Anda menentukan "konflik" adalah bagian yang sulit. Kami pikir lebih baik untuk tidak membekukan hal-hal yang akan mencegah pemecah memberi pengguna paket terbaru yang merupakan bagian dari grafik dependensi untuk paket itu. Pembekuan ini layak disebutkan karena dapat dilakukan berdasarkan spesifikasi untuk pip dengan cara yang tidak bisa dilakukan oleh conda. Saya pikir ini mungkin optimasi yang bagus untuk pemecah backtracking.

Juga: buat (simpan) sedapat mungkin diperbaiki. Itu hal yang menyenangkan dengan pip sekarang, jika kacau biasanya seseorang dapat melakukan cd site-packages && rm -rf troublesome_package (mungkin diikuti dengan menginstal ulang dengan --no-deps) dan semuanya berfungsi kembali. Orang-orang seperti conda, apt, dan teman-teman jauh lebih sulit untuk diperbaiki dengan cara itu.

Ya, ini sangat penting. Saya pikir pip telah melakukan pekerjaan yang baik dalam menjual barang-barang secara bijaksana sehingga lebih sulit untuk dipecahkan. Itu sangat bijaksana, dan conda belajar dari itu. Jika Anda akhirnya menggunakan kode yang dikompilasi, pastikan kode tersebut terhubung secara statis atau tidak mungkin pemuatan dinamis menyebabkan masalah.

(libsolv tangen: kembali ketika saya dulu bekerja untuk RH, saya meraih https://pypi.org/project/solv/ untuk menutup celah keamanan "pip install solv" di Fedora, karena proses pembuatan libsolv tidak menghasilkan sdist atau wheel arsip saat ini, apalagi mempublikasikannya ke PyPI. Senang mengobrol dengan siapa saja yang mungkin tertarik untuk membuat binding perpustakaan nyata dengan salinan bundel libsolv, daripada placeholder yang tidak berbahaya seperti sekarang)

Mengenai komentar "memilih keluar" saya, saya tidak bermaksud "kembali ke logika instalasi lama", maksud saya "memberikan opsi untuk melewati instalasi paket yang akan menyebabkan pelanggaran batasan, daripada gagal seluruh permintaan instalasi".

Yum/DNF menawarkan itu melalui opsi --skip-broken mereka (dalam DNF flag itu adalah alias untuk --setopt=strict=0 ), dan saya pikir resolver pip harus menawarkan opsi serupa.

@ncoghlan Ah benar. Itu masuk akal.

Opsi gaya "abaikan konflik versi pada paket ini"

Saya sudah menyebutkan bahwa kami akan melakukan itu, itulah sebabnya saya bingung dengan komentar Anda.

Kami berada di halaman yang sama saat itu. :)

@ncoghlan membalas timeline yang saya usulkan di distutils-sig dan mengatakan kedengarannya masuk akal.

@pradyunsg - nantikan pembaruan bulanan Anda berikutnya!

Saya meluangkan waktu untuk melihat ini lagi, dan mengajukan #7317.

Saya pikir kita hampir sampai di sana dengan abstraksi - berkat banyak pekerjaan pada interaksi indeks pip, resolusi ketergantungan + pemisahan logika build dan banyak pembersihan umum.

Saya baru saja menutup #7317. Sejauh yang saya tahu, resolusi ketergantungan sekarang dipisahkan (cukup) dari logika pembuatan metadata. Refactor logika build telah berkembang dengan baik dan tidak lagi menjadi penghalang untuk kemajuan lebih lanjut sekarang.

Kita sekarang dapat mulai bekerja untuk mengimplementasikan abstraksi [resolvelib] di pip, mengambil referensi dari [passa] dan resolver puisi jika sesuai. :)

@pradyunsg Saya berencana mengekstraksi resolver dasar (berdasarkan PubGrub) dari basis kode Puisi (lihat https://github.com/sdispater/poetry/tree/master/poetry/mixology). Sebagian besar dipisahkan dari sisa kode tetapi masih ada referensi ke bagian internal yang perlu saya abstraksi.

Jika Anda tertarik untuk membantu dengan itu, beri tahu saya. Idenya adalah untuk memiliki implementasi mandiri dari algoritma PubGrub yang dapat digunakan oleh pihak ketiga dan akan ditempatkan di https://pypi.org/project/mixology/ yang saat ini memegang kode resolver lama.

@sdispater Pasti! Saya tidak tahu apakah saya dapat membantu secara langsung (keterbatasan waktu) tetapi akan luar biasa jika Anda dapat memisahkan port PubGrub dari puisi lainnya!

Salah satu hal yang akan sangat bagus adalah memiliki lapisan abstraksi yang konsisten, sehingga pip, puisi, dan pipenv menggunakan abstraksi yang sama. Saat ini, kami memiliki zazo (milik saya), mixology (puisi) dan resolvelib (pipenv) -- semuanya mendefinisikan semacam lapisan abstraksi dan mereka sedikit berbeda tetapi (konyol!) serupa. Jika Anda terbuka untuk ini, beri tahu kami!

FYI, kami ( @wolfv , dan tim @QuantStack secara umum) telah menanggapi RfP untuk resolver ketergantungan pip.

Pendekatan yang diusulkan adalah untuk mengadopsi libsolv C library, dan memberikan kontribusi dukungan untuk format batasan versi pip ke libsolv. Kami akan mengekspos pustaka C melalui binding Python baru.

Libsolv adalah perpustakaan tangguh yang mendasari ekosistem RPM, dan karena itu sudah digunakan pada skala industri.

• Libsolv didistribusikan di bawah lisensi BSD-3-Clause.
• Libsolv mendukung beberapa paket dan format repositori, seperti rpm , deb ,
  haiku , conda , arch . Yang penting, berbagai format dan cara untuk mengekspresikan
  batasan ketergantungan menunjukkan bahwa itu adalah sistem yang dapat dipasang yang seharusnya dapat
  untuk mengakomodasi sintaks pip untuk batasan pada versi ketergantungan..
• Menggunakan libsolv alih-alih pemecah conda di pembungkus mamba tipis, kami
  mampu meningkatkan kinerja conda secara signifikan. (kelambatan conda dalam resolusi paket dengan saluran besar adalah motivasi utama kami untuk mengerjakan mamba).
• Ia bekerja lintas platform pada Windows, OS X dan Linux. ( @wolfv melakukan port windows libsolv)
• Ia melakukan pemecahan SAT penuh untuk menemukan kombinasi ketergantungan yang optimal dan jika tidak berhasil, ia mengembalikan petunjuk yang dapat ditindaklanjuti untuk resolusi konflik.

Pendekatan yang diusulkan adalah dengan mengadopsi perpustakaan libsolv C

Perlu ada fallback untuk platform yang tidak didukung libsolv (misalnya, dukungan AIX di pip sedang aktif dikerjakan, dan Anda tidak menyebutkan BSD). Jadi libsolv sebagai opsi kinerja jika tersedia masuk akal bagi saya, tetapi kami tidak benar-benar dalam posisi untuk hanya menggunakannya. (Apakah ada versi Python murni dari libsolve, yaitu sesuatu yang memberikan hasil yang sama, hanya lebih lambat?)

Juga, bagaimana get-pip.py bekerja? Apakah kita harus menyertakan binari untuk libsolv untuk semua platform yang memungkinkan? Sekali lagi, saya berasumsi tidak, kami akan menggunakan fallback python murni.

Tidak dapat menggunakan kode C eksternal telah lama mengganggu pip. Saya ingin melihat solusi yang bagus untuk itu, tetapi (a) saya tidak yakin ada satu (kependekan dari beberapa bentuk solusi bootstrap "mini-pip" yang memungkinkan kita untuk melakukan de-vendor sama sekali) dan (b) itu adalah pekerjaan yang cukup besar sehingga saya tidak suka resolver baru bergantung padanya.

Hai @pfmoore

Saya pikir dukungan platform tambahan seharusnya tidak terlalu sulit untuk dicapai karena libsolv adalah kode C yang cukup mudah. Saya cukup yakin bahwa tidak ada versi Python murni dari libsolv (yang saya mengerti adalah kelemahannya, tetapi juga tidak ada versi Python murni dari Python, atau lib standar Python, jadi dalam pikiran saya seharusnya tidak menjadi pemblokir).

Saya pikir untuk bootstrap, seseorang dapat memiliki pip Python murni yang menggunakan mekanisme penyelesaian saat ini, yang kemudian menginstal lib resolver yang diperlukan berdasarkan libsolv. Misalnya, seseorang dapat menyematkan paket yang tepat dari libsolv + pip-spesifik Python binding, dan menginstalnya dari boostrap-pip seperti yang Anda jelaskan. Kedengarannya benar-benar bisa dilakukan bagi saya, tetapi Anda mungkin tahu lebih baik apa yang akan terlibat ...

Saya pikir dukungan platform tambahan seharusnya tidak terlalu sulit untuk dicapai

Untuk lebih jelasnya, saya tidak tertarik pada platform yang lebih khusus, saya hanya berpikir kita harus sangat jelas jika kita memengaruhi platform apa yang didukung pip (yang saat ini pada dasarnya adalah "apa pun yang dapat menjalankan Python" ). Ada juga pertanyaan penerapan tentang bagaimana kami mengirimkan ekstensi C (karena pip saat ini dikirimkan sebagai roda "universal", dan itu penting untuk beberapa kasus penggunaan seperti get-pip.py )

Saya pikir untuk bootstrap, seseorang dapat memiliki pip Python murni yang menggunakan mekanisme penyelesaian saat ini

Saya telah berdebat di atas, dan saya akan mengulanginya di sini, saya tidak benar-benar ingin mempertahankan dua resolver di pip tanpa batas.

Tapi saya tidak ingin terlalu negatif tentang proposal - saya hanya ingin menandai beberapa alasan saat ini kami tidak mengizinkan dependensi pada ekstensi C, jika Anda tidak mengetahuinya.

Diskusi mungkin lebih cocok di tempat lain, dan mungkin benar-benar berlebihan ketika/jika lebih banyak detail terungkap, tetapi saya benar-benar ingin melepaskan pertanyaan saya sekarang.

Dari pemahaman saya, libsolv menggunakan pemecah SAT sepenuhnya untuk resolusi ketergantungan, dan membutuhkan memuat informasi ketergantungan terlebih dahulu sebelum mulai menyelesaikannya. Tetapi PyPI sampai sekarang menyimpan metadata ketergantungan per-paket. Bahkan jika Anda mengabaikan sifat ketergantungan runtime setup.py , akan sulit untuk secara efisien mengambil informasi yang diperlukan untuk pemecah SAT.

Bagaimana Anda berencana untuk menangani masalah ini? Apakah Anda berencana untuk mengimplementasikan infrastruktur (dan mengusulkan spesifikasi tambahan untuk implementasi repo pihak ketiga) untuk menghasilkan file .solv saat paket diunggah? Atau apakah Anda memiliki beberapa strategi untuk menghasilkan data yang dapat dipecahkan yang sesuai saat pemecahnya berjalan, dan mungkin menerapkan beberapa pelacakan mundur saat data ketergantungan baru masuk?

Saya tidak mengetahui adanya pekerjaan yang ada dalam hal ini, dan sebagian besar sumber daya yang dapat saya temukan menyarankan lanskap pengemasan Python membutuhkan sesuatu yang lain/lebih dari pemecah SAT langsung. Jadi saya sangat tertarik dengan kemungkinan apa pun di sini.

File .solv itu hanya untuk caching, libsolv tidak membutuhkannya untuk dipecahkan. Tetapi saya setuju bahwa sifat dinamis dari ketergantungan PyPI membuat sulit untuk menggunakan pemecah SAT.

(Lihat https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/edit untuk informasi lebih lanjut)

(Perhatikan bahwa pemecah SAT hanyalah pemecah backtracking yang juga melakukan pembelajaran klausa jika mengalami konflik, jadi saya pikir adalah mungkin untuk menggunakan pemecah SAT untuk PyPI. Tetapi perlu pemecah yang memungkinkan untuk menambahkan klausa secara dinamis sambil menyelesaikan.)

Sat solver memiliki beberapa kemampuan yang signifikan akhir-akhir ini termasuk penambahan dinamis, restart, backtracking, restart acak, dll. Tapi saya pikir tantangan di sini sebagian akan menjadi tantangan teknis yang terkait dengan kebutuhan untuk mendukung platform di mana tidak ada jaminan bahwa Anda dapat membangun pemecah berbasis C.

Saya di bandara sekarang jadi saya tidak bisa menanggapi poin yang telah diangkat sekarang tapi... Saya yakin kita tidak boleh membahas pilihan teknis/pengorbanan di sini -- ini lebih terbatas pada bagaimana kami berkomunikasi dan mengelola peluncuran vs apa yang kami luncurkan. :)

Saya mengajukan #7406 untuk diskusi lebih lanjut tentang pertukaran teknis -- @sdispater , @techalchemy , @uranusjr , @wolfv Saya akan menghargai jika kita dapat berdiskusi lebih lanjut seputar berbagai pilihan untuk desain resolver.

Untuk menetapkan harapan lebih awal, saya akan bepergian selama 2 minggu ke depan dan mudah-mudahan dapat mengikuti semua diskusi pada ~9 Desember.

Pembaruan status: PSF dapat memperoleh sejumlah dana dari Dukungan Sumber Terbuka Mozilla dan Inisiatif Chan Zuckerberg untuk menyewa kontraktor untuk mengerjakan pemecah pip dan masalah pengalaman pengguna terkait . Anda dapat melihat peta jalan kami (yang perlu saya perbaiki) dan posting blog dan forum dan milis dan catatan dari pertemuan terakhir untuk terus diberitahu. Saya akan segera memposting sesuatu tentang ini ke distutils-sig dan forum Pengemasan pada contoh Wacana Python .

Kami bertujuan untuk menyiapkan fitur resolver pip untuk rilis di pip 20.2 pada bulan Juli. (Sesuai irama rilis triwulanan untuk pip, kesulitan yang tidak terduga mungkin tertunda hingga 20,3 pada kuartal berikutnya.)

@uranusjr :

Dari pemahaman saya, libsolv menggunakan pemecah SAT sepenuhnya untuk resolusi ketergantungan, dan membutuhkan memuat informasi ketergantungan terlebih dahulu sebelum mulai menyelesaikannya. Tetapi PyPI sampai sekarang menyimpan metadata ketergantungan per-paket. Bahkan jika Anda mengabaikan sifat runtime-dependent setup.py, akan sulit untuk mengambil informasi yang diperlukan untuk pemecah SAT secara efisien.

Perintah prototipe pip resolve di #7819 menggunakan dua teknik untuk mendapatkan informasi ini dengan baik (lihat masalah itu untuk detailnya):

1. > Mengekstrak konten file METADATA dari url untuk roda tanpa benar-benar mengunduh roda sama sekali.
2. > Caching hasil setiap panggilan self._resolve_one() dalam file json persisten.

Teknik yang digunakan untuk (1) mampu mengonversi URL roda menjadi daftar string persyaratan yang bergantung padanya dengan sangat cepat, sambil mengunduh hanya beberapa KB dari konten roda itu sendiri. Prototipe di #7819 kemudian memastikan bahwa req.populate_link() dipanggil pada setiap persyaratan dependen yang dikembalikan oleh self._resolve_one() , dan menyimpan pemetaan (==Requirement, url) -> [list of (==Requirement, url) non-transitive dependencies] dalam file cache json persisten. (1) mendapatkan informasi baru dengan cepat, (2) membuat informasi lama cepat ditanyakan.

Meskipun saya belum terbiasa dengan libsolv, saya percaya bahwa entri pemetaan ini dari URL persyaratan ke dependensi dan URL-nya mungkin persis input atom yang diperlukan oleh pemecah SAT. Seperti yang ditunjukkan pada #7189, file cache dependensi json yang persisten menyebabkan pemanggilan pip resolve menjadi tanpa operasi total setelah dijalankan pertama kali, mengambil 800-900 md pada baris perintah sejak saat itu. Jika teknik dari (1) dan (2) digunakan, saya yakin mungkin untuk membiarkan pemecah SAT berjalan sampai selesai setiap kali pip dipanggil tanpa menunggu waktu yang sangat lama. Mungkin tidak akan terlalu sulit untuk mencoba meretas libsolv di atas prototipe di #7189 untuk membuat angka ini lebih konkret.

@teknikkimia :

Sat solver memiliki beberapa kemampuan yang signifikan akhir-akhir ini termasuk penambahan dinamis, restart, backtracking, restart acak, dll. Tapi saya pikir tantangan di sini sebagian akan menjadi tantangan teknis yang terkait dengan kebutuhan untuk mendukung platform di mana tidak ada jaminan bahwa Anda dapat membangun pemecah berbasis C.

celana dulu memiliki beberapa kode yang membuatnya lebih mudah untuk mengekspos kompiler dan tautan ke proyek berbasis setup.py (#6273), tetapi kami kemudian menghapus ini (lihat #7016) untuk memungkinkan pembuatan C/C++ di celana tanpa menggunakan setup.py , yang sesuai untuk kasus penggunaan kami di dalam Twitter yang hanya perlu membangun perpustakaan bersama untuk operator kustom TensorFlow . Kami menghosting binari bawaan untuk arsip GCC dan binutils yang ditautkan secara statis di s3 kami untuk OSX dan Linux (lihat https://github.com/pantsbuild/binary/) sehingga pengguna celana tidak perlu menginstal apa pun selain python dan JDK menggunakan celana sama sekali.

Saya akan tertarik untuk membantu melakukan brainstorming dan/atau mengembangkan semua jenis perkakas untuk membangun C dan C++ secara portabel yang memungkinkan pip bergantung secara andal pada libsolv pada semua platform yang didukung.

@cosmicexplorer

celana dulu memiliki beberapa kode yang membuatnya lebih mudah untuk mengekspos kompiler dan tautan ke proyek berbasis setup.py (#6273), tetapi kami kemudian menghapus ini (lihat #7016) untuk memungkinkan pembuatan C/C++ di celana tanpa menggunakan setup.py, yang sesuai untuk kasus penggunaan kami di dalam Twitter yang hanya perlu membangun perpustakaan bersama untuk operator kustom TensorFlow. Kami meng-host binari bawaan untuk arsip GCC dan binutils yang terhubung secara statis di s3 kami untuk OSX dan Linux (lihat pantsbuild/binari) sehingga pengguna celana tidak perlu menginstal apa pun selain python dan JDK untuk menggunakan celana sama sekali.

Pekerjaan compiler/linker sangat menarik! Ada juga diskusi tentang memisahkan kompiler dari setup.py (atau backend build PEP 517 secara umum). Ini tidak benar-benar terkait dengan resolver (setidaknya tidak secara langsung), tetapi Anda mungkin tertarik: https://discuss.python.org/t/how-do-we-get-out-of-the-business-of- driving-c-compilers/2591

@cosmicexplorer

Saya akan tertarik untuk membantu melakukan brainstorming dan/atau mengembangkan semua jenis perkakas untuk membangun C dan C++ secara portabel yang memungkinkan pip bergantung secara andal pada libsolv pada semua platform yang didukung.

Saya dan @wolfv telah melihat ini untuk membangun bagian dari tumpukan manajer paket DNF di semua platform utama yang didukung untuk mamba dan pekerjaan pribadi saya dengan DNF. Pada titik waktu ini, libsolv sekarang mampu dibangun untuk Windows, Linux, macOS, BSD, Haiku OS, dan saya samar-samar menyadarinya ditempatkan di berbagai sistem UNIX sebagai bagian dari penggunaan DNF di UNIX. Saya tahu @dralley juga telah membuat roda biner solv tersedia untuk ~platform utama yang didukung oleh PyPI~ Linux menggunakan manylinux2014 di PyPI .

Kami sekarang memiliki pip 20.1b1, rilis beta yang mencakup versi awal (alfa) dari resolver baru (lihat #8099 untuk konteksnya, dan survei di mana orang dapat memberikan umpan balik). Berikut pengumumannya . Dan https://github.com/pypa/pip/issues/7951#issuecomment -617851381 mencantumkan beberapa tempat yang telah kami publikasikan versi beta sejauh ini.

pip 20.1 sekarang keluar dan termasuk versi alpha dari resolver.

Kami sedang mendiskusikan penerbitan rilis pip lain pada bulan Mei, yang menyertakan alpha lebih jauh dari resolver. Dan kami sedang mencari tahu kapan harus merilis versi beta dari resolver baru dan melakukan push "tolong uji ini".

Kami mengalami penundaan saat kami mencari tahu #8371, cara menampilkan pesan kesalahan tertentu dengan lebih baik, dan menangani banyak hal berbulu lainnya; lihat https://github.com/pypa/pip/projects/6 dan https://github.com/pypa/pip/projects/5 untuk lebih lanjut tentang kemajuan kami. #8206 adalah diskusi tentang beta yang akan datang, pip 20.2b2, yang saya harap dapat kami publikasikan pada akhir Juni.

Saya telah memposting laporan tengah tahun kami di blog PSF . Satu hal penting yang perlu diketahui: akhir bulan ini kami akan merilis pip 20.2 yang akan memiliki versi beta dari resolver dependensi baru (pip 20.1 memiliki versi alfa) yang tersedia melalui flag opsional " --use-feature=2020-resolver ". Kami akan banyak mempublikasikan pip 20.2 dan meminta banyak pengguna untuk menempatkan resolver baru melalui langkahnya.

Per #8511 kami sekarang telah merilis pip 20.2 . Rilis ini mencakup beta dari resolver ketergantungan generasi berikutnya . Ini secara signifikan lebih ketat dan lebih konsisten ketika menerima instruksi yang tidak kompatibel, dan mengurangi dukungan untuk jenis file kendala tertentu, sehingga beberapa solusi dan alur kerja mungkin rusak. Silakan uji dengan flag --use-feature=2020-resolver . Silakan lihat panduan kami tentang cara menguji dan bermigrasi, dan cara melaporkan masalah . Penyelesai ketergantungan yang baru dinonaktifkan secara default karena belum siap untuk penggunaan sehari-hari .

Kami berencana untuk membuat rilis triwulanan pip berikutnya, 20.3, pada Oktober 2020. Kami sedang bersiap untuk mengubah perilaku resolusi ketergantungan default dan menjadikan resolver baru sebagai default di pip 20.3.

Tolong sebarkan berita dengan menunjuk ke posting blog ini -- sebarkan berita di Hacker News, Reddit, Twitter, Facebook, Dev.to, Telegram, jawaban Stack Overflow yang relevan, dan Slacks and Discords favorit Anda. Sebagian besar orang yang akan terpengaruh ini tidak mengikuti berita pengembang khusus Python. Bantu mereka mendapatkan informasi sebelum Oktober, dan bantu kami mendapatkan laporan bug mereka.

(Menyalin catatan saya dari #988.)

@zooba bertanya :

Apakah menurut Anda kami harus memperbarui versi pip yang dibundel dengan Python 3.9 pada tahap ini (untuk RC pertama)?

Demikian pula, apakah ada kebutuhan untuk memperbarui Python 3.8 untuk rilis berikutnya?

Asumsi saya, ya, setelah bugfix rilis awal minggu depan, ya, tapi @pfmoore @xavfernandez @cjerdonek @uranusjr @pradyunsg @dstufft bagaimana menurut Anda?

Maaf, posting terlalu cepat. Alasan saya adalah bahwa bundling pip 20.2 akan memudahkan pengembang berpengalaman untuk menguji resolver dependensi baru dengan mudah saat menguji versi terbaru Python. Tetapi saya tidak tahu seberapa banyak pekerjaan yang harus dilakukan untuk memperbarui versi yang dibundel itu, atau seberapa sering Anda ingin melakukannya.

Sama di sini, akan lebih baik untuk menyertakan 20.2.x dalam 3.9 untuk akses yang lebih mudah ke resolver baru.

Bagaimana menurut anda?

Anda benar, itu rencananya. :)

Oke, dijawab di python-dev -- ya, versi pip yang dibundel dalam Python 3.8 dan 3.9 harus diperbarui ke 20.2.x.

Secara terpisah, pada publisitas, saya akan mencatat di sini beberapa pekerjaan yang sedang berlangsung:

Selama ~6-8 minggu ke depan saya akan mendorong untuk mendapatkan publisitas luas sehingga pengguna mencoba menggunakan pip baru. Saya menduga bahwa masalahnya tidak akan terlalu banyak "paket individual ini tidak akan diinstal"; itu akan menjadi konflik tak terduga di antara paket-paket tertentu, mungkin tergantung pada lingkungan dan file kendala tertentu. Kami mencoba untuk mendapatkan beberapa umpan balik awal melalui survei sehingga kami kemudian dapat memperbaiki bug, menyiapkan pengujian yang lebih otomatis, dll., dan agar paket upstream tersebut dapat memperoleh informasi awal dan mengeluarkan paket tetap sebelum pip 20.3 (contoh : masalah TensorFlow/numpy/scipy di https://github.com/pypa/pip/issues/8076#issuecomment-666493069 ).

Tidak peduli berapa banyak upaya yang kami lakukan untuk ini, akan ada pengguna yang berurusan dengan inkonsistensi yang tersandung dengan 20.3, dan mereka akan frustrasi dan bingung dan terluka, dan itu akan menyebabkan beban dukungan bagi kami dan semua hulu mereka. Kami bertujuan untuk mengurangi ini dengan membuat pengguna menguji dan dengan mendapatkan perhatian upstream.

Jadi saya berencana untuk menghubungi dan memanfaatkan grup yang memperhatikan sudut spesifik domain mereka sendiri -- ilmuwan data, guru, artis, spesialis DevOps, dan seterusnya.

Saya berhipotesis bahwa salah satu cara untuk mendapatkan perhatian mereka adalah melalui paket spesifik yang mereka andalkan.

Kemarin saya melihat-lihat beberapa daftar paket yang banyak digunakan dan secara manual mengirim email ke beberapa orang dan membuat masalah pada beberapa repositori untuk menyarankan agar mereka meminta pengguna mereka untuk menguji dengan beta dari resolver baru, untuk mulai menggelindingkan bola dan mencoba beberapa kata-kata/pendekatan untuk mendapatkan lebih banyak publisitas dan pengujian. Ini menyebabkan kebingungan dalam setidaknya satu kasus -- lihat https://github.com/sqlalchemy/mako/issues/322#issuecomment-667546739 -- dan setelah rilis perbaikan bug 20.2 keluar, saya akan sedikit lebih sistematis dan lebih jelas tentang

• mengapa kami menjangkau
• yang telah kami pilih untuk dihubungi/kapan (menautkan ke strategi media publik akan membantu)
• mengapa kami tidak dapat menggunakan pengujian otomatis untuk menemukan masalah ini sendiri

Kami mendapat sedikit perhatian di Twitter ( 1 , 2 ) dan Reddit (ada yang mau menjawab pertanyaan tentang pendanaan PyPA ini ?).

@zooba menulis (tentang bundling):

Terima kasih. Sepertinya kita bisa melakukannya akhir minggu ini dan membuat rilis berikutnya. Harap beri tahu kami secepatnya jika ada sesuatu yang tidak ingin Anda lepaskan.

Saya menemukan --use-feature=2020-resolver bagi saya umumnya memperbaiki lebih banyak masalah daripada yang ditimbulkannya.

apakah sudah terlambat untuk menyarankan peluncuran awal melalui:

diusulkan 20.3 pseudocode

try:
    _2020_resolver()
except:
    legacy_resolver()

yang berarti setidaknya untuk proyek saya mereka semua akan lulus tanpa modifikasi

setelah itu, setelah resolver lama dinonaktifkan secara default, saya mungkin untuk sementara waktu memiliki beberapa proyek yang bekerja di bawah resolusi 2020 dan beberapa tidak di bawah resolver lama, saya ingin dapat menetapkan satu tanda untuk mengaktifkan fallback:

diusulkan 20.4 pseudocode

try:
    _2020_resolver()
except:
    if not use_legacy_resolver:
        raise
    legacy_resolver()

Kami berencana untuk meluncurkan 20,3 akhir bulan ini. Kami mengantisipasi bahwa ini akan membutuhkan banyak dukungan pengguna karena pengguna yang bingung mengajukan pertanyaan kepada kami.

@di telah mengajukan diri untuk membantu mengumpulkan beberapa sukarelawan untuk membantu dengan tanggapan pertama. Para sukarelawan ini akan menjawab pertanyaan dan membantu dengan beban dukungan pengguna setelah pip baru keluar -- di Twitter, StackOverflow, dan GitHub -- dan melaporkan bug nyata ke perhatian tim pengelola/kontributor.

Dustin, saya pikir Anda memiliki rencana kasar tentang bagaimana ini akan bekerja - maukah Anda mempostingnya di sini dan kemudian saya akan mendapatkan konsensus dari pengelola pip lainnya? Terima kasih.

Inilah rencana kasar saya:

• Mulai diskusi di discussion.python.org meminta dukungan
• Mengarahkan orang ke saluran Slack yang dapat berfungsi sebagai saluran komunikasi antara semua orang
• Mulai dokumen yang menguraikan beberapa FAQ dan tanggapan kami
• Sertakan pohon keputusan untuk masalah baru -> masalah yang diprioritaskan
• Bagikan ini dengan saluran setelah kami memiliki tanggal rilis yang diketahui
• Coba dan jadwalkan sukarelawan secara kasar untuk online & triaging pada hari-hari setelah rilis

Terima kasih, @di. Kami menunggu sampai besok untuk mendapatkan persetujuan dari pengelola lainnya. Dan kami bertujuan untuk merilis pip 20,3 pada hari Rabu atau Kamis, 28 atau 29 Okt.

@di Saya melihat bahwa rencana Anda disetujui. Tolong pergilah!

@di memberi tahu tentang kemungkinan penundaan dalam rilis .

Jika saya tidak tersedia ketika kami dapat menerbitkan 20.3 (yang kami harapkan minggu depan), inilah rencana publisitas .

Seperti yang saya diskusikan dalam komentar di tempat lain , kami memutuskan untuk menunda rilis sedikit, karena beberapa masalah CI muncul dan karena beberapa faktor eksternal.

Dalam pertemuan tim hari ini kami sepakat bahwa rilis 20.3 kemungkinan akan dilakukan besok atau Jumat. Anda dapat mengikuti #8936 untuk lebih lanjut.

Saya tidak melakukan penjangkauan per-paket sebanyak yang saya sarankan dalam komentar sebelumnya. Namun bukan berarti kami tidak melakukan sosialisasi. Beberapa sosialisasi yang telah kami lakukan (beberapa di antaranya dikatalogkan di #8511 atau halaman wiki ini ):

• Podcast: Podcast.__init__ , Tes & Kode , Mingguan FLOSS , Perjalanan Pengembang Perangkat Lunak , Python Nyata
• Kumpulan tweet
• Video YouTube singkat tentang perubahan
• Email ke sponsor PyCon, PSF, dan PyPI dari kontak sponsor PSF mereka, meminta mereka untuk memberi tahu departemen teknik mereka tentang perubahan yang akan datang
• Email ke pypi-umumkan dan daftar serupa
• Posting blog seperti ini
• Email ke teknologi sipil dan kelompok / think tank serupa

Selama beberapa bulan terakhir kami telah mendapatkan aliran masalah baru dari orang-orang yang menguji resolver baru di 20.2 dan 20.3 beta, pip 20.3b1 . Laporan tersebut telah membantu kami meningkatkan resolver, memperbaiki bug, dan meningkatkan UX dari outputnya. Kami juga telah meningkatkan secara substansial panduan pengguna "apa yang berubah" , sebagian sebagai tanggapan atas umpan balik beta.

Inilah rencana kasar saya:

* Start a discussion on discuss.python.org asking for support

* Direct folks to a Slack channel that could serve as a communication channel between everyone

* Start a document outlining some FAQ and our responses

* Include a decision tree for new issue -> triaged issue

* Share this with the channel once we have a known release date

* Try and roughly schedule volunteers to be online & triaging in the days following the release

@di Saya menyadari bahwa ketidakpastian dan penundaan yang konstan mungkin membuat Anda tidak dapat melakukan penjadwalan. Tanggal rilis baru adalah besok, Senin, 30 November. Jika Anda sekarang memiliki utas diskusi dan pohon keputusan untuk dibagikan, silakan dan bagikan!

pip 20.3 telah dirilis, dan memiliki resolver baru secara default! Berikut pengumuman rilis di blog PSF: https://blog.python.org/2020/11/pip-20-3-release-new-resolver.html