"upgrade" adalah alias sepele untuk "install --upgrade". Perlu berpikir sedikit lagi
tentang "upgrade-semua"; untuk satu hal, saya kira itu hanya akan meningkatkan paket
di dalam sys.prefix? (yaitu jika Anda berada di dalam virtualenv, itu tidak akan mencoba
meningkatkan paket global). Itu akan menjadi alasan untuk pindah
UninstallPathSet.can_uninstall() ke fungsi yang lebih umum bernama (atau
metode InstallRequirement), sehingga menyediakan generik "dapatkah saya menyentuh ini?"
keputusan.

Original Comment By: Carl Meyer

Sebagai catatan, saya pikir itu sepertinya ide yang bagus, mengingat kemampuan untuk
hapus instalan sebelum memutakhirkan. Meskipun saya lebih suka opsi --all untuk
upgrade alih-alih perintah upgrade-all .

Untuk masalah can_uninstall(), saya setuju.. ini mungkin berguna untuk dimiliki
secara global pula.

Original Comment By: Jannis Leidel

Saya tidak sepenuhnya menentang untuk memutakhirkan sebagai alias untuk menginstal --upgrade. Tetapi
sepertinya agak sepele.

upgrade-all mengharuskan Anda untuk mencari tahu apa yang "dapat diupgrade". Mungkin satu
prasyaratnya adalah ia tinggal di/lib/pythonX.Y/site-packages
(hanya di bawah sys.prefix tidak cukup).

Jika kami mengizinkan sesuatu seperti "impor zip" (untuk membawa paket dari induk
lingkungan ke dalam lingkungan virtualenv) maka mungkin paket dalam itu
lingkungan induk tidak boleh ditingkatkan, tetapi tidak 100% jelas itulah yang
akan diharapkan oleh pengguna.

Saya mencoba menghapus paket yang dapat diedit dengan "pip uninstall" dan itu cukup
cukup ditawarkan untuk menghapus .egg-link dan memperbarui easy-install.pth. Tetapi
tidak dapat memutakhirkan paket secara wajar, jadi can_uninstall agak
berbeda dari can_upgrade.

Original Comment By: Ian Bicking

Ya, Anda benar bahwa can_uninstall dan can_upgrade berbeda.

Saya akan berpikir jika kami memiliki "impor pip" kami masih tidak ingin memutakhirkan
paket global yang diimpor; tetapi (bersama dengan yang dapat diedit) mungkin bernilai "tidak
memutakhirkan" peringatan ini ke konsol.

Original Comment By: Carl Meyer

+1 untuk bug ini

Original Comment By: smyrman

Edisi #167 ditandai sebagai duplikat dari masalah ini.

Original Comment By: Carl Meyer

1

(echo pip; pip freeze | awk 'BEGIN{FS="=="}{print $1}') | xargs sudo pip

instal -U

Ini harus memutakhirkan memutakhirkan semua paket yang diinstal (termasuk pip itu sendiri). Jika
Anda menjalankannya di virtualenv Anda mungkin tidak perlu menggunakan Sudo.

Tentu saja memiliki risiko kegagalan yang tinggi -- jika memutakhirkan salah satu paket
gagal seluruh proses akan gagal (mirip dengan port upgrade outdated di
MacPort).

Original Comment By: Tomasz Elendt

+1 untuk peningkatan --semua

Mengapa saat ini semua fasilitas manajemen modul Python harus payah? Kenapa tidak
satu menyediakan upgrade sederhana + upgrade --all perintah?

Original Comment By: Anonymous

Saya tidak keberatan mencoba implementasi, tetapi pertama-tama beberapa pertanyaan.

Apakah konsensus umum bahwa perintah "upgrade" baru yang mendukung '--semua'
opsi ditambahkan ke pip?

Menjalankan pemutakhiran pip seharusnya hanya memengaruhi lingkungan tempat ia berjalan. Jika
jalankan dari virtualenv maka hanya paket lokal ke env itu yang akan ditingkatkan;
sama untuk non-virtualenv's

Original Comment By: Kelsey Hightower

Kelsey: dari bacaan saya tentang diskusi di atas, saya tidak melihat ada yang nyata
oposisi untuk itu. Saya pikir itu adalah tambahan yang bagus untuk dibuat. Kasus tepi utama adalah
pemasangan VCS yang dapat diedit - seperti yang disarankan Ian, saya pikir perintah "upgrade"
tidak boleh menyentuh itu. Mendefinisikan apa yang dimaksud dengan "upgrade" dalam konteks semua
kemungkinan yang dapat diedit (termasuk repo lokal yang diinstal dapat diedit yang tidak memiliki
Origin) hampir tidak mungkin, saya pikir, dan bahkan jika ada yang setengah jalan
definisi dapat disatukan, itu hanya akan meningkatkan pemeliharaan
beban backend VCS yang sudah rapuh. Tetapi untuk yang tidak dapat diedit -- gunakan
dia!

Original Comment By: Carl Meyer

Carl: Keren, saya akan memulai dan memperbarui tiket ini dengan hasilnya.

Original Comment By: Kelsey Hightower

Saat mengerjakan perintah pemutakhiran, pertanyaan berikut muncul:

• Metode apa yang harus mendukung peningkatan pip untuk menentukan paket mana yang akan
  meningkatkan? Haruskah kita mendukung file persyaratan?
• Bagaimana seharusnya pemutakhiran pip menangani paket yang belum diinstal?
  Haruskah kita menginstal paket yang hilang?

kasus penggunaan peningkatan pip dan cara menanganinya:

# pip upgrade some_installed_package

Try and locate a package that satisfies the requirement. If the

persyaratan tidak puas upgrade ke versi yang diminta. Ini termasuk
mengupgrade ke versi yang lebih lama.

# pip upgrade --all

Locate all installed packages (non-editables) and update them to a new

versi jika tersedia.

# pip upgrade some_other_package

Warning: some_other_package not installed, use pip install

beberapa_lain_paket.

Tujuan saya adalah menjaga agar perintah pemutakhiran benar-benar sederhana. Anda dapat meningkatkan
paket khusus yang tidak dapat diedit ke versi baru atau lebih lama; atau Anda dapat meningkatkan
semua paket yang tidak dapat diedit ke versi yang lebih baru.

Pikiran?

Original Comment By: Kelsey Hightower

Saya pikir "pip upgrade" harus menjadi alias yang tepat untuk "pip install --upgrade" as
itu bekerja sekarang. Itu menyiratkan bahwa ya, itu menginstal paket yang diminta jika mereka
tidak diinstal, dan ya, ia menerima file persyaratan dengan -r. Seharusnya dia
bisa dilakukan dengan hampir tidak ada kode baru.

Tingkatkan --semua akan memerlukan beberapa kode untuk menemukan daftar saat ini
menginstal paket yang dapat diupgrade; maka itu harus melewati daftar itu untuk menginstal
--upgrade, seperti di atas.

Original Comment By: Carl Meyer

Carl, terima kasih atas jawabannya. Saya telah cukup banyak mengambil jalan yang Anda miliki
dijelaskan. Nanti hari ini saya harus bisa memposting beberapa contoh lari.

Original Comment By: Kelsey Hightower

Sebagian besar kode sudah selesai, hanya tersisa sedikit polesan sebelum saya memposting kode
untuk diteliti kembali.

MELAKUKAN:

• tes
• File persyaratan filter; tambahkan yang tidak dapat diedit ke daftar paket ke
  meningkatkan.

Menjalankan pip menggunakan perintah upgrade

# pip upgrade --all

All packages up-to-date


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

All packages up-to-date


# pip upgrade PyYAML

Package updates available:

  PyYAML: N/A (installed) 3.09 (latest)

Downloading/unpacking PyYAML

  Downloading PyYAML-3.09.tar.gz (238Kb): 238Kb downloaded

....

Successfully installed PyYAML

Cleaning up...


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  PyYAML: 3.09 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

All packages up-to-date


# pip upgrade PyYAML==3.08

Downloading/unpacking PyYAML==3.08

....

Successfully installed PyYAML

Cleaning up...


# pip upgrade --all -v

Packages installed at latest version:

  pip: 0.8.2 (latest)

  distribute: 0.6.14 (latest)

  Python: 2.7.1 (latest)

  wsgiref: 0.1.2 (latest)

Package updates available:

  PyYAML: 3.08 (installed) 3.09 (latest)

Downloading/unpacking PyYAML

...

Successfully installed PyYAML

Cleaning up...

  Removing temporary dir /root/upgrade_env/build...

Original Comment By: Kelsey Hightower

Kumpulan pertanyaan terakhir (saya harap):

• Haruskah pemutakhiran pip mengurai file persyaratan dan menyaring
  dapat diedit? Bagaimana dengan persyaratan URL?

Untuk setiap item yang tidak dapat diedit dalam file persyaratan, saya ingin memeriksa
indeks untuk versi yang lebih baru. Untuk melakukan ini, saya perlu mengumpulkan
info paket dari setiap baris dalam file persyaratan.

Setiap tip dipersilakan (saat ini melihat pip.req.parse_requirements )

• Haruskah pemutakhiran pip mencari indeks untuk versi yang lebih baru untuk diinstal?
  (Inilah yang saya lakukan sekarang). Jika tidak, bagaimana perintah pemutakhiran menentukan
  jika ada peningkatan?

Saat ini saya hanya menambahkan paket ke daftar pemutakhiran ketika:

• Paket tidak diinstal
• Upgrade tersedia (versi yang lebih baru dari indeks), dan tidak eksplisit
  versi diminta
• Versi yang diminta berbeda dari yang diinstal (Versi ketinggalan
  cocok).
• Saya menunda file persyaratan ke perintah instal sampai saya memfilter
  keluar persyaratan yang tidak dapat diedit.

Original Comment By: Kelsey Hightower

Carl setelah membaca kembali posting Anda, sepertinya saya melakukan lebih dari apa yang ada
diperlukan. Saya akan mengunggah cabang saya sehingga Anda dapat melihatnya. Saya mungkin telah pergi
berlebihan dengan memeriksa PyPi untuk versi yang lebih baru.

Original Comment By: Kelsey Hightower

Carl setelah membaca kembali posting Anda, sepertinya saya melakukan lebih dari apa yang ada
diperlukan. Saya akan mengunggah cabang saya sehingga Anda dapat melihatnya. Saya mungkin telah pergi
berlebihan dengan memeriksa PyPi untuk versi yang lebih baru.

Original Comment By: Kelsey Hightower

Ya, sepertinya Anda melakukan lebih dari yang seharusnya dibutuhkan. Pemasangan pip
--upgrade sudah melakukan semua yang Anda diskusikan (memeriksa yang lebih baru
versi, dll); semua "peningkatan pip" seharusnya seperti passing dua baris
semuanya ke pip install --upgrade.

Satu-satunya kode nyata yang akan ditulis di sini adalah kode untuk "upgrade --all" untuk mendapatkan
daftar lengkap paket yang dapat diupgrade yang diinstal di lingkungan.

Original Comment By: Carl Meyer

Ya, aku tahu itu. Yah, aku belajar banyak. Meskipun tidak diperlukan untuk ini
tugas, saya suka kemampuan untuk menunjukkan apa yang diinstal dan tersedia selama
proses pemutakhiran (lihat uji coba di atas).

Saya akan memfaktorkan ulang dan membersihkan semuanya. Perubahan saat ini di garpu saya di
cabang perintah-upgrade.

https://bitbucket.org/khightower/pip/changeset/2bdc202b446c

Original Comment By: Kelsey Hightower

Saya telah menghapus perintah pemutakhiran sesuai saran Carl (saya pergi ke jauh
di tempat pertama). Tidak yakin saya suka hasilnya, tetapi itu memasang cermin--upgrade dalam fungsionalitas.

Tampaknya pip mencoba mengunduh dan menginstal ulang paket bahkan ketika
paket sudah terinstal dan up-to-date. Lebih buruk lagi dengan peningkatan--all , pip menginstal ulang semuanya termasuk pip itu sendiri. Apakah ini bagaimana pip?
upgrade harus bekerja? Jika demikian maka saya hampir selesai :)

Menjalankan perintah peningkatan pip

# pip upgrade Mako


Downloading/unpacking Mako

  Running setup.py egg_info for package Mako


    warning: no files found matching '*.jpg' under directory 'doc'

    warning: no files found matching '*.sty' under directory 'doc'

    warning: no files found matching 'autohandler' under directory 'doc'

    warning: no files found matching '*.xml' under directory 'examples'

    warning: no files found matching '*.mako' under directory 'examples'

    warning: no files found matching '*.dat' under directory 'test'

    warning: no files found matching 'ez_setup.py'

Downloading/unpacking MarkupSafe>=0.9.2 (from Mako)

  Running setup.py egg_info for package MarkupSafe


Installing collected packages: Mako, MarkupSafe

  Found existing installation: Mako 0.3.6

    Uninstalling Mako:

      Successfully uninstalled Mako

  Running setup.py install for Mako

    changing mode of build/scripts-2.7/mako-render from 644 to 755


    warning: no files found matching '*.jpg' under directory 'doc'

    warning: no files found matching '*.sty' under directory 'doc'

    warning: no files found matching 'autohandler' under directory 'doc'

    warning: no files found matching '*.xml' under directory 'examples'

    warning: no files found matching '*.mako' under directory 'examples'

    warning: no files found matching '*.dat' under directory 'test'

    warning: no files found matching 'ez_setup.py'

    changing mode of /root/upgrade_env/bin/mako-render to 755

  Found existing installation: MarkupSafe 0.11

    Uninstalling MarkupSafe:

      Successfully uninstalled MarkupSafe

  Running setup.py install for MarkupSafe


    building 'markupsafe._speedups' extension

    gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall

-Wstrict-prototypes -fPIC -I/opt/OpenPython-2.7.1/include/python2.7 -c
markupsafe/_speedups.c -o build/temp.linux-x86_64-2.7/markupsafe/_speedups.o

    gcc -pthread -shared

build/temp.linux-x86_64-2.7/markupsafe/_speedups.o -o
build/lib.linux-x86_64-2.7/markupsafe/_speedups.so

Successfully installed Mako MarkupSafe

Cleaning up...

Original Comment By: Kelsey Hightower

Kelsey - Ya, ada beberapa bug dengan install --upgrade; khususnya kamu
diidentifikasi #13 , yang mengunduh ulang dan menginstal ulang bahkan paket yang
sudah up-to-date. Solusinya adalah tidak melakukan sesuatu yang berbeda
dengan perintah upgrade baru, itu untuk memperbaiki bug di install --upgrade.

Dengan upgrade --all, tampaknya masuk akal bagi saya bahwa pip akan mengupgrade dirinya sendiri
juga, jika ada peningkatan yang tersedia. (Secara pribadi saya tidak akan pernah menggunakan peningkatan
--semua, jadi saya tidak tahu perilaku apa yang diinginkan orang yang akan menggunakannya darinya
di sini). Jelas sekali lagi akan berperilaku lebih baik jika # 13 diperbaiki.

Original Comment By: Carl Meyer

Terima kasih Carl, saya akan menyelesaikan ini dan mulai melihat # 13

Original Comment By: Kelsey Hightower

Jika ada yang punya waktu, harap tinjau cabang perintah pemutakhiran saya. Sementara itu
Saya akan mengerjakan unittests yang mencoba untuk tidak menduplikasi yang sudah ada untuk
instal perintah.

https://bitbucket.org/khightower/pip/src/fa7b2a6d2bf1/pip/commands/upgrade.py

Original Comment By: Kelsey Hightower

@vababiy : saya telah mencoba perintah pemutakhiran Anda, tetapi tampaknya tidak berfungsi dengan benar ... Jadi saya membuat perintah sendiri:

https://github.com/pypa/pip/pull/313
https://github.com/jedie/pip/commit/7a31d70dabe0e809184fe1b5280c5a7ccf420dd5

@jedie saya pikir Anda bermaksud mengarahkan komentar Anda di @khightower. @vbabiy memigrasikan komentarnya ke sini tetapi tidak menulis perintah pemutakhiran.

+1

@kelseyhightower Ada kemajuan?

+1

+1!

+1

+1

Harap berhenti mengomentari masalah ini hanya dengan "+1". Kami sadar bahwa fitur ini diinginkan, mengirim spam ke kotak masuk kami tidak membantu.

Sebaliknya saya akan senang melihat komentar "tambalan selesai!" ;)

+1

Ada Pembaruan? Apakah ada rencana untuk menambahkan ini, ini sudah 3 tahun sekarang..

@pradyun Lihat https://github.com/pypa/pip/issues/59#issuecomment -9418336

+1

Saya pikir ini sudah digabungkan. Saya dapat membersihkan keterampilan python saya dan mencobanya lagi.

Apakah fitur ini akan disertakan dalam 1.5? Tidak dapat menemukan referensi apa pun di dokumentasi 1.5 ...

+1

Apa status masalah ini?

Itu diblokir oleh #988

Jika benar-benar penting bagi Anda, ada solusi untuk memutakhirkan semua paket; Saya menyusun skrip untuk melakukannya secara paralel (https://github.com/ariccio/update-pip-packages), dan ada banyak implementasi lain di tempat lain di internet.

Ada dua bagian untuk masalah ini. upgrade-all mungkin diblokir oleh gh-988, tapi saya tidak melihat bagaimana upgrade diblokir. pip upgrade bisa menjadi alias sederhana untuk pip install -U --no-deps . Ini akan menyelesaikan salah satu masalah utama menggunakan install_requires dalam file setup.py. Tidak bisakah ini dilakukan dalam waktu dekat?

pip upgrade bisa menjadi alias sederhana untuk pip install -U --no-deps

dari deskripsi:

pip upgrade akan seperti pip install --upgrade kecuali itu akan menjadi non-rekursif secara default (dan menawarkan opsi --recursive ). Perilaku default rekursif saat ini telah menyebabkan kesedihan bagi banyak orang (#304). Adapun cara melakukan upgrade non-rekursif sekarang, lihat di sini

itu bukan pip install -U --no-deps

"non-rekursif" dalam konteks ini tidak hanya berarti –no-deps . Pemutakhiran non-rekursif akan meningkatkan dependensi, tetapi hanya jika diperlukan untuk memenuhi persyaratan induk.

@qwcode terima kasih atas klarifikasinya. Maka bukan itu yang saya pedulikan. Mengapa Anda menyebut ini "non-rekursif", itu masih rekursif tetapi hanya sedikit lebih pintar/berbeda?

Saya mendapat kesan dari diskusi di gh-571 bahwa benar-benar non-rekursif adalah default yang diinginkan. Itu tentu masuk akal, dan mencegah keharusan untuk selalu menulis kode seperti https://github.com/scipy/scipy/commit/8e7ee0c4b3c16.

di #571, "non-rekursif" bukan --no-deps ini adalah rekursif "lebih pintar/berbeda" seperti yang Anda katakan.
perhatikan tes test_upgrade_with_needed_recursive_upgrades() dari PR itu.

tanpa terjebak pada istilah, ada 3 hal:

1. "upgrade yang lebih cerdas/berbeda", yaitu jenis yang terjadi dalam pengemasan OS yang juga dapat menyiratkan peningkatan dependensi (tetapi hanya jika mereka benar-benar _memerlukan_ peningkatan).
2. apa yang pip lakukan sekarang, yaitu memutakhirkan semua dependensi, terlepas dari kebutuhan atau resolusi konflik.
3. --no-deps

beberapa cara yang mungkin untuk membedakan #1 dan #2

1. "non-rekursif" vs "rekursif"
2. "normal" vs "rekursif"
3. "hanya jika diperlukan rekursif" vs "lakukan tanpa rekursif"

Saya terbuka untuk menggunakan istilah terbaik... hanya tidak yakin apa itu.

Saya pikir saya menyukai frasa "rekursif hanya jika diperlukan" ini. mungkin saya harus menggunakannya di sini di dokumen:

Aku juga menyukainya. Jika Anda menggambarkan ketiga opsi bersama-sama sebagai

a. non-recursive
b. only if needed recursive
c. recursive (or "do it regardless recursive")

itu akan menjadi jelas.

Maka Anda ingin memilih default yang bagus. Untuk upgrade dan install -U , baik (a) atau (b) bisa masuk akal. Saya sangat suka (a), tetapi (b) juga masuk akal mengingat itulah yang dilakukan pengemasan OS.

(c) tidak masuk akal sebagai default, jadi harap pertimbangkan kembali keputusan Anda untuk tidak mengubah install -U .

Untuk memperjelas mengapa saya sangat menyukai (a): pengguna yang tidak curiga menginginkan (b) dan mendapatkan (a) harus membaca pesan yang mengatakan "non-recursive upgrade can't satisfy all dependencies, please use only-if-needed recursive" , yang bukan masalah besar. Jika defaultnya adalah (b), pengguna yang tidak curiga itu mungkin akan berakhir dengan peningkatan atau bahkan instalasi paket yang rusak yang sebenarnya tidak ingin dia sentuh. Itu bisa memakan waktu berjam-jam atau bahkan berhari-hari untuk pulih.

(c) tidak masuk akal sebagai default, jadi harap pertimbangkan kembali keputusan Anda untuk tidak mengubah install -U

alasan untuk meninggalkan install -U saja hanya untuk alasan kompatibilitas, dan kemudian akhirnya tidak digunakan lagi.

Jika defaultnya adalah (b), pengguna yang tidak curiga itu mungkin akan mendapatkan peningkatan
atau bahkan instalasi paket yang rusak yang sebenarnya tidak ingin dia sentuh

jika pengguna ingin peningkatan ketergantungan yang diperlukan tidak terpenuhi, mereka harus secara khusus memintanya menggunakan --no-deps . tidak ada cara dalam pikiran saya yang bisa menjadi default. perilaku itu akan lebih merusak daripada yang Anda pertimbangkan (yang merupakan kasus outlier). Berulang kali, pengguna akan dibiarkan tidak memiliki peningkatan ketergantungan yang mereka butuhkan.

Menghentikan install -U terdengar bagus.

Saya setuju (b) lebih umum daripada (a). Bahkan jika itu 100x lebih umum, yang menurut saya tidak demikian, lebih banyak kerusakan tidak benar. Membaca pesan kesalahan yang jelas sebelum penginstalan dimulai jauh lebih baik daripada misalnya kesalahan kompilasi di tengah jalan, yang imho (a) masih merupakan default yang lebih baik.

Mengandalkan --no-deps mungkin baik untuk pengguna yang sangat berpengalaman, tetapi pengguna baru hanya akan mempelajarinya setelah terjadi kesalahan.

Lagi pula, sepertinya aku tidak akan bisa meyakinkanmu. Kemudian kembali ke manual

try:
   import dependency
except ImportError:
    install_requires.append('dependency')
else:
    if dependency.version < 'x.y.z':
        raise ValueError('Please upgrade dependency to x.y.z')

ini.

@qwcode terima kasih atas penjelasan detailnya. Saya harap ini akan bergerak maju dalam waktu dekat - hanya jika diperlukan rekursif akan menjadi peningkatan besar atas perilaku saat ini.

Menghabiskan berjam-jam lagi minggu ini untuk mengatasi masalah tentang mengapa kita tidak menggunakan install_requires , saya menambahkan :+1: untuk menjauh dari perilaku saat ini.

Apakah ada pembaruan tentang masalah ini?

Kami sekarang memiliki 2015 dan saya masih perlu menyalin dari pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U stackoverflow

Ya, pada dasarnya semua kemajuan terkait dengan masalah ini.

GitHub melakukan pekerjaan referensi silang yang cukup baik. Semuanya bisa diklik! (Saya yakin Anda tahu ini?)

Ya tentu saja, tetapi saya tidak mengerti alasan mengapa fitur "sederhana" ini mengalami penundaan.

Apa alasannya?

Am 16.04.2015 um 05:28 schrieb Alexander Riccio [email protected] :

Ya, pada dasarnya semua kemajuan terkait dengan masalah ini.

GitHub melakukan pekerjaan referensi silang yang cukup baik. Semuanya bisa diklik! (Saya yakin Anda tahu ini?)

—
Balas email ini secara langsung atau lihat di GitHub.

untuk pip upgrade-all , konsensus tampaknya menunggu pekerjaan yang terkait dengan #988 sebelum merilis perintah baru yang mengkilap yang pada akhirnya masih cacat dan dapat berbahaya bagi lingkungan kerja. Versi sederhana upgrade-all yang tidak menyelesaikan persyaratan dengan benar dapat dengan mudah merusak paket yang ada

+1

Apa yang kamu lakukan selama 4 tahun?

+1

+1

+1

@muhasturk Saat ini, menunggu... https://github.com/pypa/pip/issues/59#issuecomment -93646462

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 ...maaf untuk spamnya, tetapi menjalankan pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U menyakitkan!

+1

Jika ada yang tertarik untuk mengerjakan ini, saya pikir komentar di atas agak membingungkan -- AFAICT status sebenarnya adalah pip upgrade-all saat ini diblokir oleh kebutuhan akan sistem resolusi ketergantungan yang tepat, tetapi pip upgrade dapat diimplementasikan kapan saja. Jika seseorang ingin mengerjakan bagian itu maka itu akan sangat luar biasa :-).

(Lihat juga utas yang dimulai di sini dan balasan @dstufft di sini dan komentar di sini setuju dengan penilaian di atas.)

inilah diskusi lain dari daftar pypa-dev dari setahun yang lalu (yang setuju bahwa pip upgrade FOO dapat dilakukan sekarang) https://groups.google.com/forum/#!searchin/pypa -dev/pip$20 tingkatkan/pypa-dev/vVLmo1PevTg/oBkHCPBLb9YJ

Terima kasih @qwcode! Saya juga baru saja melihat deskripsi baru di https://pip.pypa.io/en/latest/user_guide/#only -if-needed-recursive-upgrade, itu membantu.

+1

Jika aku tidak salah:

Jika xxx tidak diinstal:

• pip upgrade xxx akan setara dengan pip install xxx
• pip upgrade xxx --recursive akan sama dengan pip install xxx --upgrade

Jika xxx diinstal:

• pip upgrade xxx --recursive masih akan setara dengan pip install xxx --upgrade (berdasarkan desain)
• tetapi saat ini tidak ada padanan untuk pip upgrade xxx , ini bisa jadi pip install xxx --upgrade-only-if-needed/--upgrade-lazy

Tidak jelas apa nilai tambah dari perintah baru selain menambahkan opsi baru ke pip install ?

Tidak jelas apa nilai tambah dari perintah baru selain menambahkan opsi baru ke pip install ?

Perilaku default pip install -U tidak dapat diterima untuk banyak proyek. Lihat komentar saya di atas (https://github.com/pypa/pip/issues/59#issuecomment-52434862). Dan inilah penjelasan yang lebih panjang: http://article.gmane.org/gmane.comp.python.distutils.devel/24218

Jika tidak dapat diterima, maka saya kira Anda berencana untuk mengubah penggunaan pip install --upgrade ke pip upgrade ?
Mengapa Anda tidak dapat mengubah penggunaan pip install --upgrade saat ini menjadi pip install --upgrade-only-needed ?
Apa yang diberikan perintah baru yang tidak bisa diberikan oleh opsi baru?

Ini semua membuka jalan sapi. Bukan penggunaan pribadi @rgommers yang dia khawatirkan, ini penggunanya. Orang-orang akan mencari jawaban "jelas" jika mereka tidak tahu lebih baik dan saat ini jawaban yang jelas bermasalah untuk beberapa bagian utama ekosistem Python.

Memang. Orang tidak membaca dokumen. Memang kami akan memperbaiki semua dokumen penginstalan yang dapat kami temukan, tetapi segera setelah pengguna melihat -U atau --upgrade itulah yang akan dia gunakan. Kemungkinan orang akan menggunakan --no-deps atau --only-as-needed atau apa pun sebelum mereka digigit secara serius sangatlah kecil.

Mengapa Anda tidak dapat mengubah penggunaan pip install --upgrade saat ini menjadi pip install --upgrade-only-needed ?

Dan untuk lebih jelasnya: kita menghindari pip install --upgrade sekarang _dan_ jangan gunakan install_requires karena ini. Begitulah buruknya.

Saya pikir ada kesalahpahaman kecil di sini -- IIUC @xavfernandez setuju dengan menambahkan fungsionalitas pemutakhiran non-rekursif, pertanyaan mereka adalah mengapa UI ke fungsi itu harus sebagai perintah tingkat atas baru alih-alih opsi baru ke pip install .

@xavfernandez : Perhatikan bahwa saat ini ada diskusi yang terjadi di #3194 tentang apa yang akan menjadi UI paling jelas untuk fungsi ini.

(Dan pip install -U akan ditinggalkan dan kemudian dihapus, sehingga menjawab pertanyaan tentang bagaimana pengguna akan tahu untuk tidak menggunakannya :-).)

Saya pikir ada kesalahpahaman kecil di sini

Saya cukup yakin tidak ada. Dan ya, kami hanya memperdebatkan UI. Tapi itu penting.

Yup hanya memperdebatkan UI dan saya setuju itu penting. Tapi apa yang saya lihat akan datang adalah begitu upgrade pip keluar, tidak akan ada alasan untuk tetap menggunakan pip install...
Dan UI untuk menginstal paket apa pun akan menjadi "pip upgrade foo"

tidak akan ada alasan untuk tetap menggunakan pip install

yang bermasalah kenapa? Masalah (setidaknya untuk @qwcode dalam komentar di atas) dengan mengubah pip install --upgrade ke perilaku yang benar melanggar kompatibilitas mundur. Jadi pip upgrade adalah cara untuk menghindari break _and_ mendapatkan default yang tepat.

@rgommers : untuk bersikap adil, kami _will_ mendapatkan beberapa pertanyaan membingungkan yang tidak nol tentang mengapa Anda menyuruh saya menjalankan pip upgrade foo ketika saya bahkan tidak menginstal foo , itu tidak 't work (berdebat bolak-balik sampai mereka benar-benar mencoba menjalankan perintah alih-alih berasumsi bahwa itu tidak akan berhasil dan berpura-pura bahwa mereka menjalankannya)

Pada #3194 saya berkomentar bahwa mungkin cara yang tepat adalah dengan menghapus --upgrade dari pip install , membuat pip install selalu melakukan pemutakhiran item yang disebutkan secara eksplisit, dan default ke strategi pemutakhiran minimal untuk dependensi dengan tanda --recursive untuk mendapatkan perilaku saat ini pada pemutakhiran.

Saya pikir saya setuju bahwa saya merasa dengan #3194 UX default akan menjadi pip upgrade foo bukannya pip install [-U] foo . Satu-satunya masalah yang saya miliki dengan itu adalah saya pikir agak membingungkan untuk memiliki dua perintah dan mengingat bahwa saya pikir pip upgrade akan menjadi yang "benar" untuk digunakan orang, saya pikir itu payah untuk memiliki yang jelas nama menjadi nama yang salah.

Saya menderita migrain jadi saya juga tidak bisa berpikir sepenuhnya benar, tetapi saya merasa seperti mencari cara untuk menangani jalur penghentian ke saran itu mungkin cara yang benar ke depan.

Yah, saya tidak akan berargumen bahwa kompatibilitas mundur itu penting di sini. Saya selalu mendukung perubahan perilaku pip install --upgrade . Ini adalah yang terbersih, dan biayanya tampak kecil. Tapi bagi saya sepertinya diveto oleh @qwcode , jadi pip upgrade adalah hal terbaik berikutnya (dan sudah disetujui oleh pip devs setahun yang lalu).

Jika sekarang kita ingin kembali mengubah default/perilaku untuk pip install , bagus.

@dstufft yang sangat masuk akal bagi saya - sakit kepala tidak mungkin seburuk itu :)

Karena kami setuju untuk tidak menggunakan --upgrade, kami dapat menyimpannya dan menambahkan dua opsi ke pip install: --upgrade-only-needed dan --upgrade-eager , yang kedua adalah alias untuk --upgrade yang sudah usang

@xavfernandez Memaksa keputusan ke pengguna agak payah menurut saya. Kecuali saya memahami masalah yang cukup halus, saya tidak yakin bahwa saya akan benar-benar tahu apakah saya menginginkan --upgrade-only-needed dan --upgrade-eager .

@xavfernandez jadi Anda mengusulkan bahwa dalam situasi terakhir perintahnya adalah pip install --upgrade-only-needed ? Sepertinya jelek.

Akan jauh lebih baik untuk memiliki sesuatu yang memetakan setara dengan versi semantik yang tersedia di misalnya npm , hex , atau Cargo . Itu tentu membutuhkan penyesuaian dalam konteks Python, karena (a) versi PEP 440 tidak dan tidak dapat memetakan secara tepat ke versi semantik dan (b) komunitas Python pada umumnya tidak selalu menggunakan versi seperti semantik dalam rilisnya bahkan dalam PP 440.

Meskipun demikian, sesuatu di sepanjang garis itu akan sangat membantu, seperti halnya gagasan menyematkan versi tertentu.

Mengingat kendala, dalam jangka pendek satu opsi yang layak mungkin melakukan sesuatu yang analog dengan perintah upgrade dan upgrade --all homebrew, di mana yang terakhir hanya melanjutkan dengan memutakhirkan semuanya (berpotensi dengan peringatan pertama kali ).

Namun, dalam jangka panjang, akan sangat berguna untuk membuat konvensi bersama tentang arti versi dalam komunitas pengemasan Python, dan membangun dukungan pip sekitar itu bisa menjadi bagian besar darinya.

Jalur migrasi yang jelas adalah:

pip versi X:

• add options pip install --eager , pip install --no-eager , di mana --eager berarti bahwa untuk persyaratan tanpa batasan versi terlampir, kami mencoba menginstal versi terbaru meskipun sudah ada beberapa versi yang diinstal, dan --no-eager berarti kami puas jika ada versi yang diinstal
• juga tambahkan opsi pip install --eager-recursive dengan semantik -U
• --no-eager tetap default
• jika tidak satu pun dari opsi ini ditentukan, dan pip install melewati persyaratan tanpa nomor versi terlampir, dan persyaratan ini sudah dipenuhi, maka keluarkan peringatan yang mengatakan bahwa kami tidak memutakhirkan paket Anda, tetapi di masa mendatang kami akan melakukannya, jadi Anda harus menggunakan --no-eager jika Anda ingin mempertahankan perilaku saat ini
• tambahkan peringatan penghentian ke pip install -U merujuk orang ke pip install --eager-recursive

pip versi Y:

• alihkan default untuk pip install ke --eager

pip versi Z:

• hapus pip install -U

Saya membuat Y dan Z versi yang berbeda karena saya menginginkan --eager jadi mungkin kita bisa membuat perubahan itu pada jadwal yang lebih agresif, sambil mempertahankan pip install -U sebentar karena banyak dokumentasi sudah merujuk untuk itu, dan itu tidak menyebabkan kerusakan apa pun. Tapi jelas Y = Z adalah pilihan :-)

@chriskrycho : Itu semua terdengar seperti hal yang bagus untuk dimiliki, tetapi diskusi ini adalah tentang bagaimana menangani situasi di mana pengguna secara eksplisit mencoba meminta peningkatan ke versi terbaru dari sebuah paket, yang merupakan situasi yang biasa terjadi hari ini dan kami tidak memiliki jawaban yang baik. Saya tidak tahu apakah ada bug terbuka yang meminta dukungan penyematan, tetapi jika tidak, mungkin Anda harus memulainya?

Sangat; poin saya (yang sekarang saya akui saya benar-benar gagal untuk membuatnya eksplisit!) adalah hanya untuk mencatat bahwa solusi apa pun yang diadopsi di sini tidak boleh bertentangan dengan mengambil taktik semacam itu di masa depan.

Apa jalur penghentian normal untuk pip? Berbasis waktu/versi? Berapa lama sesuatu harus ditinggalkan sebelum dihapus?

Omong-omong, saya pikir "bersemangat" adalah kata yang tidak akan dipahami pengguna. rekursif / hanya sesuai kebutuhan rekursif / selalu rekursif jauh lebih jelas.

Kami biasanya melakukan siklus penghentian dua versi.

Versi utama saya berasumsi? Versi minor sangat cepat (7.0 -> 7.1 adalah satu bulan). Biasanya setengah tahun antara versi utama, jadi 1 tahun peringatan penghentian?

Ya, maaf. Versi utama. Jika kita menghentikan sesuatu di 8.x itu akan menjadi peringatan kuning untuk sisa 8.x, peringatan merah untuk semua 9.x, dan dihapus di 10.x.

Terima kasih.

Menyalin komentar @dstufft 's dari https://github.com/pypa/pip/pull/3194#issuecomment -152.357.835 sini, karena itu ringkasan terbaik dari situasi:

Saya kira tl; dr adalah bahwa saya benar-benar berpikir bahwa kita perlu memperbaiki perilaku "default", kita hanya perlu menyelesaikan implementasi spesifik untuk memperbaikinya:

1. Pertahankan UX menjadi pip install --upgrade dan ubah default.
2. Pindahkan UX ke pemutakhiran pip dengan default "benar" dan tambahkan tanda --recursive.
3. Pindahkan UX ke pip install, hapus --upgrade, dan tambahkan flag --recursive.

2c saya:

(1) memiliki UX yang bagus, dapat dilakukan sekarang
(2) UX yang sedikit lebih buruk (memiliki install dan upgrade ), dapat dilakukan sekarang
(3) UX terbaik kedua, mengubah pip install dapat dilakukan sekarang, menghapus --upgrade hanya akan dilakukan di 10.0 (tidak digunakan lagi di 8.0 dan 9.0).

Saya tidak mengerti mengapa masalah kompatibilitas mundur (yang seharusnya kecil) untuk (1) akan lebih buruk daripada untuk (3). Jadi (1) tampaknya yang terbaik. Jika bw compat benar-benar mengkhawatirkan, maka pilih (2).

Bagaimanapun, waktu untuk menyebutnya malam.

Saya pikir perbedaan antara (3) dan (1) bermuara pada apakah kita berpikir bahwa install-atau-upgrade adalah operasi paling umum yang diinginkan orang -- jika demikian maka menjadikannya perintah singkat seperti pada (3) mungkin adalah yang terbaik. Ini bukan masalah besar.

Omong-omong, saya pikir "bersemangat" adalah kata yang tidak akan dipahami pengguna. rekursif / hanya sesuai kebutuhan rekursif / selalu rekursif jauh lebih jelas.

Saya sama sekali tidak terikat pada ejaan "bersemangat", tetapi rekursif tidak masuk akal sebagai kata utama untuk mengaktifkan dan menonaktifkan peningkatan. Saya kira kita bisa menggunakan --upgrade-non-recursive (default masa depan), --upgrade-recursive , --upgrade-none atau lebih, tetapi itu masih mendahului perilaku rekursif yang membingungkan (saya tidak tahu apa --upgrade-non-recursive berarti jika saya belum terbiasa dengan perilaku rekursif aneh dari opsi legacy -U), dan --upgrade-none terdengar menyesatkan seperti itu akan memastikan bahwa tidak ada paket yang ditingkatkan bahkan jika diperlukan untuk mempertahankan self- konsistensi.

Jika kita mengikuti rute ini maka saya tidak terlalu peduli dengan periode ejaan, karena opsi yang diinginkan kebanyakan orang hanya akan menjadi default dan opsi peningkatan rekursif dan tanpa peningkatan keduanya akan menjadi hal-hal khusus yang jarang digunakan yang kebanyakan pengguna bisa mengabaikan.

--upgrade-non-recursive (default di masa mendatang) ...

tentu itu membingungkan. tetapi Anda mengabaikan opsi paling sederhana, yaitu tidak menyediakan sakelar ini sama sekali. karena jika identik dengan perilaku default, mengapa Anda membutuhkannya?

Saya pikir perbedaan antara (3) dan (1) bermuara pada apakah kami berpikir bahwa instal-atau-upgrade adalah operasi paling umum yang diinginkan orang

Saya harapkan "instal". Setidaknya saya tahu bahwa saya hanya memutakhirkan paket yang sering saya gunakan dengan sengaja, tetapi setiap kali saya melihat sesuatu yang menarik/berguna itu hanya berjarak pip install pkgname .

(bukannya saya pengguna biasa, jadi harapan saya bisa salah)

Saya pikir saya akan mendukung:

• Tidak ada pip upgrade yang akan menjadi alias untuk pip install
• pip install (tanpa opsi --upgrade* ) perilaku tidak berubah
• pip install --some_name hanya akan mencoba memutakhirkan paket yang ditentukan pada baris perintah dan bukan dependensinya
• pip install --some_other_name untuk menjaga perilaku --upgrade tersedia

Dan kemudian ada dua opsi:

• kita tidak membutuhkan/menginginkan jalur penghentian, maka --some_name dapat menjadi --upgrade dan --some_other_name dapat menjadi apa pun yang tampak terbaik
• kita membutuhkan jalur penghentian, kemudian --upgrade di pip8 akan memberikan peringatan yang mengatakan itu sudah usang dan kita harus menggunakan --some_other_name untuk mempertahankan perilaku lama atau lebih tepatnya beralih ke --some_name untuk hanya memutakhirkan paket yang ditentukan dan dependensinya hanya jika diperlukan.

Dalam kasus kedua ini, --some_name tidak boleh --upgrade . Jadi kita harus menemukan dua nama opsi baru untuk --some_name dan --some_other_name

Tampaknya bagi saya bahwa solusi "terbaik" yang jelas adalah mempertahankan pip install sebagai perintah, dan mengubah perilaku --upgrade untuk tidak memutakhirkan dependensi. Satu-satunya masalah sebenarnya adalah kompatibilitas ke belakang, tetapi apakah kami memiliki _setiap_ pengguna yang berargumen bahwa mereka bergantung pada perilaku saat ini?

Secara pribadi, saya cenderung ke tampilan "lakukan saja, dan persetan dengan kompatibilitas mundur". Saya dapat berargumen bahwa perilaku saat ini sebenarnya adalah bug, dan perubahan ini akan menjadi perbaikan bug. Tetapi saya pikir bahwa pada titik tertentu kita harus dapat mengatakan bahwa kita telah mencapai titik yang baik, dan kita akan mengambil pandangan yang lebih ketat tentang kompatibilitas ke belakang. Saya rasa kita belum sampai pada titik itu, tetapi kita mungkin perlu mulai memberi tahu komunitas apa yang kita rasa masih perlu dilakukan untuk mencapai titik itu.

Masih (IMO) kebutuhan akan semacam perintah pip install --upgrade :all: untuk meningkatkan semua paket yang diinstal. Tapi itu fungsi baru, jadi tidak relevan di sini.

Perilaku saat ini _is_ berguna, terutama untuk proyek seperti Piramida yang bukan merupakan proyek tunggal tetapi sebenarnya merupakan kumpulan proyek. Akan berguna untuk dapat melakukan sesuatu seperti pip install --upgrade-recursive Pyramid untuk meningkatkan Pyramid dan semua dependensinya ke versi terbaru. Menghapus hal rekursif bersama-sama berarti saya harus melacak semua dependensi secara manual dan melakukan pip install --upgrade Pyramid dep1 dep2 dep3 dep4 (dengan seluruh pohon dependensi) atau saya perlu melakukan pip install --upgrade :all: hipotetis dan mungkin memutakhirkan lebih banyak hal-hal dari saya benar-benar ingin meng-upgrade. Di #3194 setidaknya satu pengguna menyebutkan bahwa mereka ingin perilaku saat ini tersedia melalui tanda karena berguna dalam beberapa kasus.

Apakah ada alasan (selain kompatibilitas mundur) untuk tidak membuatnya pip install secara implisit melakukan peningkatan "minimal"? Saya mencoba mencari tahu dalam situasi apa saya sebenarnya ingin itu hanya menginstal dan tidak melakukan peningkatan (IOW, versi di mana versi terbaru baik-baik saja jika saya belum menginstalnya, tetapi tidak jika saya memilikinya diinstal) dan saya mengalami masalah dengan kasus di mana saya ingin perilaku saat ini.

Saya suka ide perintah _new_ pip upgrade [--recursive] seperti pada #3194 (dan tidak lagi digunakan install --upgrade )

Saya memiliki kekhawatiran tentang pilihan apa pun yang merusak kompatibilitas atau memiliki penghentian yang kompleks atau yang membebani pip install memiliki banyak opsi dengan lebih banyak perubahan atau kompleksitas. Juga, saya pribadi tertarik pada perintah "upgrade", yang secara default, hanya memutakhirkan mirip dengan cara kerja alat distro. "install" install, dan "upgrade" upgrade...

Saya cenderung ke tampilan "lakukan saja, dan persetan dengan kompatibilitas mundur"

Saya tidak :) setidaknya untuk logika inti seperti ini.

buat jadi pip install secara implisit melakukan peningkatan "minimal"

bagi saya, mengingat ini sepertinya non-starter, bukan? pertimbangkan # kerusakan build otomatis yang mungkin terjadi. juga, orang-orang terjebak dalam model konseptual pada titik tertentu tentang apa itu pip install ... dan ini akan memaksa memuat ulang model mental baru. orang tidak suka itu.

@qwcode Saya tidak tahu, saya tidak berpikir itu akan baik-baik saja. Masalah utama dengan pip upgrade adalah apakah Anda menghapus cara orang mengatakan "beri saya versi terbaru ini terlepas dari apakah itu diinstal atau tidak" atau Anda memiliki dua perintah yang melakukan hal yang hampir seluruhnya sama ( pip install dan pip upgrade ). Mungkin ada beberapa kerusakan dalam jangka pendek, tetapi saya sedikit khawatir tentang model mental sebenarnya dari pip upgrade karena saya dapat melihat orang-orang tersebar luas mengganti instruksi pemasangan mereka dari pip install foo ke pip upgrade foo (tetapi mengapa saya memutakhirkan sesuatu yang belum saya instal?!).

Eh, saya pikir itu akan baik-baik saja maksud saya.

tersebar luas menggantikan instruksi pemasangan mereka pip install foo menjadi pip upgrade foo

baiklah, itu sebabnya saya pikir upgrade harus ditingkatkan saja. untuk "kotoran" --fill-in-missing , saya tidak terjebak pada itu, jadi jangan menganggap saya berarti bahwa saya harus memilikinya, tetapi lihat di bawah.

"beri saya versi terbaru ini terlepas dari apakah itu diinstal atau tidak"

• jika saya tidak memiliki FOO , maka saya pip install FOO dan saya mendapatkan versi terbaru.
• jika saya memiliki FOO , maka pip upgrade FOO dan saya mendapatkan versi terbaru.

Saya pikir kita sedang berbicara tentang 2 kasus:

1. Saya tidak tahu apakah saya memiliki FOO , dan saya ingin perintah _one_ mendapatkan FOO , apakah saya memilikinya atau tidak.
2. Saya ingin perintah _one_ mendapatkan FOO dan BAR . Saya telah menginstal FOO , tetapi tidak BAR .

Apakah kita berutang perintah _one_ kepada pengguna untuk ini? Saya lebih suka kesederhanaan dan kejelasan dalam perintah daripada memberi orang jalan pintas. Tetapi jika pengguna menuntutnya, maka di situlah sesuatu seperti --fill-in-missing masuk.

Juga, saya pribadi tertarik pada perintah "upgrade", yang secara default, hanya memutakhirkan mirip dengan cara kerja alat distro. "install" install, dan "upgrade" upgrade...

Poin klarifikasi: Saya baru saja memeriksa cara kerja tiga alat distro populer, dan AFAICT (sebagian ini didasarkan pada halaman manual b/c Saya tidak menggunakan semua ini sendiri):

• tepat:
  
  
  
  • apt install <pkg> melakukan "upstall" -- baik mengupgrade atau menginstal tergantung pada apakah sudah diinstal atau belum.
  
  
  • apt upgrade meningkatkan semua paket yang diinstal
  
  
  • apt upgrade <pkg> tidak ada, satu-satunya cara untuk memutakhirkan satu paket adalah apt install <pkg> (yang juga menerima berbagai jenis penentu versi)
  
  
• enak:
  
  
  
  • yum install <pkg> melakukan "upstall"
  
  
  • yum upgrade meningkatkan semua paket yang diinstal
  
  
  • yum upgrade <pkg> memutakhirkan daftar paket yang ditentukan. Saya tidak tahu apa yang terjadi jika mereka belum diinstal.
  
  
• buatan sendiri:
  
  
  
  • brew install <pkg> melakukan "upstall"
  
  
  • brew upgrade meningkatkan semua paket
  
  
  • brew upgrade <pkg> memutakhirkan daftar paket yang ditentukan. Saya tidak tahu apa yang terjadi jika mereka belum diinstal.
  
  

Jadi menggunakan instal untuk peningkatan sebenarnya adalah apa yang dilakukan alat distro :-). Tidak berarti kita harus juga; hanya titik data.

Saya tidak tahu apakah saya memiliki FOO, dan saya ingin satu perintah untuk mendapatkan FOO terbaru, apakah saya memilikinya atau tidak.

Saya pikir kasus penggunaan yang paling jelas menarik untuk ini adalah dalam dokumentasi. Contoh: Django docs yang saya tautkan di utas lain yang menginstruksikan orang untuk menjalankan pip install -U <some package> . Anda tidak ingin memberitahu orang untuk "menjalankan pip install <pkg> kecuali jika Anda sudah menginstalnya, jalankan pip upgrade <pkg> " karena itu terlalu membingungkan untuk pemula, tetapi jika install tidak' t upgrade kemudian hanya memberitahu orang untuk menjalankan pip install <pkg> juga akan membuat kebingungan di mana orang mulai bekerja melalui tutorial Anda dengan versi lama diinstal dan kemudian tidak tahu mengapa hal-hal tidak bekerja dengan benar dan menyalahkan Anda untuk itu. Jadi, Anda pasti memerlukan satu perintah "upstall", dan itu harus sederhana dan jelas untuk disertakan dalam dokumen.

Tindak lanjut pada perilaku Homebrew untuk perbandingan: brew upgrade gagal jika Anda mencoba menginstal paket yang tidak diinstal:

$ brew upgrade git
Error: No such file or directory - /usr/local/Cellar/git

Juga, perilaku brew upgrade ini berubah (lihat diskusi di sini ); di rilis mendatang, itu akan beralih ke membutuhkan --all untuk memutakhirkan semua paket yang diinstal.

Poin klarifikasi

Aku tahu seseorang akan menangkap ini. :)
Saya hampir menjawab sendiri. Saya fokus pada peningkatan.

peningkatan yang enak[...] Saya tidak tahu apa yang terjadi jika mereka belum diinstal.

itu tidak melakukan apa-apa

instal yummelakukan "upstall"

benar, tetapi perilaku defaultnya adalah meminta konfirmasi, yang tidak dimiliki pip.

dokumen Django yang saya tautkan di utas lainnya

untuk lebih jelasnya, itu bukanlah dokumen Django yang sebenarnya. dokumen Django mengatakan pip install Django (https://docs.djangoproject.com/en/1.8/topics/install/)

itu sebenarnya hal yang buruk menurut saya, mengingat cara kerja -U saat ini, untuk membuat orang terbiasa menggunakan install -U .

dalam contoh tertaut Anda, saya pikir itu untuk redis yang tidak memiliki dependensi, jadi tidak apa-apa dalam kasus ini.

akan membuat kebingungan di mana orang mulai mengerjakan tutorial Anda
dengan versi lama [...] Jadi, Anda pasti membutuhkan satu perintah "upstall"

IDK, Tidak begitu jelas bagi saya bahwa tutorial harus memberitahu orang untuk upstall secara umum. Jika seseorang melakukan tutorial untuk FOO, dan mereka sudah menginstal FOO, maka mungkin mereka tidak boleh "memperbaiki" secara membabi buta.... mungkin peningkatan akan merusak lingkungan yang ada.

Saya pikir tutorial harus memberitahu orang-orang untuk "meningkatkan" (istilah yang bagus!) karena cukup banyak dari mereka yang ditulis oleh proyek itu sendiri dan ketika orang pergi untuk melihat tutorial mereka jarang melihat dulu untuk melihat versi FOO yang ada. telah diinstal, mereka cenderung melihat dokumen terbaru apa pun.

Saya juga setuju bahwa cara kerja -U saat ini, adalah kebiasaan buruk untuk membuat orang terbiasa menggunakannya tanpa pandang bulu, tetapi hal utama yang menurut saya adalah dengan perilaku yang diusulkan Saya tidak berpikir itu kebiasaan buruk , melainkan hal yang baik untuk dilakukan. Jika Anda perlu memastikan bahwa versi tertentu telah terinstal daripada Anda seharusnya sudah menggunakan == dan kami dapat menambahkan tanda untuk mengubah "upstall" default kembali menjadi "instal" biasa untuk orang-orang yang perlu memastikan bahwa versi yang saat ini diinstal ATAU versi terbaru diinstal (walaupun saya masih tidak dapat membuat skenario di mana ini sebenarnya yang diinginkan semua orang).

Saya pikir tutorial harus memberi tahu orang-orang untuk "meningkatkan"

sekali lagi, bagaimanapun, di lingkungan apa mereka berada, di mana jelas tidak apa-apa untuk memutakhirkan? Jika itu adalah lingkungan python sistem distro, maka tentu saja tidak. Jika lingkungan lain, mereka dibuat untuk aplikasi, maka upstall bisa merusak. jika itu adalah lingkungan yang baru saja mereka buat untuk tutorial, maka mereka tidak perlu memutakhirkan.

poin kunci di sini adalah bahwa PyPI bukan repo "dikuratori", seperti repo distro. Anda dapat cukup yakin bahwa "upstall" aman dari repositori distro default... Anda tidak tahu itu dengan PyPI. Setiap peningkatan adalah pertaruhan. "instal", sebagaimana adanya, bersifat konservatif.

ingatlah bahwa membuat pip install bertindak seperti "peningkat" tanpa memperbaiki #988 akan merusak segalanya.

pertimbangkan di mana A dan B diinstal dan A membutuhkan B<2 . Sekarang saya menjalankan pip install B , yang meningkatkan B ke v3 atau apa pun (karena tidak mempertimbangkan kendala yang diinstal), dan sekarang lingkungan saya rusak.

untuk orang-orang yang perlu memastikan bahwa versi yang saat ini diinstal ATAU versi terbaru telah diinstal (walaupun saya masih tidak dapat membuat skenario di mana ini sebenarnya yang diinginkan semua orang).

Ini sepele untuk datang dengan skenario seperti itu. Contoh (sayangnya tidak dibuat-buat): saat ini statsmodels dipecah oleh pandas (0.17.0). Saya pengguna keduanya. Saya memiliki banyak versi Python yang diinstal dan venvs tergeletak di sekitar. Jadi saya tahu bahwa untuk Python/venv apa pun saya ingin menginstal pandas hanya jika belum ada. Jika ya, saya mungkin juga akan memiliki statsmodels dan kemudian "upstall" akan merusaknya.

@rgommers Hmm, jadi Anda benar-benar yakin bahwa Anda tidak memiliki panda 0.17.0 di lingkungan virtual di mana saja? Saya kira itu bisa terjadi meskipun saya pikir saya mungkin akan mengejanya dengan melakukan pip install pandas!=0.17.0 atau pip install pandas<0.17 tetapi saya kira tidak sepenuhnya tidak masuk akal untuk mengandalkan apa yang sudah Anda instal.

Hmm, jadi Anda benar-benar yakin bahwa Anda tidak memiliki panda 0.17.0 di lingkungan virtual di mana pun?

Bukan itu yang saya katakan. Saya memiliki venv dengan pandas 0.17.0, hanya satu di mana saya tidak memiliki statsmodels. pip install pandas<0.17 akan melakukan pekerjaan itu, tetapi tidak terpikir oleh saya untuk menggunakannya (terutama karena saya tidak perlu, perintah install berfungsi untuk tujuan ini).

Bagaimanapun, saya tidak memiliki banyak preferensi untuk atau menentang upstall. Saya hanya ingin menunjukkan skenario yang realistis ketika Anda mengatakan bahwa Anda tidak dapat membuatnya.

+1

Diskusi ini tampaknya terhenti tanpa sampai pada kesimpulan. Opsi apa pun di atas meja adalah peningkatan besar pada status saat ini. Sepertinya semua pro dan kontra yang relevan telah dipertimbangkan; hanya ada perbedaan pendapat tentang kepentingan relatif dari kompatibilitas mundur vs. API yang optimal. Mungkin pengembang pip dapat mencoba menyelesaikan keputusan?

@rgommers mereka mungkin melakukan keputusan? https://pip.pypa.io/en/stable/user_guide/#only -if-needed-recursive-upgrade

@rgommers mereka mungkin melakukan keputusan? https://pip.pypa.io/en/stable/user_guide/#only -if-needed-recursive-upgrade

@Liso77 terima kasih, tapi tidak - itu benar-benar diskusi di utas ini yang perlu diselesaikan. Dokumentasi yang Anda tautkan hanya menunjuk kembali ke sini.

@rgommers dari tautan yang saya posting di atas, saya membaca bahwa pengembang akan membuat perintah pemutakhiran. Dan jangan berencana untuk menambahkan opsi "hanya jika diperlukan" untuk menginstal perintah karena mereka tidak membuat istilah untuk opsi ini dan hanya menggunakan deskripsi dalam tanda kutip. Jadi dari komentar Anda (atau dstuff) pada 30 Oktober - ini adalah: _2. Pindahkan UX ke pemutakhiran pip dengan default "benar"..._ (btw saya lebih suka ini)
Saya yakin Anda lebih memikirkan topik ini dan Anda melihat hal yang lebih halus yang saya lakukan. Jadi tolong tulis apa (jika menurut Anda ada sesuatu) yang masih terbuka. Jika Anda bermaksud bahwa mungkin baik bahwa pengembang menulis di sini secara eksplisit keputusan mereka dan akhirnya menutup masalah ini - saya setuju.

Omong-omong. situasinya bisa jauh lebih sedikit bermasalah jika kita memiliki sesuatu seperti

pip freeze > checkpoint.txt
pip checkout checkpoint.txt

yang dapat menjamin pengembalian instalasi ke "pos pemeriksaan" mana pun. (pip install -r tidak bagus saat ini) Saya berpikir untuk menambahkan proposal ini dalam edisi baru tetapi saya yakin saya harus belajar dan menganalisis lebih banyak untuk menghasilkan proposal yang sangat berguna. Saya melihat ada banyak peringatan tetapi saya sangat suka memiliki kemungkinan untuk

pip checkout git+https://github.com/somebody_trusted/pip_distro4ubuntu<strong i="12">@bleeding_egde_branch</strong>
#or
pip checkout git+https://github.com/somebody_trusted/pip_distro4ubuntu<strong i="13">@stable</strong>

Maksud saya itu dapat memecahkan (dengan bantuan someone_trusted (atau komunitas dengan banyak unit test)) sesuatu seperti masalah panda dan statsmodels yang Anda jelaskan di atas.

(berguna untuk melihat untuk topik ini juga: https://pypi.python.org/pypi/peep)

@Liso77 sederhana: diskusi tentang masalah ini belum selesai. Ada PR yang menunggu dengan perintah upgrade diimplementasikan (gh-3194), tetapi pip devs (setidaknya qwcode dan @dstufft , dan mungkin juga @xavfernandez dan @pfmoore) perlu memutuskan apakah itu yang mereka inginkan , atau mereka ingin mengubah perilaku pip install sebagai gantinya. Sampai itu terjadi, tidak ada yang akan berubah.

+1

Jadi, tampaknya memperkenalkan perintah pemutakhiran baru telah disetujui dan perdebatan terbaru yang belum terselesaikan adalah apakah harus ada perintah "upstall" atau tidak dan jika ya, perintah utama mana (instal atau perbarui) yang harus mendapatkannya sebagai sakelar atau default .

Melempar pendapat pribadi saya:

Saya pikir memiliki perintah tunggal yang gagal-aman untuk upstalling adalah "layak", _if only_ untuk kasus di mana Anda ingin memverifikasi secara terprogram bahwa lingkungan mutakhir karena alasan apa pun. Mengapa "secara terprogram"? Karena tidak interaktif, yaitu tidak ada pengguna yang bereaksi terhadap kesalahan, peringatan, atau pesan lain yang mengarahkannya ke perintah saudara atau saudari karena sebuah paket sudah atau belum ada.
Opsional, prompt dapat ditambahkan menanyakan pengguna apakah dia ingin meng-upgrade atau menginstal bukan hanya mengeluh.

Yang mengatakan, perintah "upstall" ini tidak boleh menjadi default dari salah satu perintah (instal/upgrade) dan karenanya memerlukan opsi untuk dipanggil. Ini menambah kejelasan pada kata kerja "instal" dan "upgrade" yang didefinisikan dengan jelas secara semantik, dan menurut saya semua manajer paket yang melakukan upstall secara default pada salah satunya melakukan kesalahan. Meminta tindakan (seperti yang tampaknya dilakukan yum ) tidak masalah.

Ini meninggalkan kita dengan upgrade --install (lebih pendek dari --install-missing ) dan install --upgrade . Secara semantik, "tingkatkan ke terbaru [dan instal jika tidak ada]" dan "instal terbaru [atau tingkatkan ke terbaru jika sudah ada]". Tidak banyak perbedaan di sini imo. install --upgrade adalah versi yang sudah ada dan dapat dikenali, tetapi tidak kompatibel dengan versi sebelumnya.
Berikut ini satu lagi untuk campuran: Perintah baru bernama install-upgrade (atau upstall ?), di mana tidak menginstal atau memutakhirkan mendapatkan opsi untuk "juga melakukan yang lain" tetapi perintah baru diperkenalkan dengan semantik yang jelas dalam posisi penting: nama perintah itu sendiri. Ini akan menjadi preferensi saya.

TL;DR : Perkenalkan upgrade dan upgrade-install , tidak digunakan lagi install --upgrade . Semua fungsi dengan semantik yang jelas.
Tambahkan pesan atau secara opsional meminta untuk menginstal dan memutakhirkan perintah jika operasinya gagal karena paket sudah ada atau belum.

Lakukan ini lagi secara manual pagi ini. Apakah ada berita tentang permintaan fitur ini?

+1

+1

+1

Semuanya, silakan gunakan reaksi jempol ke atas di OP dan berhenti mengirim spam ke kotak masuk semua orang.

karena pip memiliki model QA yang berbeda dari distribusi linux, saya cukup yakin, upgrade acak semua perintah hanyalah kerusakan dalam pembuatan

pypi tidak memiliki database versi paket dan kompatibilitas yang sebenarnya diverifikasi dan diuji,
jadi tidak seperti distribusi dengan QA, pypi praktis tidak memiliki QA sendiri dan bergantung sepenuhnya pada proyek yang diunggah ke dalamnya (yang kualitasnya bervariasi)

dengan serangkaian batasan saat ini, saya yakin itu lebih merupakan kutukan daripada berkah
dan jika ada yang bertanya-tanya mengapa distribusi sudah ketinggalan zaman, QA membutuhkan waktu dan usaha yang sebenarnya ^^

Semuanya, silakan gunakan reaksi jempol ke atas di OP dan berhenti mengirim spam ke kotak masuk semua orang.

Perhatikan bahwa kita sebenarnya tidak membutuhkan _apa pun_ respons "Saya ingin ini" dari orang-orang. Kami sadar bahwa orang menginginkan ini, yang kurang adalah siapa pun yang mau mengembangkan perbaikan yang memenuhi semua berbagai masalah dan masalah yang telah diangkat, dan yang pasti akan muncul selama tinjauan PR.

Jadi secara pribadi, saya akan menghargai jika orang menahan diri untuk tidak mem-ping masalah ini kecuali mereka memiliki kode kerja yang setidaknya menawarkan titik awal untuk implementasi - dan mereka bersedia mengikutinya hingga implementasi.

Jika tidak, kita akan mendapatkannya ketika kita bisa. Saya pribadi mengalami masalah ini secara teratur, dan saya adalah pengembang pip inti, jadi saya dapat menjamin bahwa jika saya memiliki waktu yang cukup untuk mengerjakan ini, saya akan melakukannya. Sementara itu, "ada kemajuan?" komentar cenderung hanya menurunkan motivasi saya karena kebanyakan hanya merasa seperti orang yang menuntut hak untuk mendikte bagaimana saya menghabiskan waktu hobi saya...

titik awal untuk implementasi

Saya pikir itulah tujuan dari https://github.com/pypa/pip/pull/3194? Dari sana diskusi beralih ke beberapa alternatif untuk penamaan dan perilaku perintah tanpa konsensus oleh pengembang inti. Apakah akan membantu untuk menerapkan beberapa dari alternatif tersebut? Atau apakah https://github.com/pypa/pip/pull/3194 hanya perlu penyegaran?

@sfriesel Anda melewatkan "dan bersedia mengikutinya". Sepertinya orang yang membuat PR itu kehabisan waktu atau minat (masalah umum). Langkah selanjutnya yang mungkin untuk OP atau orang lain yang bersedia mengambil alih kepemilikan PR, untuk menulis ringkasan gaya PEP dari posisi saat ini, apa berbagai masalah yang beredar, apa yang dia sarankan sebagai resolusi untuk berbagai masalah ini, dan panggilan untuk komentar untuk memulai kembali diskusi. Jika debatnya terlalu besar untuk github, mungkin dia perlu membawa dokumennya ke distutils-sig untuk masukan lebih lanjut. Jika dia tidak bisa memutuskan resolusi yang dia senangi untuk berbagai masalah, atau tidak bisa mendapatkan konsensus dari debat, maka ya, #3194 mungkin sudah mati (sampai orang lain mengambil masalahnya lagi, di titik mana saya berharap mereka memasukkan semua pekerjaan yang dilakukan ke dalam PR baru mereka).

Lebih dari 50% pekerjaan pada proposal seperti ini adalah "manajemen" (mendokumentasikan proposal, mengelola diskusi, membuat konsensus). Ini belum tentu sedikit yang suka dilakukan orang, tetapi dengan basis kode yang banyak digunakan seperti pip, ini adalah bagian penting. (Dan ya, itu masalah - lebih baik mengatakan "Saya menulis kode sebagai hobi" daripada "Saya melakukan manajemen proyek sebagai hobi" :-))

@pfmoore Sangat setuju.

Banyaknya usulan dan banyaknya diskusi, tersebar di banyak tempat, terkait isu ini selama bertahun-tahun membuat sangat sulit untuk mendekati isu ini dan mendapatkan gambaran yang jelas dalam waktu singkat .

@RonnyPfannschmidt

pypi tidak memiliki database versi paket

Itu benar. Ini adalah informasi yang disediakan oleh paket-paket pada saat run-time (dari setup.py) dan ini menambahkan sedikit lebih banyak kerumitan pada proses penyelesaian dependensi. Selain itu, karena bagaimana logika saat ini berperilaku, beberapa paket (bahkan yang menonjol seperti scipy) tidak mencantumkan ketergantungan (seperti numpy) jika diinstal untuk menghindari kompilasi ulang yang tidak perlu.

Itu akan diselesaikan oleh PEP 426 , antara lain tetapi saya tidak tahu apa status PEP itu.

@pfmoore

Perhatikan bahwa kita sebenarnya tidak membutuhkan tanggapan "Saya ingin ini" dari orang-orang

Sangat menggoda untuk mengatakan +1 atau mengacungkan jempol untuk menyatakan bahwa Anda ingin melihat ini terjadi. Ini membuat orang tersebut merasa seperti mereka telah menambahkan sedikit sesuatu untuk masalah ini, berkontribusi untuk itu. Saya tidak mengatakan bahwa pengembang pip perlu dimotivasi atau dibujuk, hanya saja semua orang ingin mengatakan itu. Dan...

Saya akan menghargai jika orang menahan diri untuk tidak melakukan ping masalah ini kecuali mereka memiliki kode yang berfungsi

Mengacungkan jempol tidak akan memberikan pemberitahuan/email kepada siapa pun (mengganggu) dan kami masih dapat melihat jumlah orang yang menunjukkan minat. Saya tidak berpikir siapa pun harus keberatan tetapi saya bisa saja salah.

Mengacungkan jempol tidak akan memberikan pemberitahuan/email kepada siapa pun (mengganggu) dan kami masih dapat melihat jumlah orang yang menunjukkan minat. Saya tidak berpikir siapa pun harus keberatan tetapi saya bisa saja salah.

Ah, saya tidak menyadari bahwa melakukan itu menghindari notifikasi. Ya, itu ide bagus.

Langkah selanjutnya yang mungkin untuk OP atau orang lain yang bersedia mengambil alih kepemilikan PR, untuk menulis ringkasan gaya PEP dari posisi saat ini, apa berbagai masalah yang beredar, apa yang dia sarankan sebagai resolusi untuk berbagai masalah ini, dan panggilan untuk komentar untuk memulai kembali diskusi.

Untuk apa nilainya, saya sebelumnya menulis tentang ini dan resolusi ketergantungan, gaya PEP. Saya akan membaginya dan memperbaruinya sekarang, menambahkan semua hal yang telah diusulkan dalam beberapa bulan terakhir. Saya akan memposting satu untuk perintah pemutakhiran sebagai Inti setelah selesai (~ 2 hari?) Dan menautkannya dari sini.

Saya belum mau mengambil alih kepemilikan PR dulu. Saya bermaksud membantu menghidupkan kembali diskusi dan mendapatkan desain akhir yang dapat diimplementasikan. Jika beberapa hal di sekitar saya pergi ke rencana, saya harus bisa mengikuti ini melalui penerapan tapi saya tidak ingin berkomitmen untuk itu berikut ini melalui dulu.

/cc @qwcode @dstufft @pfmoore @xavfernandez

Berikut tautan ke artikel saya: https://Gist.github.com/pradyunsg/a5abeac4af90fbdc54bb266c32c0d2d8

Saya awalnya hanya menautkan ke berbagai tempat (~30 tautan) agar pembaca dapat merujuk dan mencoba menyalin-lalu-edit-untuk-menyesuaikan semua utas komentar. Dokumen itu cukup panjang dan pendapat saya lolos. Saya akhirnya memulai dari awal. Ini lebih pendek sekarang dan tidak berpendirian. Saya masih menandainya sebagai WIP.

Jika ada masalah di dalamnya, silakan beri komentar di Gist. Saya akan melakukan koreksi sesegera mungkin.

PERINGATAN: _SLIGHTLY_ KOMENTAR PANJANG

Saya suka ide untuk memperbaiki perilaku --upgrade . Apakah ada kekhawatiran tentang ini selain kompatibilitas ke belakang? Menambahkan perintah upgrade sepertinya bukan ide yang bagus, karena tumpang tindih yang tinggi antara pemasangan dan peningkatan.

FWIW, git melakukan sesuatu yang mirip dengan apa yang kita diskusikan tentang --upgrade , mengubah perilaku default git push pada tahun 2014. tautan

Jika ada minat untuk mengubah perilaku pip install --upgrade , inilah proposal penyemaian (lihat ini sebagai P1) untuk diskusi itu:

• Memulai versi utama berikutnya (9.0), pip install --upgrade mencetak peringatan:

```
PipDeprecationWarning: pip akan berhenti memutakhirkan dependensi ke yang terbaru
versi tanpa syarat secara default memulai versi 11.0.

Untuk mempertahankan perilaku saat ini setelah perilaku default berubah, untuk
perintah install lulus --upgrade-strategy eager .

Untuk segera mulai menggunakan perilaku baru, ke perintah instal
lulus --upgrade-strategy non-eager .

Untuk meredam pesan ini,.

Untuk lebih jelasnya, baca.
```

Halaman dokumentasi yang ditautkan akan memberikan gambaran singkat tentang perubahan dan efeknya. Kemudian akan menjawab pertanyaan paling umum: "Apa yang harus saya lakukan?" dan "Strategi peningkatan mana yang harus saya gunakan?" dengan cara yang paling langsung masuk akal.

• Pesan tersebut dapat menggunakan pembersihan.
• Pilihannya bahkan bisa berupa 2 flag, --upgrade-eager dan --upgrade-non-eager atau sesuatu. Itu bikeshedding, yaitu langkah terakhir.
  
  
  
  • Kecuali jika terjadi sesuatu yang drastis, di versi 11.0, pip install --upgrade mengubah perilaku menjadi tidak bersemangat saat memutakhirkan dependensi.
  
  

Sunting: Saya menempatkan 3 siklus versi utama untuk perubahan, hanya untuk memberi lebih banyak waktu kepada orang-orang untuk beralih. Mungkin tidak perlu. Mungkin, 1 peringatan pencetakan versi utama dan perubahan berikutnya sudah cukup?

@dstufft telah menemukan ide yang serupa (sama?).

Jika perintah pemutakhiran adalah jalan ke depan, inilah proposal penyemaian untuk memulai kembali diskusi itu (lihat ini sebagai P2, jika Anda mau):

1. pip upgrade menyalin sebagian besar opsi dan perilaku dari pip install .
2. Bendera --dry-run akan ditambahkan ke perintah install dan upgrade yang mencetak pip apa yang akan dicoba jika benar-benar dijalankan.
3. pip install <out_of_date_pkg> tidak mengubah perilaku.
4. pip upgrade <not_installed_pkg> akan gagal.
5. pip upgrade <up_to_date_pkg> tidak akan melakukan apa-apa, katakan mengapa tidak melakukan apa-apa dan keluar dengan kode keluar nol.
6. pip upgrade <out_of_date_pkg> akan melakukan peningkatan rekursif yang tidak diinginkan.
   
   
   
   • :white_check_mark: Default untuk peningkatan rekursif yang tidak bersemangat
   
   
7. pip upgrade --eager package akan berperilaku seperti pip install --upgrade .
   
   
   
   • :white_check_mark: Izinkan keikutsertaan pada perilaku saat ini
   
   
8. pip install --upgrade akan mencetak RemovedInPip10Warning .
   Karena itu akan dihapus.

Selain itu, apa pendapat Anda tentang:

1. Membuat perintah pemutakhiran menjadi interaktif? (sesuatu seperti apa yang dilakukan apt-get)
   
   
   
   • membuat pip install <pkg> berperilaku seperti instalasi manajer paket OS ieupstall?
   
   
2. Memiliki --only-binary secara default di perintah peningkatan baru?
   
   
   
   • Jika sudah, bagaimana dengan menambahkan --only-source dan --no-source pada perintah upgrade?
   
   
3. Menambahkan opsi untuk "menahan" pembaruan suatu paket? IMO, ini adalah persyaratan untuk upgrade-all .
4. Apakah masuk akal untuk membedakan antara kasus-kasus ini yaitu memerlukan CLI yang berbeda?
   
   
   
   • instal: tidak diinstal -> terbaru
   
   
   • tingkatkan: kedaluwarsa -> mutakhir
   
   
   • pemasangan: {tidak dipasang, kedaluwarsa} -> mutakhir
   
   

Saya tidak mengusulkan apa pun tentang "instal sebagai upstall" karena saya juga tidak merasa kuat tentang hal itu. Ini konsisten dengan manajer paket tingkat OS tetapi akan menjadi perubahan besar. Saya tidak yakin seberapa berguna itu atau seperti apa perilaku dan antarmuka yang sebenarnya ...

Mungkin tidur selama ini bisa membantu.

Secara pribadi saya tidak melihat banyak nilai dalam menjaga konsistensi dengan beberapa perilaku jika ada orang yang senang. Saya ingin tahu apakah memiliki satu untuk Python 2 (mencakup stabilitas) dan satu lagi untuk Python 3 (mencakup perubahan) akan lebih baik atau lebih buruk.

@ekevo

Saya ingin tahu apakah memiliki satu untuk Python 2 (mencakup stabilitas) dan satu lagi untuk Python 3 (mencakup perubahan) akan lebih baik atau lebih buruk.

Satu, Itu di luar topik. Dua, jika Anda melakukannya, akan ada divergensi. Itu akan mengasingkan orang yang saat ini menggunakan Python 2 karena itu (semoga) akan mencapai EOL suatu hari nanti dan mereka harus beralih ke Python 3, harus beradaptasi dengan alat yang berperilaku berbeda. Jadi, pip seharusnya tidak melakukan divergensi (dan tidak akan, IMO). Mungkin juga menyimpannya bersama dalam satu alat.

OTOH, saya mengerti apa yang Anda pikirkan tentang seberapa banyak kompatibilitas mundur dapat diterima ...

Peringatan di pip 9, ditambah opsi tambahan untuk mengubah perilaku pip install --upgrade , --eager/non-eager (atau nama lain) tampaknya baik-baik saja bagi saya.

Menabrak. Pemberitahuan lain untuk semua orang.

@pfmoore @dstufft @qwcode Saya tidak ingin usil, tetapi bisakah Anda meluangkan waktu untuk ini, selama akhir pekan atau minggu mendatang?

Oke, jadi komentar saya:

Kembali dua cara ke depan, saya tidak punya pendapat. Pilih mana yang menurut Anda merupakan pilihan yang lebih baik, terapkan dan kita akan lihat bagaimana kelanjutannya dari sana.

Kembali pertanyaan tambahan Anda:

1. Saya -1 untuk membuat perintah menjadi interaktif. Kecuali jika ada masalah khusus yang perlu diambil keputusan oleh pengguna, di sepanjang baris "konsekuensi dari apa yang Anda minta ini adalah sesuatu yang jelas tidak Anda sadari, dan bisa menjadi masalah - apakah Anda ingin melanjutkan" maka itu hanya kebisingan yang tidak berguna. Saya menentang permintaan "apakah Anda yakin" secara umum. Jika Anda memiliki proposal khusus untuk suatu prompt yang menurut Anda layak ditambahkan, silakan bertanya lagi dengan menyertakan detailnya.
2. Kita seharusnya tidak membuat pemutakhiran berbeda dari penginstalan, jadi tidak pada --only-binary secara default. Untuk penggunaan pribadi saya, saya mungkin akan selalu menginginkan pip upgrade --only-binary pada contoh pertama, tetapi saya _menginginkannya_ secara eksplisit.
3. Saya tidak yakin apa yang Anda maksud tentang "menahan" pembaruan. Mohon klarifikasi. Tetapi sebagai tanggapan umum, saya akan mengatakan jangan repot-repot pada contoh pertama, mari jaga agar PR awal bebas dari "tambahan opsional" - mereka dapat ditambahkan nanti.
4. Bukankah itu topik utama perdebatan dari berbagai diskusi fitur ini? Sebagai permulaan, apakah itu tidak mempengaruhi pertanyaan dasar install --upgrade vs upgrade ? Saya tidak ingat pernah ada resolusi untuk pertanyaan itu, jadi saya sedikit terkejut Anda mengharapkan jawaban "sederhana" untuk yang ini? Saya tentu tidak punya jawaban yang bagus.

(Omong-omong, saya tidak memiliki akses mudah ke intinya, jadi jika ada konten di sana yang tidak ada dalam ringkasan Anda, maaf saya melewatkannya).

Saya tahu menulis PR adalah kerja keras, dan menurunkan motivasi untuk membuatnya terjebak dalam perdebatan dan pertanyaan, tetapi pada akhirnya, saya pikir seseorang harus menulisnya, dan meletakkannya di sana sebagai "inilah solusinya Saya mengusulkan - ada komentar?"

Kita tidak boleh membuat pemutakhiran berbeda dari pemasangan [snip] Saya mungkin akan selalu menginginkan pip upgrade --only-binary pada contoh pertama, tetapi saya ingin itu eksplisit.

Jika Anda mungkin selalu menginginkan sesuatu, itu harus default ¹ . Tapi saya pikir menjaga konsistensi di install dan kemungkinan upgrade perintah adalah ide yang bagus.

Saya tidak yakin apa yang Anda maksud tentang "menahan" pembaruan.

Saya akan membiarkan ini berhenti sampai kita sampai pada titik berbicara tentang menambahkan fungsionalitas upgrade-all.

catatan untuk diri sendiri: konsep apt-mark untuk pip

Saya -1 untuk membuat perintah menjadi interaktif. Kecuali jika ada masalah khusus yang harus diputuskan oleh pengguna

Dito.

Bukankah itu topik utama perdebatan dari berbagai diskusi fitur ini?

Persis mengapa saya ingin tahu apa yang kalian pikirkan.

Saya tidak ingat pernah ada resolusi untuk pertanyaan itu, jadi saya sedikit terkejut Anda mengharapkan jawaban "sederhana" untuk yang ini?

Saya belum mengharapkan jawaban "sederhana". Saya berharap kita sampai pada satu jawaban, sebaiknya sederhana, melalui diskusi.

Omong-omong, saya tidak memiliki akses mudah ke intinya, jadi jika ada konten di sana yang tidak ada dalam ringkasan Anda, saya melewatkannya maaf

Lebih dari ringkasan, ini adalah tindak lanjut dari penulisan. Silakan membacanya secepat Anda bisa melakukannya.

Pilih mana yang menurut Anda merupakan pilihan yang lebih baik, terapkan dan kita akan lihat bagaimana kelanjutannya dari sana.
[menggunting]
Saya pikir seseorang harus menulis satu [PR], dan meletakkannya di sana sebagai "ini adalah solusi yang saya usulkan - ada komentar?"

Saya berpikir di sepanjang baris "mari kita cari tahu persis apa yang kita inginkan terlebih dahulu" dan kemudian melanjutkan dan mengimplementasikannya.

¹ kecuali itu menghancurkan dunia orang lain

Kita tidak boleh membuat pemutakhiran berbeda dari pemasangan [snip] Saya mungkin akan selalu menginginkan pemutakhiran pip --only-binary pada contoh pertama, tetapi saya ingin itu eksplisit.
Jika Anda mungkin selalu menginginkan sesuatu, itu harus default. Tetapi saya pikir menjaga konsistensi di seluruh pemasangan dan kemungkinan perintah peningkatan adalah ide yang bagus.

Jika _everyone_ mungkin selalu menginginkan sesuatu, itu (mungkin) harus menjadi default. Tapi saya hanya mengomentari preferensi saya sendiri. Sejujurnya saya tidak tahu apakah --only-binary adalah yang diinginkan kebanyakan orang (mungkin tergantung pada apakah kita berbicara jangka panjang atau pendek).

Ada perbedaan yang kuat antara binari (roda), sumber yang dapat dibangun di mana saja (biasanya Python murni) dan sumber yang memerlukan kompiler atau prasyarat eksternal lainnya. Sayangnya, pip tidak dapat membedakan dua yang terakhir, dan itu membuat --only-binary kurang berguna (terutama sebagai default).

Dan saya menghargai konsistensi antara perintah di atas default "lakukan apa yang saya maksud", yang lagi-lagi mungkin hanya preferensi pribadi saya.

Lebih dari ringkasan, ini adalah tindak lanjut dari penulisan. Silakan membacanya secepat Anda bisa melakukannya.

Saya sudah membacanya, itu tidak menambahkan banyak yang saya tidak sadari (karena saya telah mengikuti berbagai utas tentang ini), jadi komentar saya tetap ada. Tapi ini ringkasan yang bagus tentang keadaan permainan, jadi terima kasih telah menulisnya.

Kita tidak boleh membuat pemutakhiran berbeda dari pemasangan [snip] Saya mungkin akan selalu menginginkan pemutakhiran pip --only-binary pada contoh pertama, tetapi saya ingin itu eksplisit.

Jika Anda mungkin selalu menginginkan sesuatu, itu harus default. Tetapi saya pikir menjaga konsistensi di seluruh pemasangan dan kemungkinan perintah peningkatan adalah ide yang bagus.

Jika _everyone_ mungkin selalu menginginkan sesuatu, itu (mungkin) harus menjadi default. Tapi saya hanya mengomentari preferensi saya sendiri.

Klarifikasi: "Anda" dalam komentar saya mengacu pada pengguna akhir (jamak), @pfmoore menjadi satu dalam kasus khusus itu. Saya benar-benar harus menggunakan beberapa kata lain.

Beberapa pemikiran tentang strategi peningkatan. Pendapat pribadi, semua ini tentu saja :-)

Misalkan saya melakukan pip upgrade foo

1. Jika saat ini saya belum menginstal foo , saya mengharapkan kesalahan. Bagi saya, "instal" dan "upgrade" adalah dua aktivitas terpisah yang tidak ingin saya gabungkan.
2. Jika tidak ada versi yang tersedia yang lebih baru dari apa yang saat ini diinstal (lihat di bawah re --only-binary ) maka saya mengharapkan pemberitahuan bahwa tidak ada yang bisa dilakukan.
3. Jika tidak, saya berharap foo ditingkatkan ke versi terbaru. Itu yang saya minta, jadi itu harus terjadi.
   
   
   
   • Saya tidak yakin bahwa menambahkan batasan masuk akal. Apa arti pip upgrade foo>1.0 jika saya telah menginstal 1.1 tetapi 1.2 tersedia? Ini bukan peningkatan jika meninggalkan 1.1 di sana, tetapi jika ditingkatkan ke 1.2, itu sama dengan pip upgrade foo . Mungkin Anda bisa menganggap sesuatu seperti pip upgrade foo<2.0 tetapi IMO itu akan menjadi kasus yang sangat tidak biasa, dan tidak sebanding dengan kerumitannya. Jadi mari kita asumsikan pip upgrade hanya mengambil daftar nama paket (sebagai lawan dari persyaratan).
   
   
   • Demikian pula, saya tidak tahu bagaimana menafsirkan pip upgrade <path_to_archive/wheel> . Mari kita asumsikan itu tidak diperbolehkan pada contoh pertama.
   
   
4. Saya mungkin atau mungkin tidak ingin mengizinkan pip untuk mencoba membangun dari sumber (ini harus menjadi keputusan pengguna, karena pip tidak tahu apakah membangun dari sumber akan berfungsi, dan tidak memiliki kemampuan untuk mencoba lagi dengan versi yang berbeda jika a pembuatan sumber gagal). Jadi --only-binary harus menjadi opsi pengguna, dan jika ditentukan, berarti pip harus mengabaikan distribusi sumber saat mengerjakan "apa yang tersedia". (Tentu saja kita bisa default hanya binari, dan memiliki opsi --allow-source , tapi bagaimanapun upgrade harus cocok dengan install dalam hal ini).

OK, jadi itu menangani paket yang ditentukan secara eksplisit. Saya ragu ada sesuatu yang kontroversial di sana (kecuali mungkin untuk bagian-bagian yang saya katakan harus kita hilangkan sampai nanti). Sekarang ke dependensi.

• Aturan utama dalam pikiran saya adalah bahwa kita tidak boleh melakukan apa pun pada dependensi, kecuali kita _sebenarnya_ memutakhirkan paket yang ditentukan pengguna. Jadi itulah titik awalnya. Jika target tidak ditingkatkan, jangan lihat dependensi. Pernah.
• Pandangan saya adalah bahwa _all_ dependensi harus ditangani dengan cara yang sama - apakah dependensi langsung atau tidak langsung dari paket yang ditentukan pengguna, tidak relevan. Saya tidak berpikir ini kontroversial.
• Asumsi mendasar di sini adalah bahwa pengguna tidak tahu apa daftar dependensinya. Lagi pula, tujuan memiliki dependensi implisit adalah agar pengguna _tidak_ harus mengelolanya. Jadi solusi apa pun yang memerlukan pengguna untuk mengetahui secara eksplisit tentang ketergantungan adalah cacat, dalam pandangan saya (kecuali sebuah perintah gagal dengan pesan tentang ketergantungan tertentu, dalam hal ini pengguna dapat menjalankan kembali dengan ketergantungan yang ditentukan dalam opsi - tetapi kita harus mencari pekerjaan pertama kali dalam sebanyak mungkin kasus, jadi ini tidak boleh dilihat sebagai norma).
• Saya akan mengatakan bahwa secara default, pendekatannya seharusnya hanya memutakhirkan dependensi yang _memiliki_ untuk ditingkatkan untuk memenuhi batasan baru. Ada masalah buruk yang mengintai di sini, karena batasan dapat berubah tergantung pada apa yang ditingkatkan. Tetapi apakah kita melakukan solusi lengkap untuk masalah itu, atau hanya mencoba beberapa solusi "usaha terbaik" tidak begitu penting (saya ragu grafik ketergantungan kompleks dengan kendala yang saling bertentangan umum terjadi dalam kehidupan nyata). Poin pentingnya adalah prinsipnya, bahwa kami tidak memutakhirkan apa pun yang tidak diminta oleh pengguna untuk ditingkatkan, kecuali jika kami harus melakukannya.
• Memiliki tanda untuk mengatakan "tingkatkan semuanya ke versi terbaru" mungkin berguna (setidaknya untuk kompatibilitas mundur). Lebih baik lagi jika memiliki alat (mungkin di luar pip) yang menganalisis dan melaporkan opsi peningkatan. Kemudian pengguna dapat memutuskan sendiri. Tetapi saya tidak tahu apakah saya akan pernah melihat kebutuhan untuk salah satu dari opsi ini sendiri.
• Daripada opsi "upgrade yang bersemangat", saya lebih cenderung menginginkan perintah upgrade-all (atau upgrade --all jika kita ingin mempertahankan satu perintah). Ini harus identik secara semantik dengan upgrade dengan setiap paket yang diinstal terdaftar di baris perintah. Setelah saya melakukan pemutakhiran paket secara buta (biasanya saya mungkin tidak tahu atau telah mendokumentasikan pohon ketergantungan paket saya), saya mungkin hanya menginginkan "semuanya". Terlebih lagi jika saya menggunakan lingkungan virtual untuk mengisolasi sesuatu.
• Pertanyaan --only-binary muncul lagi di sini. Tentu saja jika pengguna menentukan --only-binary untuk peningkatan utama, dependensi harus diasumsikan menyiratkan --only-binary . Tetapi bahkan jika pengguna mengizinkan penginstalan sumber saat memutakhirkan paket utama, memperkenalkan risiko kegagalan yang terlibat dalam melakukan peningkatan sumber dependensi tampaknya tidak masuk akal. Jadi saya sarankan kita hanya harus mempertimbangkan binari untuk meningkatkan dependensi, kecuali jika pengguna secara eksplisit mengizinkan source. Itu menyiratkan membutuhkan opsi --allow-source dep1,dep2,... . Saya berharap proposal ini kontroversial, tetapi pertimbangkan paket Python murni foo yang didistribusikan hanya dalam bentuk sumber, yang bergantung pada numpy. Kami memiliki foo 1.0 tergantung pada numpy >=1.10, dan foo 2.0 bergantung pada numpy >=1.11. Pengguna memiliki foo 1.0 dan ingin memutakhirkan. Mereka tidak memiliki sarana untuk membangun numpy. Mereka harus mengizinkan pemutakhiran sumber untuk foo, tetapi mereka tidak ingin membuang waktu untuk mencoba membangun numpy 1.11 (atau lebih buruk lagi, membangunnya mungkin berhasil tetapi memberikan pembangunan yang tidak dioptimalkan, yang merusak sistem mereka). Mereka tentu saja dapat menentukan --only-binary numpy tetapi mereka bahkan mungkin tidak menyadari bahwa foo bergantung pada numpy.

Itu saja. Bagi saya, persyaratannya cukup jelas (dan sejujurnya, saya tidak berpikir mereka sangat kontroversial jika kita mengabaikan masalah implementasi). Namun, implementasi adalah pembunuh di sini (pada dasarnya di atas cukup banyak menuntut pendekatan pemecah SAT penuh seperti yang telah dibahas sebelumnya). Kompromi apa yang ingin kami buat karena menerapkan pemecah SAT terlalu sulit, adalah di mana perdebatan kemungkinan akan terjadi.

Sejauh yang saya tahu, berikut ini akan menjadi tantangan implementasi:

1. Pemecah SAT penuh sulit. Saya tidak cukup tahu untuk memahami alternatif apa yang lebih sederhana, dan bagaimana mereka berbeda dari pemecah SAT. (Yah, peningkatan yang bersemangat, saya yakin, cukup sederhana - itulah mengapa itulah yang kami lakukan saat ini). Khususnya, ketika kami akan mendapatkan situasi di mana kami meningkatkan sesuatu yang menurut prinsip sederhana "jangan perbarui apa pun yang Anda tidak perlu" katakan seharusnya tidak ditingkatkan.
2. Saya telah mengabaikan apa pun kecuali batasan ketergantungan yang paling mendasar. Begitu kita terlibat dalam batas atas versi, atau daftar versi yang diizinkan, segalanya menjadi buruk. Tetapi secara realistis, kasus seperti itu cenderung sangat jarang (saya ingin seseorang melakukan penelitian tentang informasi ketergantungan aktual dari PyPI - saya mungkin mencoba melakukan itu, tetapi saya ragu saya akan mendapatkan waktu).
3. Ketika kita memiliki beberapa target - pip upgrade a b c - apakah kita memperlakukan ini sebagai 3 tindakan terpisah, "upgrade a", lalu "upgrade b" lalu "upgrade c", atau apakah kita menggabungkan 3 menjadi satu "gabungan" tindakan entah bagaimana (perhatikan bahwa karena saya mengusulkan memperlakukan dependensi berbeda dari target, ini _tidak_ sama dengan pip upgrade dummy mana dummy bergantung pada a, b dan c dan kami menganggap dummy telah ditingkatkan).

Jika ada yang ingin mempermasalahkan komentar atau pernyataan di atas, itu bagus. Sebagian besar ini hanya pendapat saya, dan sejujurnya saya tidak bekerja pada lingkungan yang kompleks - penggunaan saya kemungkinan besar adalah tentang memelihara instalasi sistem dan beberapa lingkungan virtual di Windows (karenanya, perdebatan tentang instalasi biner vs sumber penting untuk saya, tetapi grafik ketergantungan yang kompleks tidak begitu banyak). Semakin banyak kasus penggunaan yang dapat kita periksa dengan asumsi kita, semakin baik.

Jadi saat ini kami memiliki dua operasi, pip install dan pip install --upgrade , namun saya pikir kedua hal ini melakukan sesuatu yang sebenarnya tidak diinginkan oleh siapa pun dalam kehidupan nyata.

Untuk pip install , kami mendapatkan perilaku aneh ini di mana Anda mungkin mendapatkan versi terbaru (atau mungkin tidak!) Berdasarkan apa yang sudah diinstal di sistem Anda. Saya pikir keanehan semacam ini membuat pip lebih sulit untuk digunakan, dan saya pikir itu tidak masuk akal (situasi apa yang Anda pedulikan untuk tidak memutakhirkan tetapi Anda masih ingin menginstal yang terbaru jika Anda belum memilikinya dia?). Saya pikir fakta bahwa perintah ini memiliki perilaku mungkin-terbaru-mungkin-tidak yang aneh ini adalah alasan mengapa kami melihat banyak orang meraih pip install ---upgrade sebagai perintah utama mereka daripada pip install .

Namun, pip install --upgrade tidak jauh lebih baik, sementara itu memberi Anda perilaku yang konsisten, itu terlalu bersemangat, itu meluas menjadi peningkatan penuh _semuanya_ yang bahkan mungkin tidak disadari oleh pengguna akan terlibat dalam pip install --upgrade perintah

Apa yang saya pikir harus kita lakukan di sini, adalah mencari tahu jalan untuk membuat `pip install ... more consistent. In that I mean pip install harus selalu berakhir dengan versi terbaru yang dapat diterima (mengingat specifier dan flag pengubah seperti--only-binary ``) terlepas dari apa yang telah diinstal sebelumnya.

Saya pikir memberikan perintah ini semacam perilaku --eager atau --recursive atau --upgrade-all-the-things akan baik-baik saja.

Saya tidak berpikir bahwa perintah pip upgrade yang mengambil daftar paket adalah sesuatu yang harus kita lakukan. Saya pikir jika kita menambahkan perintah seperti itu, maka itu harus digunakan untuk hanya memutakhirkan semua yang diinstal ke versi terbaru (dengan mempertimbangkan informasi rantai ketergantungan, serta pengubah seperti --only-binary ).

Hah? Jadi pip install foo tidak selalu gagal jika foo diinstal? Itu tampaknya salah bagi saya, saya berharap itu hanya mengatakan "sudah diinstal".

Saya tidak tertarik dengan gagasan pip install sebagai "instal atau perbarui". Lebih baik eksplisit dan sebagainya.

Saat ini pip install foo tidak pernah "gagal" berdasarkan apakah sesuatu diinstal atau tidak, itu hanya akan melakukan apa-apa dan mengatakan bahwa X sudah diinstal. Pernyataan saya adalah bahwa perilaku tidak terlalu berguna. "Tegaskan bahwa beberapa versi, versi apa pun yang pernah diinstal" tampaknya bukan perilaku yang berguna bagi saya. Itu juga tidak cocok dengan manajer paket lain yang biasa saya sukai apt-get atau lebih.

Oke, saya dapat melihat bahwa perilaku itu tidak berguna (walaupun secara pribadi saya menganggap diam-diam menerima "sudah diinstal" sebagai hal yang tidak berbahaya). Tetapi saya lebih suka melihat instalasi paket yang sudah diinstal gagal, daripada memutakhirkannya.

Apa yang Anda harapkan dari pip install foo-1.0-none-any.whl jika foo 2.0 sudah diinstal? Turunkan versi? Diam-diam tidak melakukan apa-apa? Saya lebih suka melihat kesalahan "sudah terpasang" yang bagus dan sederhana daripada seperangkat aturan rumit yang saya ragu orang akan ingat dalam praktiknya.

Saya tidak punya banyak pengalaman dengan manajer paket Linux, jadi saya tidak bisa mengomentari kesamaan (atau sebaliknya) dengan pip. Tapi saya rasa saya tidak mengharapkan apt-get install foo untuk meningkatkan, jadi jika Anda mengatakannya, saya hanya bisa menjawab bahwa saya juga menganggap ini aneh.

"Tegaskan bahwa beberapa versi, versi apa pun yang pernah diinstal" tampaknya bukan perilaku yang berguna bagi saya.

Pertanyaan sampingan singkat tentang ini: Bagaimana dengan "Tegaskan bahwa versi khusus ini diinstal"?

Nevermind, kita memiliki perilaku itu hari ini.

@pfmoore :

Apa yang Anda harapkan untuk dilakukan pip install foo-1.0-none-any.whl jika foo 2.0 sudah diinstal? Turunkan versi? Diam-diam tidak melakukan apa-apa? Saya lebih suka melihat kesalahan "sudah terpasang" yang bagus dan sederhana daripada seperangkat aturan rumit yang saya ragu orang akan ingat dalam praktiknya.

Huh, ekspektasi adalah hal yang mengejutkan. Saya akan mengatakan bahwa _jelas_ dalam hal ini pip harus diturunkan. Pengguna telah sepenuhnya secara eksplisit mengatakan bahwa mereka ingin pip memasang roda khusus ini, jadi pip harus memasang roda khusus itu. Tidak ada yang rumit tentang itu. Tetapi kasus "jalur distribusi/file diberikan secara eksplisit" adalah #536 -- mungkin kita harus membuat diskusi ini lebih fokus pada apa yang terjadi jika pengguna mengatakan "pip install foo", yang menuju ke indeks paket dan menemukan foo 2.0, ketika foo 1.0 sudah diinstal.

Saya sangat setuju dengan posisi Donald di sini. Jika kita mulai dari pertanyaan "apa yang harus dilakukan pip install ?", maka saya dapat melihat bagaimana orang dapat berargumen bahwa, yah, tertulis 'instal' di namanya sehingga seharusnya hanya menginstal sesuatu, tidak pernah memutakhirkannya ( baik, kecuali jika ada beberapa kendala). Tetapi jika kita mulai dari pertanyaan "operasi apa yang diinginkan pengguna?", maka perintah yang mungkin menginstal yang terbaru, atau mungkin meninggalkan Anda dengan versi lama, benar-benar aneh dan kontra-intuitif. Saya menegaskan bahwa dalam 99% kasus di mana pengguna mengetik pip install x , itu karena mereka (a) tidak yakin apakah itu diinstal atau tidak, DAN (b) ingin memastikan bahwa mereka menginstalnya karena mereka akan mulai menggunakannya untuk pertama kalinya. (Jika ini bukan pertama kalinya, mereka akan tahu bahwa itu diinstal, sehingga mereka tidak akan menjalankan pip install .) Dalam situasi ini, memberi mereka versi terbaru adalah hal yang benar untuk dilakukan.

@nhammas :

Bagaimana dengan "Tegaskan bahwa versi khusus ini telah diinstal"? Itu tampaknya berguna bagi saya, memiliki perintah instal idempoten.

Untuk "versi spesifik" ada pip install x==<version> .

Saya juga dapat membayangkan bahwa untuk beberapa jenis penggunaan skrip/program, mungkin berguna untuk memiliki perintah pip require x yang memiliki semantik yang sama dengan menginstal paket dengan Dist-Requires: x , yaitu memastikan bahwa beberapa versi diinstal tetapi tanpa jaminan tentang apa. Tapi ini akan menjadi perintah tingkat rendah yang tidak ditujukan untuk pengguna akhir.

Salah satu cara untuk memikirkan perbedaan antara ini: jika x tidak diinstal, maka pip require x akan baik-baik saja untuk menginstal beberapa versi lama secara acak. (Dan sih, mungkin memang harus, untuk memaksa orang agar kuat melawannya .) Tapi tidak ada yang akan menerima pip install x menginstal beberapa versi lama secara acak.

(Ini adalah eksperimen pemikiran, saya sebenarnya tidak menganjurkan bahwa Dist-Requires: x atau pip require x di lingkungan tanpa x harus memilih versi lama acak x untuk menginstal.)

Yah, saya kira ada juga satu kasus lain di mana pengguna mengetik pip install x , yaitu ketika mereka sudah tahu itu diinstal, tetapi mereka terbiasa dengan sistem dengan perilaku gaya Debian di mana install selalu memutakhirkan . Jelas para pengguna ini juga ingin memutakhirkannya :-).

Saya lebih suka tidak menambahkan perintah pip upgrade .

pengguna pip sudah memiliki beberapa harapan tentang perilaku pip.
Titik sakit utama berasal dari perilaku default pip instal --upgrade jadi mari kita fokus pada itu.

Peringatan di pip 9, ditambah opsi tambahan untuk mengubah perilaku pip install --upgrade , (--eager/non-eager) diikuti di pip 10 dengan perubahan perilaku default tampaknya cukup sederhana, harus menghilangkan rasa sakit utama asal dan tidak merusak model mental pengguna pip pip.

Ya, saya pasti mencoba mendekati ini dari "operasi apa yang ingin dilakukan pengguna" versus "operasi apa yang harus dilakukan perintah X". Saya kemudian mengambil operasi tingkat tinggi yang saya _pikir_ pengguna ingin lakukan, dan mencoba memetakannya ke satu perintah bernama (sejelasnya, pip install-the-latest-version`` sangat tidak ramah pengguna) .

Ini jelas sangat kabur, tetapi saya dapat mengatakan bahwa 99% dari waktu yang saya lakukan adalah pip install -U <whatever> karena itu paling cocok dengan apa yang saya harapkan dari penginstal mengingat apa yang tersedia saat ini. Saya juga melihat di berbagai skrip otomatisasi orang menggunakan pip install -U . Itu juga yang dilakukan oleh manajer paket populer lainnya untuk bahasa secara default seperti npm. Dalam kasus di mana saya melihat orang tidak menggunakan -U , itu karena sifatnya yang rekursif, bukan karena mereka tidak ingin versi terbaru diinstal.

pengguna pip sudah memiliki beberapa harapan tentang perilaku pip.

TBH, bagaimanapun, harapan utama yang saya miliki tentang pip sebagai pengguna adalah bahwa pada sekitar 50% dari doa itu akan melakukan sesuatu yang mengejutkan dan jelas salah. Dan aku bukan satu-satunya - lihat misalnya @glyph 's bicara di PyCon pekan lalu di mana ia mengamati bahwa pip besar kecuali bahwa semua default yang rusak dan memerlukan Unbreak-me bendera. Ini bukan kritik terhadap pengembang pip, saya mengerti Anda/kita semua bekerja di bawah serangkaian kendala yang kompleks, dan ini bukan argumen bahwa kita harus menghancurkan segalanya mau tak mau demi melanggarnya -- pip memiliki banyak potongan dan banyak dari mereka baik-baik saja! Tetapi mengingat keadaan default pop secara keseluruhan, saya _benar-benar_ tidak yakin dengan argumen dalam bentuk "pip selalu melakukan X, oleh karena itu pip harus selalu melakukan X". Jika Anda ingin memperdebatkan pemasangan pip untuk menolak memutakhirkan maka itu keren, tetapi saya lebih suka melihat argumen itu dibuat berdasarkan manfaat yang sebenarnya, bukan hanya pada inersia.

Ya, saya tentu setuju dengan @njsmith dan @glyph di sini. Kami memiliki sejumlah perilaku default yang buruk, dan bagian dari bergerak maju, saya pikir perlu mencari tahu bagaimana kami dapat menghilangkannya dan menangani perubahan yang melanggar untuk memindahkan hal-hal ke default yang lebih baik.

Perubahan khusus ini mungkin bukan salah satunya, tetapi saya pikir itu.

Ya, saya pasti mencoba mendekati ini dari "operasi apa yang ingin dilakukan pengguna" versus "operasi apa yang harus dilakukan perintah X". Saya kemudian mengambil operasi tingkat tinggi ini yang menurut saya ingin dilakukan pengguna, dan mencoba memetakannya ke satu perintah bernama (sejelasnya, pip install-the-latest-version`` tidak terlalu ramah pengguna) .

OKE. Misalkan saya bersedia menganggap diri saya yakin (agak) tentang hal ini. Namun, jika kita menganggap ini adalah hal yang benar untuk dilakukan, bagaimana dengan dependensi? Saya 100% yakin bahwa "coba instal numpy dari sumber" hampir selalu bukan yang diinginkan. Jadi kami hanya menginstal numpy dari roda, kecuali jika pengguna secara eksplisit menyebutkan numpy. Anggap itu sebagai pemberian untuk saat ini, dan kemudian anggaplah kita memiliki situasi yang saya jelaskan sebelumnya.

• Pengguna telah menginstal foo 1.0 dan numpy 1.10, foo 1.0 bergantung pada numpy >= 1.10
• PyPI memiliki foo 2.0 tersedia, tergantung pada numpy >= 1.11. Tidak ada roda 1.11 yang numpy.

Apa yang dilakukan pip install foo ? Agaknya biarkan pengguna di 1.0, karena ini adalah instalasi yang berfungsi? Tetapi haruskah itu berhasil (karena foo diinstal) atau gagal (karena tidak dapat menginstal versi terbaru)? Jika yang pertama, bagaimana pengguna mengetahui bahwa sistemnya sudah usang? Jika yang terakhir, bagaimana pengguna mengatakan "Saya hanya ingin memastikan foo ada"? OK, pengguna dapat melakukan pip list --outdated , melihat bahwa foo 2.0 ada dan melakukan pip install foo (BTW, itu masih tampak sangat aneh bagi saya, saya punya foo, tapi saya tahu ada versi baru, jadi Saya menginstal pip??? Nevermind...) Dan berhasil, tetapi 1.0 tetap diinstal?

Salah satu alasan saya lebih memilih dua perintah adalah bahwa maksud pengguna benar-benar jelas, sehingga kasus tepi seperti ini dapat ditangani dengan benar karena kami mengetahui harapan pengguna.

Mungkin ini semua jelas jika Anda terbiasa dengan apt-get. Tapi saya pasti bisa mengatakan itu sama sekali tidak jelas bagi orang seperti saya yang tidak.

Jika Anda ingin memperdebatkan pemasangan pip untuk menolak memutakhirkan maka itu keren, tetapi saya lebih suka melihat argumen itu dibuat berdasarkan manfaat yang sebenarnya, bukan hanya pada inersia.

Argumen saya adalah atas dasar eksplisit daripada implisit. Paling pasti _not_ pada "kami selalu melakukannya dengan cara ini". Saya tidak memiliki masalah dengan gagasan bahwa mungkin pengguna apt terbiasa "menginstal" yang berarti "mungkin meningkatkan". Saya benar-benar tidak begitu yakin bahwa pengguna lain akan begitu.

Satu pemikiran - apakah apt memiliki "paket sudah ada - upgrade?" mengingatkan? Saya dapat membayangkan install-as-upgrade menjadi kurang mengejutkan bagi saya jika itu adalah "install-or-ask-if-I-should-upgrade"... Tentu saja, pip tidak berperilaku interaktif seperti itu saat ini, meskipun jelas membuatnya melakukannya adalah sebuah pilihan.

Itu adalah pertanyaan yang menarik-- Manajer paket lainnya sebagian besar menyiasatinya dengan tidak benar-benar memiliki paket biner sama sekali sehingga _always_ menurut sumbernya, atau dengan hanya berurusan dengan paket biner sehingga _always_ biner. Kami berada di semacam aneh di antara yang membuatnya lebih sulit.

Mengingat itu, saya pikir secara default untuk saat ini, kita harus menarik paket sumber numpy 1.11 dan mencoba menginstalnya, tetapi jika mereka telah menentukan --only-binary , maka resolver hipotetis kita (yang sangat kita butuhkan, SAT atau pelacakan balik atau apa pun) akan melihat bahwa foo-2.0 bukan instalasi yang dapat diselesaikan dan kemudian akan kembali menginstal foo-1.0 . Ini bukan default yang bagus, terutama untuk pengguna di Windows di mana kompilasi _jauh_ lebih sulit, tapi saya pikir itu mencerminkan kenyataan hari ini.

Meskipun demikian, satu hal yang benar-benar ingin saya lakukan adalah mulai mencoba dan mendorong hal-hal menuju dunia di mana kita dapat mengubah perilaku pip lagi sehingga secara default kita hanya dapat menjadi biner, dan memerlukan keikutsertaan untuk rilis sumber, tetapi saya tidak berpikir kita berada di tempat yang kita bisa melakukan itu.

@pfmoore : Saya pikir pertanyaan pemasangan biner vs. sumber agak ortogonal? Sepertinya saya seperti pertanyaan yang sama persis muncul untuk perintah pip upgrade , jadi sementara itu adalah masalah nyata yang perlu kita atasi, memisahkan peningkatan dan pemasangan hanya memindahkan masalah daripada menyederhanakannya? Juga, dalam kasus tertentu numpy, kami sekarang mengirimkan roda pada dasarnya untuk semua platform yang kami dukung :-).

Tapi inilah cara saya menyarankan penanganan masalah ini untuk pip install foo (khususnya perintah ini -- saya tidak berbicara tentang pip install foo==whatever atau pip install ./foo-*.whl atau pip install bar mana bar memiliki Requires-Dist: foo ):

1) Query indeks untuk menemukan kandidat versi terbaru dari foo ; sebut ini $LATEST . Jika tidak ada versi kandidat, maka error out.

2) Jika $LATEST sudah terinstal, maka selesai dengan sukses.

3) Periksa apakah ada distribusi $LATEST yang dapat diinstal pada lingkungan saat ini. (Contoh alasan mengapa mungkin tidak ada: hanya ada roda, tetapi tidak ada sdist, dan roda tidak cocok dengan lingkungan saat ini. Tidak ada roda yang cocok, dan ada sdist, tetapi pengguna telah melewati --binary-only :all: Tidak ada roda yang cocok, dan ada sdist, tetapi sdist memiliki beberapa tanda yang mengatakan "Saya hanya bekerja pada python 3" dan pengguna menjalankan python 2 -- orang ipython/jupyter mungkin akan mengusulkan ini sebagai fitur baru segera, b/c mereka ingin menjatuhkan dukungan python 2 untuk rilis baru pada bulan Januari sambil tetap menyediakan LTS yang mendukung python-2.)

4) Jika $LATEST _tidak_ memiliki distribusi yang layak: berikan peringatan untuk memberi tahu pengguna bahwa versi yang lebih baru tersedia tetapi tidak untuk lingkungan mereka, idealnya dengan petunjuk tentang apa yang perlu mereka lakukan jika mereka benar-benar melakukannya menginginkan versi baru (mis., "ipython 6.0.1 tersedia tetapi memerlukan python >= 3.4, dan Anda memiliki python 2.7 -- pertimbangkan untuk memutakhirkan python", atau "numpy 1.12 tersedia, tetapi tidak ada biner untuk ppc64 dan Anda memilikinya bangunan dinonaktifkan dari sumber -- pertimbangkan --allow-source numpy ). Kemudian hapus $LATEST dari daftar versi kandidat dan lanjutkan ke langkah 1.

5) Jika $LATEST _mempunyai distribusi yang layak, coba instal distribusi ini.

6) Jika penginstalan gagal (mis. b/c ini adalah sdist dan tidak ada kompiler), maka keluarlah kesalahan. Jika tidak, selesaikan dengan sukses.

@njsmith binary-only agak ortogonal, setuju, tetapi IMO jika kami mencoba merancang perintah yang "melakukan apa yang diharapkan pengguna" maka penting untuk melakukannya dengan benar pada saat yang bersamaan.

@dstufft masalah dengan "instal numpy kecuali pengguna mengatakan --binary-only dijelaskan dalam contoh di posting epik saya sebelumnya - (1) mengatakan bahwa foo hanya tersedia dalam bentuk sumber, dan (2) pengguna mungkin tidak (dan memang seharusnya tidak perlu) tahu bahwa foo bergantung pada numpy. Kemudian pengguna tidak dapat mengatakan --only-binary :all: dan tidak tahu bahwa mereka membutuhkan --only-binary numpy hingga _after_ a (lama) gagal kompilasi. Atau (mungkin lebih buruk lagi) kompilasi yang berhasil yang membuat pengguna dengan numpy yang tidak dioptimalkan (hari-hari ini, numpy mengkompilasi di luar kotak pada Windows, tetapi memberikan build yang tidak dioptimalkan).

Saya sepenuhnya setuju bahwa jangka panjang kita harus default ke biner saja, tapi kita belum mendekati itu (minimal, itu harus menyiratkan bahwa hampir setiap paket python murni tersedia sebagai roda).

@pradyunsg Seperti yang Anda lihat, masih banyak masalah yang belum terselesaikan di sini. Apakah Anda masih tertarik untuk meneruskan ini? Saya enggan memulai debat panjang lagi jika itu hanya akan mandek lagi ...

@pradyunsg Seperti yang Anda lihat, masih banyak masalah yang belum terselesaikan di sini. Apakah Anda masih tertarik untuk meneruskan ini? Saya enggan memulai debat panjang lagi jika itu hanya akan mandek lagi ...

Saya berharap akan ada. Saya tertarik untuk membawa ini ke depan. Mari kita lakukan! :senyum:

Saya sarankan mengumpulkan daftar dengan semua yang _user_ ingin pip lakukan dan kemudian mengusulkan solusi untuk masing-masing sampai semua (atau jumlah yang cukup) diselesaikan dengan perintah pip (dengan opsi/default) atau dapat ditangani dengan "tidak ada tindakan".

Untuk memulai, inilah daftar yang kemungkinan besar tidak lengkap:

1. Seorang pengguna ingin menginstal paket yang belum diinstal.
2. Seorang pengguna mencoba untuk menginstal paket yang sudah diinstal.
3. Seorang pengguna ingin memutakhirkan paket yang diinstal.
4. Seorang pengguna mencoba untuk meng-upgrade paket yang tidak diinstal.
5. Seorang pengguna ingin memastikan bahwa mereka telah menginstal versi terbaru dari sebuah paket, baik yang sudah diinstal atau belum.
6. Seorang pengguna biasanya tidak ingin semua dependensi ditingkatkan dan sebaliknya hanya puas.
7. Seorang pengguna ingin memutakhirkan/menginstal sebuah paket tetapi tidak ingin membangun dari sumber (baik paket maupun dependensinya). Mungkin lebih mungkin daripada:
8. Seorang pengguna bersedia untuk meng-upgrade/menginstal dari sumber.

Proposal pribadi saya untuk ini, sebagai pengguna:

1) & 7) pip install foo harus mencoba untuk menyelesaikan ke versi terbaru yang tersedia (mempertimbangkan dependensi) dan menginstalnya. Algoritma akan menjadi milik @njsmith .
2) pip install foo → tampilkan peringatan bahwa foo sudah diinstal dan usulkan menggunakan pip upgrade foo
3) & 7) pip upgrade foo mencoba menginstal versi foo terbaru yang tersedia, sekali lagi mengikuti algoritme @njsmith . Jika versi yang lebih baru tidak dapat diinstal karena tidak tersedia untuk platform dan tidak ada sdist atau pengguna tidak ingin membangun dari sumber, tunjukkan itu. Berhasil dalam kedua kasus dan hanya gagal jika instalasi itu sendiri gagal.
4) pip upgrade foo gagal jika paket tidak diinstal.
5) pip install-uprade foo atau pip install foo --ensure-latest atau pip install foo --upgrade (pada dasarnya sama seperti saat ini kecuali tidak bersemangat).
7) Semua operasi harus tidak bersemangat dan flag --eager akan tersedia untuk mendapatkan fungsionalitas lama install --upgrade . Jika ketergantungan belum diinstal, instal yang terbaru. Jika sudah puas, tidak melakukan apa-apa. Jika tidak puas, instal versi terbaru yang masih memuaskan (untuk persyaratan batas atas).
8) pip upgrade foo --allow-source atau pip upgrade foo --allow-source numpy , jika foo bergantung pada rilis numpy non-biner. Sunting: Saya tidak tahu apakah ini akan berlaku, lihat komentar di bawah.

Jangan ragu untuk memperpanjang daftar dan memposting proposal Anda sendiri.

@pfmoore Saya tidak yakin apa alternatifnya? Keadaan dunia saat ini adalah bahwa roda semakin kuat tetapi mereka tidak ada di mana-mana jadi saya tidak yakin saya benar-benar melihat opsi bagus yang tidak mengizinkan rilis sumber secara default sekarang.

@dstufft proposal saya adalah mengizinkan sumber untuk paket yang dinamai secara eksplisit, tetapi default hanya binari untuk dependensi. Dengan begitu pengguna tidak mendapatkan langkah membangun "kejutan". Ini kompromi, tentu saja, tetapi itu mencerminkan apa yang saya (harus) lakukan secara manual saat ini.

@FichteFoll Di atas segalanya, kasus penggunaan utama saya adalah untuk kemampuan "tingkatkan semua". Cari semua yang terinstal saat ini, dan jika ada versi yang lebih baru, tingkatkan versinya.

Paket yang saya instal biasanya tidak memiliki dependensi selain ">=" (dan sebagian besar bahkan tidak memilikinya) jadi tidak ada yang rumit di sini. Ambil saja versi terbaru. Batasan terbesar saya adalah ada beberapa paket yang tidak dapat saya buat (numpy, scipy, lxml, pyyaml, matplotlib, pyqt) jadi saya hanya ingin binari untuk itu. Saya mungkin bisa memasukkan --only-binary <these> dalam pip.ini (atau setidaknya saya harap saya bisa...)

Sekunder: Instal paket XXX (versi terbaru), ditambah semua dependensinya yang belum saya miliki. Jangan perbarui dependensi yang sudah saya miliki jika memenuhi batasan paket baru. Saya selalu tahu bahwa saat ini saya tidak memiliki XXX.

Tersier: Tingkatkan satu paket XXX yang saya (tahu saya) telah instal. Jangan ubah paket lain kecuali diperlukan untuk mempertahankan batasan ketergantungan (dan bahkan itu teoretis - saya belum pernah menghadapi situasi ini dalam kehidupan nyata jadi saya tidak tahu apa yang akan menjadi resolusi terbaik untuk saya). Niat saya selalu "upgrade ke versi terbaru". Saya belum pernah menemukan situasi di mana ini akan merusak dependensi paket yang sudah diinstal. Jika ya, saya _think_ saya ingin peringatan bahwa saya belum mendapatkan versi terbaru (dan mengapa) ditambah peningkatan ke versi terbaru yang dapat diterima. Dalam pikiran saya, situasi ini saat ini diterjemahkan menjadi pip install -U meskipun perilaku untuk dependensi bukanlah yang saya inginkan. Alasan utama saya melakukan ini adalah karena kurangnya "tingkatkan semua" yang sesuai saat ini (atau untuk menangani kasus-kasus di mana perintah "tingkatkan semua" baru gagal berfungsi seperti yang saya inginkan).

Semua diskusi tentang dependensi dan kendala, menurut pengalaman saya, hampir seluruhnya teoretis. Saat ini saya memiliki 160 paket yang diinstal di sistem saya Python (campuran modul ilmiah, analisis data, web dan pemrograman umum). 100 dari mereka tidak memiliki persyaratan. Selebihnya, tidak ada yang lebih kompleks daripada daftar paket - tidak ada batasan versi atau apa pun yang lebih kompleks dari Requires: six, dask, pillow, networkx . Daftar dependensi terpanjang memiliki 9 item.

@pfmoore Bukankah itu akan merusak banyak hal? Daftar singkat hal-hal yang dapat saya pikirkan dari atas kepala saya yang saya tahu adalah paket yang sangat populer tergantung pada:

• SQLAlchemy (opsional membutuhkan kompiler, akan menggunakan Python murni jika tidak).
• PyYAML (opsional membutuhkan kompiler, akan menggunakan Python murni jika tidak).
• Markupsafe (opsional membutuhkan kompiler, akan menggunakan Python murni jika tidak).
• PyCrypto (selalu membutuhkan kompiler)
• pycparser (tidak pernah membutuhkan kompiler)
• httplib2 (tidak pernah membutuhkan kompiler)
• anyjson (tidak pernah membutuhkan kompiler)
• zope.interface (opsional membutuhkan compiler, akan menggunakan Pure Python jika tidak).
• docopt (tidak pernah membutuhkan kompiler)
• Mako (tidak pernah membutuhkan kompiler)
• itsdangerous (tidak pernah membutuhkan kompiler)
• amqp (tidak pernah membutuhkan kompiler)
• orderdict (tidak pernah membutuhkan kompiler)

dan seterusnya, Anda dapat melihat daftar panjang paket paling populer dan apakah paket tersebut memiliki roda atau tidak di http://pythonwheels.com/.

@pfmoore

Cari semua yang terinstal saat ini, dan jika ada versi yang lebih baru, tingkatkan versinya.

Saya mengambil perintah ini dari beberapa pertanyaan SO beberapa waktu lalu yang saat ini saya gunakan untuk ini. Ini kurang optimal, tetapi berfungsi untuk sebagian besar paket saya, kecuali satu. (Ini menggunakan peluncur py karena saya menggunakan Windows.)

pip list -o | cut -d " " -f 1 | xargs -n1 py -m pip install -U

Sekarang, satu masalah yang saya miliki dengan ini adalah paket flake8, yang memiliki persyaratan ini:

Requires-Dist: pyflakes (>=0.8.1,<1.1)
Requires-Dist: pep8 (>=1.5.7,!=1.6.0,!=1.6.1,!=1.6.2)
Requires-Dist: mccabe (>=0.2.1,<0.5)

Secara khusus pyflakes adalah masalah karena itu memiliki versi yang lebih baru yang tersedia dan diperbarui dengan perintah di atas, menyebabkan flake8 gagal melakukan apa pun (karena ia memeriksa versi).
Jadi ini memang sesuatu yang perlu dipertimbangkan dan saya juga ingin memiliki fungsionalitas upgrade-semua yang tepat (tanpa melanggar persyaratan!).

@dstufft kenapa? Jika foo bergantung pada pyyaml ​​dan saya meminta untuk memutakhirkan foo, pyyaml ​​tidak dapat ditingkatkan (tidak ada binari baru) tetapi foo masih dapat ditingkatkan, karena masih ada pyyaml ​​asli yang ada.

Untuk dependensi baru (atau saat menginstal di mana dependensi tidak selalu ada), Anda harus menginstal, jadi jika tidak ada biner, Anda mengambil source. Saya pribadi akan mempertimbangkan "pilih versi yang lebih lama dengan biner daripada versi yang lebih baru dengan sumber" tetapi itu semakin mendekati default ke --binary-only yang saya setuju kita belum siap.

Hmm, mungkin masalah yang saya miliki sebenarnya dengan opsi --only-binary , yang terlalu kasar. Jika kami memiliki opsi --prefer-binary , yang mengatakan "hanya gunakan binari, kecuali itu berarti tidak ada kandidat, dalam hal ini coba lagi mengizinkan sumber", saya menduga banyak kekhawatiran saya bahwa peningkatan yang terlalu berlebihan akan mengakibatkan kerusakan mungkin bisa diringankan. Yang, seperti yang disarankan @njsmith , berarti bahwa perbedaan biner/sumber yang saya fokuskan mungkin ortogonal untuk tiket ini (walaupun itu hanya akan mengubah posisi saya menjadi "tidak ada solusi yang memuaskan untuk persyaratan saya tanpa sesuatu yang lebih baik dari --only-binary tersedia"...).

Secara khusus pyflakes adalah masalah

OK, jadi itu bukan situasi yang saya miliki (seperti yang saya katakan, saya tidak punya apa-apa dengan dependensi yang diinstal kompleks). Saya tidak punya masalah dengan menyempurnakan "tingkatkan semua" untuk memutakhirkan semuanya ke "versi terbaru yang tidak mengakibatkan kerusakan" tetapi AIUI yang membutuhkan pendekatan "pemecah SAT" untuk mencari solusi yang benar. Itu adalah masalah implementasi - desain memang harus selalu memberikan hasil yang benar.

@pfmoore Saya pikir bendera --prefer-binary bisa menjadi pilihan yang baik, terlepas dari hasil tiket ini. Kemungkinan dibundel dengan peringatan ketika akhirnya tidak menginstal versi terbaru yang seharusnya diinstal.

@FicheFoll : Saya tidak berpikir mencoba untuk menurunkan seluruh ui dari prinsip pertama akan menjadi sangat produktif. Ada bagian masalah yang relatif jelas yang menjadi topik untuk masalah khusus ini, dan jika kami mencoba memperluas cakupan ke semuanya sekaligus maka itu hanya akan macet lagi.

Pada topik itu, sepertinya tempat utama kami berbeda adalah ini: anggaplah bahwa pengguna memiliki model mental bahwa pip install foo hanya untuk mentransisikan sesuatu dari yang dihapus ke diinstal, dan bahwa mereka memahami bahwa foo sudah terpasang. Saya menegaskan bahwa pengguna dengan model mental ini _tidak akan pernah mengetik pip install foo _. Oleh karena itu, ketika beberapa pengguna _melakukan_ ketik pip install foo ketika foo sudah terinstal, kita dapat menyimpulkan bahwa model mental mereka tidak seperti Anda (2). _Kedua_ bagian pertama salah: mereka tahu foo telah diinstal dan mereka mengharapkan pip untuk ditingkatkan seperti beberapa manajer paket populer lainnya, _atau_, bagian kedua salah: mereka tidak menyadari bahwa foo telah diinstal , dalam hal ini mereka mengharapkan install untuk meninggalkan mereka dengan versi terbaru (karena itulah yang dilakukan install ketika paket tidak diinstal, dan mereka pikir paket ini tidak diinstal).

Sebagai catatan, salah satu alasan saya tidak suka pip install ... hanya pernah berubah dari tidak terinstal menjadi terinstal dan pip upgrade ... hanya pernah beralih dari diinstal ke hal yang lebih baru diinstal adalah karena saya menemukan pengguna pengalaman yang cukup payah. Perangkat lunak yang mengetahui apa yang Anda inginkan, tetapi alih-alih melakukan hal itu, ia memberitahu Anda untuk menjalankan beberapa perintah yang berbeda sangat membuat frustrasi.

$ pip install foobar
I'm sorry, but foobar is already installed, you want to run ``pip upgrade foobar``
$ pip upgrade foobar
...

Tidak akan melakukan apa pun untuk saya kecuali mengganggu saya, meskipun secara teknis "benar".

Sebaliknya, jika Anda mengatakan "ok, jika pip install foobar sudah menginstal foobar , maka kami akan bertindak seolah-olah itu tidak diinstal, dan jika Anda melakukannya pip upgrade foobar maka kami 'll bertindak seperti itu sudah diinstal, kita berakhir dengan dua perintah yang pada dasarnya melakukan hal yang sama, kecuali dengan _maybe_ beberapa perbedaan kecil dalam bagaimana sesuatu diproses, yang mengatakan kepada saya bahwa mereka termasuk sebagai perintah tunggal dengan beberapa --options untuk menangani kasus tepi. Saya pikir ini lebih baik karena itu berarti pengguna tidak harus mencoba membuat pilihan antara mana yang mereka inginkan di depan, ada satu perintah untuk menginstal barang dan untuk sebagian besar pengguna yang akan melakukannya umumnya melakukan hal yang benar Jika beberapa pengguna dalam skenario tertentu yang memerlukan beberapa pilihan di pihaknya, maka mereka harus membayar biaya untuk membuat beberapa pilihan tentang --flags akan digunakan.

OKE. Anggap saya yakin. Saya telah melakukan beberapa penelitian, dan bahkan penginstal Windows yang saya (seharusnya :-)) akrab dengan melakukan install-as-upgrade (jika Anda menginstal sesuatu seperti VirtualBox, dikatakan "Anda sudah menginstal versi sebelumnya, apakah Anda ingin memutakhirkan?") Powershell memiliki paket instal, yang tidak mengatakan sesuatu yang spesifik, tetapi tidak ada paket pemutakhiran. Dll. Jadi saya kira hanya memiliki satu perintah "install" adalah norma.

Yang tentu saja artinya, kecuali ada orang lain yang mau membantah, secara teknis PR ini bisa saja ditutup sebagai “tidak akan dilaksanakan”. Tapi itu masih tempat yang bagus untuk membahas _bagaimana_ kita ingin merombak perintah install, saya kira.

OTOH, mungkin kami menutup ini karena ditolak, dan seseorang membuka masalah baru, dengan proposal konkret tentang bagaimana mereka menyarankan perintah instal harus dimodifikasi. Setidaknya bisa memberikan titik awal yang lebih jelas untuk diskusi.

Pertanyaan. Adakah yang berpikir kita berada pada titik di mana seseorang dapat mengumpulkan perilaku yang diusulkan lengkap dari semua saran di sini dan di tempat lain? Mencakup bagaimana dependensi ditangani, apa yang terjadi dengan kendala (dan ketika mereka bertentangan), biner vs sumber, bagaimana kami mendukung skenario "upgrade semua", dll? Perasaan pribadi saya adalah bahwa kita membutuhkan seseorang untuk membuat keputusan itu, untuk memberikan diskusi sebuah titik referensi, atau kita hanya bisa memperdebatkan detail selamanya. Saya mungkin bisa melakukan itu, tetapi saya tidak mungkin dapat mengimplementasikan apa yang saya usulkan (misalnya, saya akan mengusulkan pendekatan "resolusi ketergantungan optimal", yang menyiratkan AIUI pemecah SAT). Jadi akan lebih baik bagi seseorang yang bersedia untuk mengimplementasikan proposal mereka untuk melangkah (dan menghadapi perdebatan tak terelakkan dan bikeshedding :-)).

Saya masih khawatir tentang beberapa implikasi dalam poin-poin yang dibuat di sini, tetapi saya tidak yakin saya memiliki energi untuk memperdebatkannya sampai ada kemungkinan implementasi yang nyata.

Saya sepenuhnya setuju dengan @dstufft terbaru https://github.com/pypa/pip/issues/59#issuecomment -224341218
Itu sebabnya (sekali lagi) saya menganjurkan solusi sederhana dari opsi --eager / --non-eager .

Saya juga setuju dengan komentar @dstufft , seperti yang disebutkan (kami menggunakan satu perintah install dan tidak ada perintah update ).

Namun, saya tidak yakin apa yang dimaksud dengan --eager / --non-eager . Saya kira --non-eager berarti jangan memutakhirkan apa pun yang tidak harus diperbarui (baik karena pengguna menentukannya secara eksplisit, atau karena terlalu tua untuk memenuhi set dependensi baru). Apakah --eager berarti meningkatkan setiap ketergantungan ke versi terbaru yang memungkinkan, apakah perlu atau tidak? Yang mana yang akan menjadi default? (Saya akan berdebat untuk --non-eager )

Dan sebuah pertanyaan - apakah ini akan mendorong paket ilmiah untuk mendeklarasikan dependensinya dengan benar? Itu harus menjadi pertimbangan penting.

Titik gudang sepeda. Nama opsi --eager dan --non-eager cukup tidak intuitif. Saya pikir kita perlu istilah yang lebih baik. Mungkin sesuatu yang eksplisit seperti --upgrade-dependencies .

PR ini juga menyarankan perintah upgrade-all , yang merupakan kasus penggunaan utama bagi saya. Apakah Anda mengatakan bahwa kami menolak perintah itu, atau hanya bahwa Anda tidak memiliki pendapat tentang itu?

Pemahaman saya tentang arti --eager dan -non-eager cocok dengan apa yang baru saja dikatakan --non-eager seharusnya default. Saya juga setuju namanya agak payah meskipun saya tidak punya solusi yang lebih baik yang tidak seteguk. Mungkin --[no-]recursive atau sesuatu, saya tidak tahu.

Saya pikir sesuatu seperti perintah upgrade-all bisa menjadi tambahan yang bagus (selama itu memastikan untuk tidak melanggar penentu versi apa pun). Saya mungkin akan menyebut ini upgrade dan membiarkannya tanpa argumen untuk membatasi operasinya.

tl; dr
Diskusi untuk upgrade-all-packages - tetap di sini.
Diskusi untuk prefer-biner - Ke #3785
Diskusi untuk install-as-upgrade - Ke #3786

Jika kami memiliki opsi --prefer-binary, yang mengatakan "hanya gunakan binari, kecuali itu berarti tidak ada kandidat, dalam hal ini coba lagi mengizinkan sumber"

Ini ide yang bagus. Sementara terkait dengan masalah ini, saya pikir itu layak untuk masalah itu sendiri. ( Komentar @dstufft membuat saya berpikir ada minat untuk mengejarnya). Saya memberanikan diri untuk membuka #3785 untuk diskusi lebih lanjut tentang ini.

Pemahaman saya tentang arti --eager dan -non-eager cocok dengan apa yang baru saja dikatakan

Pemutakhiran yang bersemangat akan menginstal versi terbaru yang diizinkan dari semua (sub-) dependensi. (sub-) hanya jika tidak lagi memenuhi persyaratan sebuah paket.

Nama opsi --eager dan --non-eager cukup tidak intuitif.

Saya setuju. Saya suka gagasan menempatkan perilaku di belakang satu bendera.
--upgrade-strategy=eager/non-eager

Ini suap juga tapi itu menyampaikan maksud lebih eksplisit. Apakah terlalu bertele-tele? Mungkin.

Saya pikir pelepasan sepeda paling baik dilakukan setelah menyelesaikan semantik.

Adakah yang berpikir kita berada pada titik di mana seseorang dapat mengumpulkan perilaku yang diusulkan lengkap dari semua saran di sini dan di tempat lain?

Aku pikir begitu. Kami, setidaknya, perlu menetapkan beberapa fakta dasar yang kami sepakati. aku di ini.

OTOH, mungkin kami menutup ini karena ditolak, dan seseorang membuka masalah baru, dengan proposal konkret tentang bagaimana mereka menyarankan perintah instal harus dimodifikasi. Setidaknya bisa memberikan titik awal yang lebih jelas untuk diskusi.

Saya pikir kita harus membiarkan masalah ini terbuka untuk saat ini, karena ini mengusulkan upgrade-all . Anda telah mencatat bahwa peningkatan tidak terjadi. Saya membuka #3786 untuk diskusi lebih lanjut tentang perintah install-as-upgrade.

Saya masih khawatir tentang beberapa implikasi dalam poin-poin yang dibuat di sini, tetapi saya tidak yakin saya memiliki energi untuk memperdebatkannya sampai ada kemungkinan implementasi yang nyata.

Saya bersedia untuk meneruskan ini sampai ke implementasi. Saya pasti tidak ingin menyia-nyiakan upaya orang lain untuk mencapai konsensus tentang hal ini.

Saya pikir semua orang setuju bahwa perintah 'upgrade the world' akan sangat bagus untuk dimiliki, tetapi IIUC itu diblokir sementara kami menunggu resolver bekerja. Sementara itu, saya memposting proposal yang lebih konkret untuk peningkatan paket tunggal pada edisi khusus baru @pradyunsg untuk diskusi itu.

Saya pikir semua orang setuju bahwa perintah 'upgrade the world' akan sangat bagus untuk dimiliki, tetapi IIUC itu diblokir sementara kami menunggu resolver bekerja.

Memang masalah ini sekarang diblokir dengan benar oleh #988. Menyebutkan nomor masalah untuk menghubungkan dua masalah.

Saya hampir lupa...

Saya tidak yakin apa yang Anda maksud tentang "menahan" pembaruan. Mohon klarifikasi.

Sekarang masalah ini khusus untuk peningkatan-semua, saya harus mengklarifikasi.

Mungkin ada beberapa situasi di mana mungkin berguna untuk mencegah pemutakhiran paket tertentu saat kami menjalankan pemutakhiran semua. Yang spesifik yang ada dalam pikiran saya adalah... Jika pkg diinstal dan saya tidak ingin repot mengonfigurasi ulang versi potensial yang lebih baru, jadi, saya ingin mencegah pip memutakhirkan paket spesifik itu saat menjalankan 'upgrade the dunia'. Pada dasarnya saya menahan peningkatan pkg.

Bendera yang mengambil daftar paket yang dipisahkan koma untuk menahan dari pemutakhiran akan baik-baik saja.

Menambahkan ini setelah pemecah SAT datang seharusnya mudah. Ini hanya beberapa klausa tambahan IIUC. (Ya, saya juga mempelajari pemecah SAT)

Saya tidak tahu apakah ini sesuatu yang umum atau sesuatu yang diinginkan seseorang. Tapi, saya tidak berpikir ini berasal dari kepala saya. Seseorang pasti telah menyebutkannya di beberapa utas di suatu tempat.

Aku mengerti. Itu masuk akal, dan sepertinya hal yang wajar untuk diinginkan.

Permintaan cepat: Bisakah seseorang menambahkan ke deskripsi catatan kecil bahwa perintah pemutakhiran tidak akan terjadi? Mungkin jika Anda mau, tulislah ringkasan kecil mengapa demikian.

_{_pergi tidur_}

Dua fitur bagus yang dimiliki apt (dan saya pikir manajer paket sistem dewasa lainnya seperti dnf memiliki fitur serupa):

• Menandai sebuah paket sebagai "dipegang", yang merupakan flag persisten yang melekat pada paket dan menyebabkannya dilewati oleh perintah upgrade-the-world. Sering diatur pada paket yang harus Anda turunkan atau tambal secara lokal.
• Pelacakan paket mana yang diminta secara eksplisit oleh pengguna, versus paket mana yang hanya diinstal secara implisit untuk memenuhi batasan ketergantungan. Yang terakhir dapat dihapus oleh peningkatan dunia jika mereka berhenti bergantung.

Kedua hal ini dapat dilihat sebagai kasus khusus dari hal yang dilakukan oleh manajer paket lingkungan proyek yang lebih baru seperti npm dan kargo, di mana mereka membedakan antara semacam file "persyaratan" yang berorientasi pada manusia versus file "kunci" yang ditentukan sepenuhnya. Paket yang dipegang secara eksplisit seperti paket yang memiliki batasan versi yang ditentukan manusia, dan paket yang saya instal secara eksplisit adalah paket yang tercantum dalam file yang dapat diedit manusia.

Dito. Jika kita menambahkan 'upgrade the world', kita perlu menambahkan kemampuan untuk menandai paket (sebagai held / user-installed dan mungkin lebih) untuk menambahkan informasi guna menentukan tindakan dengan lebih baik upgrade. Saya melihat ini sebagai persyaratan, bukan sebagai hal yang baik untuk dimiliki.

Saya sebenarnya suka teknik yang digunakan oleh Cargo dan suka. Penggunaan file dan bukan beberapa bentuk meta-data-hidden-behind-a-cli-command membuatnya lebih mudah untuk dipahami, dikelola, dan juga memungkinkan untuk menciptakan lingkungan yang dapat direproduksi.

Saya sebenarnya akan senang jika saya melihat beberapa bentuk pyproject.lock ...

komentar ke-200. Wow. :senyum:

Menambahkan referensi ke #654 untuk "menandai" paket yang kita bicarakan.

Bisakah Anda menjelaskan apa yang dilakukan kargo? Di mana Anda akan melihat file pyproject.lock disimpan di mesin pengguna?

Lockfile Rust's Cargo disimpan di root proyek, untuk merekam versi dependensi yang saat ini diinstal. Mengkomit file ini ke git memungkinkan Anda berbagi set versi ketergantungan yang konsisten dengan pengembang dan CI lain. Komposer PHP memiliki file kunci yang serupa, Komposer.lock.

Saya selalu berasumsi bahwa 'pip freeze' dan 'pip install -r' pip dimaksudkan untuk melakukan hal serupa, dan sangat disayangkan bahwa format file kunci mudah dibaca/ditulis oleh manusia dan orang memilih untuk mengeditnya secara langsung. Apakah requirements.txt awalnya tidak dianggap sebagai file kunci?

@triplepoint Terima kasih atas penjelasannya. Itu memang terdengar lebih seperti file persyaratan. Tetapi file persyaratan bersifat opsional, berbasis versi, dan per proyek. Menandai (seperti yang saya pahami) harus per lingkungan (virtualenv atau instalasi sistem) dan cukup katakan "jangan tingkatkan otomatis paket X" (tetapi izinkan pemutakhiran manual jika pengguna secara eksplisit meminta pemutakhiran paket itu dengan nama).

Untuk membantu menguraikan diskusi tentang upgrade-all dan "perilaku peningkatan", berikut adalah komentar dari @rbtcollins dan @ncoghlan dalam diskusi pada daftar yang terakhir tentang pemecah SAT yang tidak diperlukan untuk implementasi pertama upgrade-all :

Robert:

Saya menyadari konsensus pada tiketnya adalah bahwa itu diblokir, tetapi saya tidak
sebenarnya setuju.

Ya, Anda tidak dapat melakukannya _right_ tanpa resolver penuh, tetapi Anda dapat melakukannya
perkiraan yang akan jauh lebih baik daripada tidak sama sekali (hanya sempit
penentu yang diberikan di semua persyaratan). Itu sebenarnya
masuk akal ketika Anda berurusan dengan serangkaian versi yang dianggap baik
(instal mana yang tidak berurusan dengan).

panggilan:

"yum upgrade" telah bekerja cukup baik selama bertahun-tahun tanpa pemecah SAT yang tepat, dan paket yang diatur dalam instalasi Linux biasa jauh lebih besar daripada di lingkungan virtual biasa (walaupun kurasi distro mengurangi kemungkinan persyaratan yang saling bertentangan yang muncul di awal tempat).

Yang mengatakan, menjalankan kembali pip-compile dan kemudian melakukan pip-sync sudah setara fungsional dari operasi upgrade-all (seperti menghancurkan dan membuat ulang venv), jadi saya setuju tidak perlu memasangkan pertanyaan tentang mendukung peningkatan massal di pip dasar dengan mengubah perilaku memutakhirkan komponen bernama.

IMO, pip upgrade-all sejauh ini merupakan proposal terpenting dari semua diskusi "fungsionalitas peningkatan". Memiliki "upgrade semua" akan memberikan cara yang jelas untuk menjaga sistem Anda tetap mutakhir, membuat pertanyaan tentang pembaruan yang tidak diinginkan membuat hal-hal di tingkat yang lebih lama jauh lebih tidak mendesak, serta mengisi celah yang ada saat ini.

Sementara pemecah penuh akan menyenangkan, saya tidak melihat alasan mengapa titik awal untuk pip upgrade-all seharusnya tidak melakukan apa yang dilakukan pip install -U <list every package that's installed here> . Itulah yang saya harapkan sebagai pengguna, dan untuk sebagian besar kasus itu melakukan persis apa yang dibutuhkan. Kasus sudut kompleks di sekitar persyaratan yang saling bertentangan dapat ditangani dalam contoh pertama dengan mengacu pada hal di atas. Jika itu tidak cukup, maka kita dapat melihat baik memodifikasi perilaku install -U untuk mengatasinya, atau membuat casing khusus perintah update-all , atau bahkan mengimplementasikan pemecah penuh pada saat itu.

Apakah Anda akan menerapkan ini dalam 10 tahun ke depan?

FWIW, saya akan mengunjungi kembali ini, akhir pekan ini.

@magicgoose berkata:
Apakah Anda akan menerapkan ini dalam 10 tahun ke depan?

@pfmoore mengatakannya lebih baik daripada yang saya bisa:

Kami sadar bahwa orang menginginkan ini, yang kurang adalah siapa pun yang mau mengembangkan perbaikan yang memenuhi semua berbagai masalah dan masalah yang telah diangkat, dan yang pasti akan muncul selama tinjauan PR.

Jadi secara pribadi, saya akan menghargai jika orang menahan diri untuk tidak mem-ping masalah ini kecuali mereka memiliki kode kerja yang setidaknya menawarkan titik awal untuk implementasi - dan mereka bersedia mengikutinya hingga implementasi.

sepenuhnya pendapat pribadi

saya pikir pada dasarnya pip (yang menginstal paket dari repo yang tidak memiliki QA global seperti katakanlah debian, redhat atau ubuntu)
saya merasa perlu dan/atau dapat diterima untuk benar-benar menahan diri dari mengimplementasikan dan memperbarui semua fungsi,

karena kami pip pernah menjamin status yang diketahui dari kumpulan paket python yang dapat diinstal

@RonnyPfannschmidt IMO sangat masuk akal bagi pengguna pip untuk secara eksplisit melarang penggunaan perintah update-all, jika itu sesuai dengan persyaratan/alur kerja mereka. Tetapi tidak semua pengguna pip memiliki persyaratan ketat yang sama dengan orang-orang ini. Untuk pengguna dengan kebutuhan yang lebih santai, perintah update-all berguna, dan kekurangannya membuat mereka secara signifikan lebih sulit untuk menjaga sistem mereka "up to date". Jadi saya pikir masuk akal jika pip memberikan perintah seperti itu. Adalah tugas kami untuk menyediakan alat yang dibutuhkan orang, bukan untuk menegakkan kebijakan tertentu tentang cara pengguna memilih untuk menggunakan alat tersebut.

@pfmoore pengalaman pribadi saya dengan hanya memperbarui semua paket di lingkungan, itu merusak banyak hal ^^

pengguna yang membutuhkan pembaruan santai semua terdengar seperti yang Anda maksud pengguna akhir normal (yang seharusnya hanya menggunakan distribusi linux normal misalnya)

Apakah upgrade-all bermasalah atau tidak tergantung _lot_ pada berapa banyak dependensi yang Anda miliki, dan seberapa baik disiplin mereka tentang pemeliharaan API mereka. Itu juga dapat digunakan bersama dengan repositori pribadi yang dikuratori untuk mendapatkan kontrol atas peningkatan apa yang sebenarnya terjadi, daripada harus dengan hati-hati mengonfigurasi perintah peningkatan mana yang Anda jalankan di setiap lingkungan virtual.

@RonnyPfannschmidt Pengguna Windows masih melebihi jumlah pengguna Linux ~ 18 banding 1, dan mereka tidak memiliki apa pun yang sebanding dengan komunitas manajemen paket distro untuk kembali pada saat ini (sementara teknologi inti ada di versi terbaru, komunitas pengemasan dan kurasi tidak). Itu berarti mereka jauh lebih bergantung pada alat tingkat pengguna seperti pip dan conda untuk mengatasi kekurangannya.

Kami sadar bahwa orang menginginkan ini, yang kurang adalah siapa pun yang mau mengembangkan perbaikan yang memenuhi semua berbagai masalah dan masalah yang telah diangkat, dan yang pasti akan muncul selama tinjauan PR.

@pfmoore apakah Anda sadar bahwa komentar seperti itu dapat dianggap merendahkan upaya kontributor? Itulah yang terlihat bagi saya. Saya tidak yakin apakah Anda mengikuti seluruh sejarah masalah ini, tetapi dalam kasus khusus ini Anda sangat menyimpang. Masalahnya lebih banyak dengan tim pengembangan pip daripada dengan kontributor mana pun.

Ringkasan kasar hanya sebagian saja (PR gh-3194):

1. Ada keputusan terdokumentasi bahwa perintah upgrade diterima (di milis pip serta dokumen dan GitHub).
2. Kemudian panggilan keluar oleh pengembang terkemuka ( @njsmith dalam hal ini) bahwa mengimplementasikan fitur ini akan menjadi sangat berharga.
3. Kontributor baru muncul, mengimplementasikan segalanya, menangani semua komentar ulasan dengan cepat. PR siap digabung.
4. Kontributor inti berubah pikiran tentang menginginkan upgrade .
5. Diskusi yang sangat panjang mengikuti, tanpa kesimpulan.
6. Kontributor menyerah dan menghilang (kebanyakan orang akan, hal-hal seperti itu membuat frustrasi).

Dan itu bahkan sebelum @pradyunsg muncul, yang menunjukkan kegigihan yang luar biasa.

Dalam proyek yang berfungsi dengan baik, pengembang inti yang benar-benar peduli dengan masalah ini akan mengatur hangout cepat dan membuat semacam keputusan. Atau delegasikan satu atau dua orang untuk mengerjakannya cukup untuk mendapatkan kesimpulan itu. Atau setidaknya minta maaf dan ucapkan terima kasih kepada pengirim PR, alih-alih menyalahkan dia karena "tidak menindaklanjuti".

Saya tahu Anda memiliki niat baik, tetapi harap lebih berhati-hati dengan komentar semacam ini.

Saya pikir sangat masuk akal jika persyaratan dan pendapat berubah melalui diskusi, terutama untuk masalah pelik seperti ini di mana tidak ada jawaban yang benar. Bagian dari mendapatkan tambalan yang mendarat di basis kode apa pun adalah mengikuti perubahan yang dikeluarkan sebagai bagian dari tinjauan dan diskusi seputar perubahan apa pun. Beberapa perubahan cukup minimal dan memiliki lebih sedikit, beberapa memiliki lebih banyak. Tidak ada yang salah dengan seseorang yang memutuskan bahwa mereka tidak ingin berurusan dengan itu dan keluar (setiap bilah untuk menambahkan perubahan akan menyebabkan sejumlah penurunan, termasuk tes, dokumentasi, dll).

Perubahan khusus ini sangat buruk karena mengubah perilaku default dari penggunaan utama pip. Itu sulit dan menakutkan dan akan merugikan pengguna kami jika kami terburu-buru dan tidak menyelesaikan masalah sebelum berkomitmen ke satu arah atau yang lain. Perintah ini digunakan 10 hingga 100 juta kali sebulan. Ini bukan perubahan kecil dan mudah dan bukan orang-orang yang melakukan ping masalah ini yang harus menghadapi reaksi marah yang datang dari membuat perubahan apa pun.

Orang yang melaksanakan PR sebelumnya, waktu mereka dihargai, tetapi faktanya mereka tidak menindaklanjuti sampai akhir. Karena waktu _our_ developer inti di sini terbatas, kami adalah sukarelawan atau tersebar di antara banyak proyek dan kami mengambang masuk dan keluar dari partisipasi. Ada banyak masalah berbeda yang semuanya membutuhkan perhatian dan ini hanya salah satunya. Paul hanya menyatakan bahwa ping masalah ini tidak membantu (yang tidak) dan bahwa jika seseorang menginginkannya, mereka harus menunggu seseorang (termasuk salah satu pengembang inti) memutuskan untuk melakukan upaya yang cukup besar untuk mengubah perilaku default jutaan atau melakukannya sendiri.

Kami sadar bahwa orang menginginkan ini, yang kurang adalah siapa pun yang mau mengembangkan perbaikan yang memenuhi semua berbagai masalah dan masalah yang telah diangkat, dan yang pasti akan muncul selama tinjauan PR.

@pfmoore apakah Anda sadar bahwa komentar seperti itu dapat dianggap merendahkan upaya kontributor? Itulah yang terlihat bagi saya. Saya tidak yakin apakah Anda mengikuti seluruh sejarah masalah ini, tetapi dalam kasus khusus ini Anda sangat menyimpang.

@rgommers Serius? Komentar itu berasal dari beberapa bulan yang lalu, dan dikutip di luar konteks di sini (tapi terus terang, saya tidak punya masalah dengan @pradyunsg mengutipnya sebagai tanggapan atas komentar yang tidak membantu dan sarkastik yang dia balas). Saya menyarankan bahwa jika Anda meninjau seluruh sejarah, Anda akan melihat komentar saya dalam konteks, di mana semoga Anda akan mengerti apa yang saya coba katakan.

Jika saya adalah "off-base", maka Anda bisa mengatakannya pada bulan Mei pada saat saya mengatakannya, daripada mengambilnya sekarang, di luar konteks.

Jika saya menyinggung siapa pun, saya minta maaf, itu bukan maksud saya. Sejujurnya, saya sama frustrasinya dengan orang lain karena masalah ini terbukti sangat sulit untuk mencapai desain yang dapat diterima semua orang. Dalam komentar saya, saya mencoba untuk menyeimbangkan - di satu sisi, saya benar-benar menghargai kontribusi yang diberikan orang, tetapi di sisi lain, saya merasa penting untuk menjelaskan kepada orang-orang bahwa dalam masalah seperti ini, coding sejujurnya adalah pekerjaan yang paling sedikit dibutuhkan. Sangat sering, kontributor tidak menghargai fakta ini, dan di situlah kami mendapatkan PR yang tidak lengkap, di mana orang menjadi frustrasi dengan pekerjaan yang diperlukan untuk meyakinkan orang bahwa desain mereka baik-baik saja, dan/atau mengerjakan ulang perubahan, mungkin dengan cara yang tidak mereka lakukan' t sangat suka, untuk mempertimbangkan pandangan orang lain (sering bertentangan dan tidak konsisten!). Saya lebih suka mereka datang ke dalam proses dengan pemahaman tentang apa yang terlibat, daripada datang dengan harapan yang tidak realistis dan sebagai hasilnya memiliki pengalaman buruk.

Semua orang yang terlibat dalam diskusi tentang masalah ini telah menghabiskan _banyak_ waktu untuk memperdebatkan pro dan kontra dari berbagai pendekatan. Saya tidak membayangkan ada orang yang senang dengan berapa lama waktu yang dibutuhkan. Secara pribadi, kurangnya perintah upgrade-all (hanya satu bagian dari perubahan, dan tidak mungkin menjadi yang diimplementasikan terlebih dahulu) memukul saya secara teratur. Kami kadang-kadang (jujur, ini lebih dari sekadar "sesekali") membuat orang (biasanya orang yang belum benar-benar berkontribusi pada diskusi atau kode) berkomentar "ini penting, mengapa Anda belum mengimplementasikannya?" Terus terang, sulit untuk tetap tenang dan _tidak_ membentak orang seperti itu.

Dalam proyek yang berfungsi dengan baik, pengembang inti yang benar-benar peduli dengan masalah ini

Anda menyadari bahwa komentar ini terbuka untuk ditafsirkan sebagai mengatakan bahwa pengembang pip tidak peduli untuk memperbaiki ini (dan implikasinya tentang pip)? Kita semua berisiko mengucapkan kata-kata dengan cara yang dapat menyinggung orang. Saya yakin Anda tidak bermaksud ini sebagai kritik terhadap pengembang pip, harap anggap saya sama-sama tidak mencoba menyinggung siapa pun.

akan mengatur hangout cepat dan membuat semacam keputusan.

Saya akan terkejut jika sesuatu seperti itu akan berhasil di sini, tetapi saya terbuka untuk mencobanya. Tidak yakin siapa yang akan terlibat atau bagaimana kami akan mengelolanya, tapi pasti, jika itu membantu dan seseorang ingin mencoba pendekatan itu. Saya akan mengatakan bahwa, karena perubahan ini memiliki potensi besar untuk memengaruhi pengguna pip, setiap keputusan yang dibuat pada saluran pribadi seperti ini mungkin harus ditulis sebagai proposal dan dipublikasikan untuk komentar umum - dan saya menduga hal itu hanya akan memicu putaran lain dari perdebatan yang sama yang telah kita alami.

Atau delegasikan satu atau dua orang untuk mengerjakannya cukup untuk mendapatkan kesimpulan itu.

Jadi maksudmu keputusan sebesar ini harus dibuat secara sepihak oleh beberapa orang? Mungkin itu satu-satunya cara kita akan mendapatkan resolusi, tapi sebenarnya bukan bagaimana keputusan dibuat di pip (tidak seperti Python, kita tidak memiliki BDFL dengan otoritas pengambilan keputusan eksekutif). Anda dapat mengklaim bahwa membuat kami bukan "proyek yang berfungsi dengan baik" jika Anda mau, itu bukan pandangan saya, tetapi kami dapat tidak setuju jika Anda mau.

Atau paling tidak minta maaf dan ucapkan terima kasih kepada PR submitter,

Saya tidak yakin apa yang harus kami minta maaf, tetapi jika itu membantu maka saya akan dengan senang hati meminta maaf - untuk fakta bahwa tidak ada yang memberinya pemahaman yang jelas tentang betapa sulitnya menyelesaikan proposal ini, atau membantunya mengelola debat dan membimbing peserta mencapai konsensus. Tapi untuk bersikap adil, saya tidak berpikir orang _lain_ yang terlibat tahu pada saat ini bahwa ini akan terjadi, jadi saya pikir itu terutama berbicara di belakang.

Dia tentu saja berterima kasih. Agak mudah untuk mengatakan "tidak perlu dikatakan", tetapi seharusnya tidak - proyek open source tidak cukup berterima kasih kepada kontributor, dan itu masalah. Sementara saya membahas masalah ini, saya ingin berterima kasih kepada _semua orang_ yang berkontribusi pada debat ini - dan saya benar-benar serius di sini - seperti yang saya tahu dari pengalaman betapa melelahkannya hal itu. Tapi khusus untuk @pradyunsg karena menjadi korban saat ini dari semua diskusi dan perubahan arah yang tak ada habisnya. Terima kasih untuk tidak menyerah! (Belum!!)

bukannya menyalahkan dia karena "tidak menindaklanjuti".

Yah, saya tidak berpikir ada kesalahan yang melekat (walaupun sulit untuk mengetahui apakah dia merasa disalahkan, karena dia tidak ada lagi). Tetapi memang benar bahwa PR aslinya tidak berhasil sampai selesai. Itu hanya fakta. Saya harap tidak ada yang menyarankan bahwa kontributor berhak agar PR mereka diterima _hanya karena mereka mengirimkannya_. Tidak semua PR dapat diterima saat pertama kali diajukan, PR perlu direvisi dan diperbarui, dan terkadang bahkan setelah semua pekerjaan mereka _masih_ tidak dapat diterima. Maaf, tapi itulah hidup.

[Jika saya terkesan kasar dalam pernyataan di atas, saya minta maaf (sekali lagi!). Tetapi banyak waktu luang saya dihabiskan untuk membaca dan menangani keluhan bahwa saya (atau proyek yang saya terlibat) entah bagaimana belum cukup. Dan ini adalah lingkaran setan - saya kehilangan motivasi untuk mengerjakan open source di waktu luang saya karena omelan, yang tentu saja berarti semakin sedikit yang selesai. Sementara saya mencoba untuk tetap sopan, terkadang itu tidak mudah]

Saya tidak berencana untuk mengatakan lebih jauh tentang meta-diskusi ini tentang bagaimana PR dikelola. Saya telah menghabiskan satu jam malam ini mengerjakan respons ini, untuk mencoba menghindari mengatakan apa pun yang mungkin menyinggung perasaan seseorang (dan saya yakin saya gagal :-(). Dan saya bisa menghabiskan waktu itu dengan lebih baik - dengan keluarga saya, bersantai, atau melakukan sesuatu yang lebih produktif.

Jadi bisakah saya menyarankan agar kita kembali mencoba membantu @pradyunsg membuat PR yang bisa membuat kita semua senang, dan meninggalkan meta-diskusi yang sia-sia?

Jadi bisakah saya menyarankan agar kita kembali mencoba membantu @pradyunsg membuat PR yang bisa membuat kita semua senang, dan meninggalkan meta-diskusi yang sia-sia?

Ya silahkan. :polos:

Oh saya lupa.

@rgommers berkata:
Dan itu bahkan sebelum @pradyunsg muncul, yang menunjukkan kegigihan yang luar biasa.

Saya akan menganggap ini sebagai pelengkap... Terima kasih.

@pfmoore berkata:
terutama kepada @pradyunsg karena menjadi korban saat ini dari semua diskusi dan perubahan arah yang tak ada habisnya. Terima kasih untuk tidak menyerah!

Terima kasih kembali.

(Belum!!)

Saya sangat berharap itu tidak sampai ke keadaan itu. Ini akan menjadi keadaan yang sangat buruk jika itu terjadi, IMO. (Saya sombong seperti itu)

Saya menulis yang berikut ketika saya sedang meninjau sejarah dan berpikir mungkin juga meletakkannya di sini, untuk referensi di masa mendatang dan membiarkan orang lain mengoreksi saya untuk berjaga-jaga.

• Memutuskan untuk mengerjakan ini setelah menyadari betapa besarnya rasio non- teknis:teknis (Ini jauh lebih besar daripada yang saya _benar-benar_ pikirkan secara konservatif) dan menyadari bahwa telah ada upaya yang gagal dalam hal ini.
• Melakukan penulisan tentang keadaan, karena saya bosan dan saya perlu tahu apa yang terjadi.
  
  
  
  • Mungkin menghabiskan lebih banyak waktu (dan ruang di sini?) daripada yang dibutuhkan, tetapi setidaknya saya mendapat gambaran yang baik tentang masalah ini untuk diri saya sendiri (dan orang lain?).
  
  
• Terlalu bersemangat setelah menulisnya. :smiley: Tunjukkan pada dunia!
• Memulai diskusi (panjang!!!) tentang penerapan perintah pemutakhiran.
  
  
  
  • Beberapa ide off-shoot yang berguna muncul dalam diskusi. Masalah baru dibuat untuk hal yang sama.
  
  
• Diskusi mengarah pada gagasan untuk mengubah perilaku pemasangan menjadi pemasangan, yang akan melakukan peningkatan yang tidak bersemangat secara default dan menghapus bagian dari fungsionalitas yang disediakan oleh opsi --target - 3 hal.
  
  
  
  • Di sinilah kami membuat kesalahan - menggabungkan 3 (cukup) perubahan independen dan yang akan diimplementasikan sebagai satu, karena tidak ada yang menyadari bagian ini.
  
  
• Saya menerapkan hal yang sama. Karena 3 perubahan digabungkan, semuanya macet ketika tidak ada konsensus untuk mengubah perilaku pemasangan menjadi upstall, perubahan yang berpotensi kontroversial.
• Kurangnya konsensus memulai diskusi panjang yang sampai pada titik di mana orang-orang mundur dari diskusi dan saya kira hampir terdorong ke kelelahan.
  
  
  
  • Beberapa asumsi sebelumnya rusak dan diputuskan bahwa kami akan melakukan perubahan gangguan minimal terlebih dahulu.
  
  
• Saya kehabisan waktu luang untuk mengerjakan ini, jadi saya membuat beberapa masalah baru sehingga orang lain dapat mengerjakannya secara mandiri dan idealnya tidak membuat kesalahan yang sama seperti yang kami lakukan di sini.
• terhenti.
• Saya kembali! Saya akan mencoba untuk beralih ke peningkatan yang tidak bersemangat secara default dilakukan pada 25 September.

Ya, mari fokus memperbaiki pip install --upgrade dan tinggalkan yang lainnya untuk saat ini. Itu persyaratan untuk pekerjaan lain.

@pfmoore @dstufft terima kasih atas balasan yang bijaksana. Saya tidak bermaksud menyinggung siapa pun, jadi mohon maaf jika terkesan seperti itu.

Saya tidak akan menanggapi semuanya, karena tidak ada yang mencari diskusi panjang di sini.

Anda bisa saja mengatakannya pada bulan Mei saat saya mengatakannya,

Saya jauh dari Github selama 2 bulan saat itu, tetapi itu mengganggu saya ketika saya melihat komentar itu pertama kali.

Jadi maksudmu keputusan sebesar ini harus dibuat secara sepihak oleh beberapa orang?

Semua opsi di atas meja jauh lebih baik daripada status quo. Dan setelah 5,5 tahun dan ratusan komentar tersebar di beberapa masalah/PR di sini dan milis, saya tidak yakin bahwa lebih banyak komentar akan menyelesaikannya. Saya harap ini akan diselesaikan, tetapi jika ini macet lagi maka pasti ya - pilih satu atau beberapa orang dan buat pilihan saja.

Saya tidak yakin apa yang harus kami minta maaf, tetapi jika itu membantu maka saya akan dengan senang hati meminta maaf - untuk fakta bahwa tidak ada yang memberinya pemahaman yang jelas tentang betapa sulitnya menyelesaikan proposal ini, atau membantunya mengelola debat dan membimbing peserta mencapai konsensus.

Maksudku yang terakhir. Terkadang saya berubah pikiran pada keputusan untuk salah satu proyek saya, itu terjadi. Kemudian saya merasa bertanggung jawab untuk memperjelas arah baru. Dan mohon maaf jika saya tidak punya waktu untuk menghadapi konsekuensi dari perubahan itu (hanya membutuhkan waktu 30 detik....).

Tetapi memang benar bahwa PR aslinya tidak berhasil sampai selesai. Itu hanya fakta.

Itu pandangan, bukan fakta. Dalam pandangan saya, PR sudah selesai - yang harus dilakukan hanyalah menekan tombol hijau atau menolaknya. Dia melakukan semua yang saya harapkan dari seorang kontributor.

Saya menyadari setelah balasan Anda bahwa harapan yang dimiliki pengembang pip dari kontributor dan pengembang inti sangat berbeda dari hampir semua proyek lain yang saya kenal. Saya mengharapkan pengembang inti untuk memandu kontributor baru, mendorong mereka, memberi mereka umpan balik jika diperlukan, dan membantu mereka menyelesaikan masalah kontroversial (yang sebagian besar kontributor tidak memiliki keterampilan atau minat, dan mereka yang sering berakhir menjadi pengembang inti) jika diperlukan. Anda mengatakan kepada kontributor baru: _"Anda harus mengelola kami. kami dapat berubah pikiran, tidak setuju satu sama lain, atau kehilangan minat - tugas Anda untuk mengelolanya"_. Mungkin itulah sifat dari proyek ini dan harus seperti ini, saya tidak tahu.

Sementara saya membahas masalah ini, saya ingin mengucapkan terima kasih kepada semua orang yang berkontribusi pada debat ini

Sepakat. Terima kasih untuk semua orang yang berkontribusi.

• dan saya benar-benar serius di sini - seperti yang saya tahu dari pengalaman betapa menguras tenaga.

Hal ini menguras. Secara pribadi, saya tetap di sini dan di distutils-sig karena ini penting untuk ekosistem Python dan pengguna paket saya, tetapi kedua tempat itu tidak benar-benar memberi saya energi positif.

Untuk berjaga-jaga jika itu menyelinap di bawah radar - #3972 :smile:

Anda mengatakan kepada kontributor baru: "Anda harus mengelola kami. Kami dapat berubah pikiran, tidak setuju satu sama lain, atau kehilangan minat - tugas Anda untuk mengelolanya". Mungkin itulah sifat dari proyek ini dan harus seperti ini, saya tidak tahu.

Saya mengatakan saya tidak akan melanjutkan ini, tetapi poin ini berhasil. Bukan itu yang saya rasakan tentang pendekatan kami, tetapi sekarang setelah Anda mengatakannya seperti itu, saya melihat bahwa itu bisa menjadi seperti itu. Sejujurnya "kita mungkin berubah pikiran, tidak setuju satu sama lain, atau kehilangan minat" adalah benar - lagipula kita semua hanya orang dengan komitmen lain juga - tapi saya tidak menganggapnya sebagai sesuatu yang harus dilakukan oleh kontributor baru. "mengelola". Sebaliknya, itu hanya kenyataan berurusan dengan orang-orang, tetapi jika membuat terlalu banyak muncul sebagai membuang masalah pada kontributor baru, itu salah.

Terima kasih telah menunjukkan hal ini - saya akan mencoba mengingatnya dan menghindari memberi kesan itu di masa mendatang.

Saya pikir banyak masalah yang benar-benar bermuara pada fakta bahwa kami sangat kekurangan awak yang akhirnya membuat sulit untuk mengikuti dan menindaklanjuti segala sesuatu. Ada lebih banyak kontributor potensial daripada kita sehingga mudah merasa kewalahan ketika ada banyak orang yang mencoba membuat perubahan sekaligus. Perubahan yang lebih besar, atau perubahan di mana tidak ada konsensus yang jelas, cenderung menjadi yang paling sulit untuk dihadapi sehingga merekalah yang cenderung paling menderita :(

Keadaan yang menyedihkan adalah bahwa sementara saya pikir kita semua ingin berada di sini untuk membantu membimbing melalui setiap kontributor melalui proses, kita tidak memiliki tenaga. Ini cenderung memiliki sedikit siklus kental juga, karena kami tidak memiliki tenaga untuk melakukan itu, kami tidak mudah menemukan orang baru yang tampaknya benar-benar mulai mempelajari mentalitas di balik cara kerja pip dan yang telah belajar cukup (karena kami tidak di sana untuk mengajari mereka) untuk memberi mereka hak komit untuk pip. Ini berarti kita terus-menerus diremehkan dan berjuang hanya untuk menjaga kepala kita tetap di atas air (Setidaknya, itulah yang saya rasakan. Konstan 70-90 jam seminggu sangat sulit bagi seseorang :/).

@pradyunsg Meninjau #3972 ada di daftar TODO saya, hanya belum mencapainya.

@pradyunsg Meninjau #3972 ada di daftar TODO saya, hanya belum mencapainya.

Terima kasih!

Ini berarti kita terus-menerus diremehkan dan berjuang hanya untuk menjaga kepala kita tetap di atas air (Setidaknya, itulah yang saya rasakan. Konstan 70-90 jam seminggu sangat sulit bagi seseorang :/).

Itu sulit. Numpy dan Scipy berada dalam situasi itu ketika saya mulai mengerjakannya. Tidak menyenangkan. Saya menghargai semua yang Anda lakukan.

Masalah ini sekarang sangat panjang dan sangat tua, banyak hal telah dibahas, terlalu banyak hal telah terjadi dan masalah ini hampir mencapai sinyal/noise rendah. Sulit untuk melihat apa yang telah terjadi.

FWIW, alasan upgrade ada di kartu adalah karena fakta bahwa install --upgrade memiliki default yang rusak. Karena kita sekarang selangkah lebih dekat untuk memperbaikinya, saya rasa sebaiknya kita memiliki masalah baru untuk itu.

Saya menyarankan agar masalah ini ditutup karena hal di atas dan masalah baru dibuat untuk apa pun di sini yang dianggap belum terselesaikan. Saya dapat melihat 2 hal:

• Geser strategi peningkatan versi default ke only-if-needed .
• Tambahkan fungsionalitas "upgrade the world" yang bergantung pada #988.

Pada 9/15/16, Nick Coghlan [email protected] menulis:

@RonnyPfannschmidt Pengguna Windows masih melebihi jumlah pengguna Linux ~18 banding 1, dan
mereka tidak memiliki apa pun yang sebanding dengan komunitas manajemen paket distro
untuk kembali pada titik ini (sementara teknologi inti ada di sana baru-baru ini
versi, komunitas pengemasan dan kurasi tidak). Itu berarti mereka
jauh lebih bergantung pada alat tingkat pengguna seperti pip dan conda untuk mengambil
kendur.

Bukankah kemudian?
pembaruan konda --semua
cukup baik?

@Liso77
Tidak. Tidak.

Conda dan pip adalah alat dengan tujuan yang berbeda. Ini adalah bacaan yang bagus tentang topik ini. Poin ke-3 adalah yang paling relevan.

Jika diskusi untuk peningkatan-semua muncul lagi (semoga dalam edisi baru) suara saya adalah untuk mengejanya sebagai berikut:

pip install --upgrade :all:

pip install --upgrade :all: sangat aneh. Mari tetap berpegang pada semantik POSIX, yang pada dasarnya dilakukan semua orang saat ini: pip install --upgrade --all

Bagaimana dengan hanya pip install --upgrade tanpa nama paket atau penentu? Untuk mudah dijalankan secara tidak sengaja?

pip-tools melakukannya seperti ini untuk pip-compile -P .

Mungkin kita harus bersepeda setelah kita bekerja
penerapan... :)

Pada hari Minggu, 12 Februari 2017, 20:55 FichteFoll [email protected] menulis:

Bagaimana dengan pip install --upgrade tanpa nama paket atau
penentu? Untuk mudah dijalankan secara tidak sengaja?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/pypa/pip/issues/59#issuecomment-279225595 , atau bisu
benang
https://github.com/notifications/unsubscribe-auth/ADH7SfnSBflH8rK3nFLw1hvYBaovjbcGks5rbyRUgaJpZM4AJ4Py
.

Bagaimana dengan versi pip list --outdated yang menghasilkan daftarnya dalam format yang dapat langsung (yaitu, tanpa sed , cut , dll.) diserap oleh pip install --upgrade (misalnya, pip list --outdated --format install | xargs pip install --upgrade atau yang serupa dengan backticks)?

sintaks apa pun yang akan digunakan, yang terpenting adalah memperkenalkan perintah ini, Sulit dipercaya bahwa masih ada yang hilang

sementara itu saya sarankan Anda untuk mencoba
https://github.com/jgonggrijp/pip-review
dengan pip-review --local --interactive meminta Anda paket demi paket jika Anda ingin memperbarui, tidak terlalu bagus tapi lebih baik daripada tidak sama sekali

@ SMH17 Sangat dapat dipercaya bahwa itu masih hilang, karena tidak ada vendor Python komersial yang secara resmi menyediakan waktu pengembangan yang didanai untuk mengerjakan peningkatan kegunaan pengemasan Python atas nama pelanggan mereka.

Jadi jika Anda ingin melihat situasinya membaik, kemungkinan hal paling bermanfaat yang dapat Anda lakukan secara pribadi adalah dengan mendorong vendor dukungan Python Anda untuk menginvestasikan waktu pengembang dalam meningkatkan alat yang Anda gunakan, atau jika Anda tidak memiliki dukungan vendor belum, mendorong majikan Anda untuk membayar satu.

Sebagai bagian tambahan dari konteks mengenai kurangnya urgensi seputar masalah ini, perlu diingat bahwa rekomendasi umum adalah untuk

• menjaga definisi lingkungan kerja Anda di bawah kendali sumber untuk meningkatkan reproduktifitas pada sistem lain (menggunakan sesuatu seperti https://github.com/jazzband/pip-tools atau https://github.com/kennethreitz/pipenv untuk menjaga agar definisi tersebut tetap mutakhir )
• bertujuan untuk secara rutin meningkatkan ke rilis baru dependensi untuk meminimalkan jendela eksposur ke kerentanan keamanan yang tidak diketahui atau tidak diungkapkan

Itu tidak berarti perintah yang diusulkan di sini tidak berguna, mereka hanya sangat kurang berharga jika lingkungan kerja saat ini sudah dipertahankan melalui pip-compile + pip-sync , atau pipenv lock + pipenv install .

Akan bermanfaat untuk memperbarui deskripsi asli karena saya kira telah ada beberapa perubahan yang dilakukan pada pip install sejak pembaruan dilakukan oleh @qwcode.

Halo semuanya.

Saya telah merusak beberapa dependensi paket python saya karena perintah berikut:

pip install --upgrade packageName telah memutakhirkan paket secara rekursif.

Mengapa tidak mengubah perilaku default opsi --upgrade , yaitu menghapus dan menginstal ulang HANYA paket yang diberikan dari baris perintah?

Bagaimana dengan ini ?

@sebma Saya pikir perilaku default tidak boleh diubah. Mungkin Anda bisa mencoba menggunakan flag -no-dependencies di lain waktu. Ini harus bekerja :+1:

@sebma , @aaossa , Saya ingin Anda berdua tahu bahwa sudah cukup banyak diputuskan bahwa strategi peningkatan default akan berubah di masa mendatang (ref: https://github.com/pypa/pip/issues/3871# issuecomment-247789343). Fitur yang diperlukan (yaitu argumen --upgrade-strategy ) telah ditambahkan di https://github.com/pypa/pip/pull/3972.

Seperti yang disebutkan @pradyunsg sebelumnya , masalah ini semacam sisa. Bagian pertama sudah ditangani sekarang (lihat paragraf pertama saya) dan bagian kedua adalah satu-satunya alasan mengapa paket ini masih terbuka, sepertinya. Saya tidak tahu apakah masalah "upgrade-semua" yang terpisah telah dibuat sejak itu.

Saya telah merilis pemutakhiran interaktif yang bagus untuk file persyaratan: https://github.com/simion/pip-upgrader

Ubah strategi peningkatan default menjadi hanya jika diperlukan.

4500 melakukan ini.

Tambahkan fungsionalitas "upgrade the world" yang bergantung pada #988.

4551 untuk diskusi tentang ini.

Mengatasi poin yang dibuat di posting teratas saat ini:

pip upgrade akan seperti pip install --upgrade kecuali itu akan menjadi non-rekursif secara default (dan menawarkan opsi --recursive). Perilaku default rekursif saat ini telah menyebabkan kesedihan bagi banyak orang (#304). Adapun cara melakukan upgrade non-rekursif sekarang, lihat di sini.

Telah diputuskan untuk tidak menambahkan perintah upgrade atau membuat pip install upgrade paket yang sudah diinstal. pip sekarang memang memiliki peningkatan non-rekursif secara default, dengan perilaku rekursif tersedia di belakang --upgrade-strategy eager .

pip upgrade-all akan memutakhirkan semua paket yang diinstal.

4551 ada dan akan menyenangkan untuk memiliki diskusi baru tentang ini; ketika #988 selesai.

@dstufft @xavfernandez @pfmoore Apakah ada di antara Anda yang berpikir masalah ini harus ditutup?

_{Sunting (18-05-2017): Tanda baca + teks kecil ditambahkan}

Tampaknya masuk akal.

Halo semua,
Saya membuat skrip/intisari sederhana yang berfungsi.

https://Gist.github.com/serafeimgr/b4ca5d0de63950cc5349d4802d22f3f0

Mengapa tidak melakukan ini saja?

pip install --upgrade $(pip list --outdated | awk '{print $1}' | tr '\n' ' ')

Karena kenyataannya tidak semudah itu karena Anda mungkin menginstal versi yang tidak memenuhi beberapa dependensi paket Anda yang lain.

Berdasarkan dan dengan berkat @serafeimgr 's inti , saya telah menulis alat baris perintah mungkin-berguna, pip_upgrade_outdated ; sumber di github . Umpan balik selamat datang.

(Lihat juga masalah ini : Ya, eksekusi paralel sangat berbahaya, dan, ya, ini dapat merusak banyak hal. Meskipun demikian, banyak orang menjalankan sesuatu seperti ini dengan tangan sepanjang waktu, jadi mungkin akan berguna.)

Terima kasih telah meluangkan waktu untuk membangun solusi lengkap.
Meskipun rekomendasi saya adalah menemukan cara untuk mendorong fitur ini ke pip.

Saya pikir pipenv & pipfile akan menggantikan pip/requirements.txt.
Mungkin @kennethreitz tahu lebih banyak tentang peta jalan dan --upgrade semua fitur.

@qoheniac | tr ... berlebihan.

Utas ini telah dikunci secara otomatis karena tidak ada aktivitas terbaru setelah ditutup. Silakan buka edisi baru untuk bug terkait.