"upgrade" ist ein trivialer Alias ​​für "install --upgrade". Muss noch ein bisschen nachdenken
über "upgrade-all"; Zum einen nehme ich an, dass es nur Pakete aktualisieren würde
innerhalb sys.prefix? (dh wenn Sie sich in einer virtuellen Umgebung befinden, wird es nicht versuchen
globale Pakete aktualisieren). Das wäre ein Grund umzuziehen
UninstallPathSet.can_uninstall() zu einer allgemeiner benannten Funktion (oder
-Methode von InstallRequirement), so dass ein allgemeines "kann ich das berühren?"
Entscheidungen.

Original Comment By: Carl Meyer

Fürs Protokoll, ich denke, das scheint eine gute Idee zu sein, wenn man die Möglichkeit bedenkt,
vor dem Upgrade deinstallieren. Obwohl ich eine --all Option bevorzugen würde für
upgrade anstelle eines eigenen upgrade-all Befehls.

Was can_uninstall() angeht, stimme ich zu.. das ist wahrscheinlich praktisch zu haben
weltweit sowieso.

Original Comment By: Jannis Leidel

Ich bin nicht ganz dagegen, als Alias ​​für install --upgrade zu aktualisieren. Aber
es scheint ein bisschen trivial.

upgrade-all erfordert, dass Sie herausfinden, was "aktualisierbar" ist. Wahrscheinlich einer
Voraussetzung ist, dass es lebt/lib/pythonX.Y/site-packages
(einfach unter sys.prefix reicht nicht).

Wenn wir so etwas wie "Zip-Import" zulassen (um ein Paket von den Eltern zu bringen
Umgebung in eine Virtualenv-Umgebung) dann wahrscheinlich Pakete darin
Die übergeordnete Umgebung sollte nicht aktualisiert werden, aber es ist nicht 100% klar, was es ist
der Benutzer erwartet.

Ich habe versucht, ein bearbeitbares Paket mit "pip uninstall" zu deinstallieren und es ist ganz
vernünftigerweise angeboten, den .egg-Link zu entfernen und easy-install.pth zu aktualisieren. Aber es
hätte das Paket nicht vernünftig aktualisieren können, also ist can_uninstall etwas
anders als can_upgrade.

Original Comment By: Ian Bicking

Ja, Sie haben Recht, can_uninstall und can_upgrade sind unterschiedlich.

Ich würde denken, wenn wir "Pip-Import" hätten, würden wir immer noch nicht upgraden wollen
importierte globale Pakete; aber (zusammen mit editables) könnte es ein "nicht" wert sein
upgrade this"-Warnung an die Konsole.

Original Comment By: Carl Meyer

+1 für diesen Fehler

Original Comment By: smyrman

Ausgabe Nr. 167 wurde als Duplikat dieser Ausgabe markiert.

Original Comment By: Carl Meyer

1

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

installieren -U

Dies sollte alle installierten Pakete aktualisieren (einschließlich pip selbst). Wenn
Sie es in virtualenv ausführen, müssen Sie wahrscheinlich nicht sudo verwenden.

Natürlich birgt es ein hohes Ausfallrisiko – wenn eines der Pakete aktualisiert wird
scheitert der gesamte Prozess wird fehlschlagen (ähnlich wie port upgrade outdated in
MacPorts).

Original Comment By: Tomasz Elendt

+1 für Upgrade --alle

Warum müssen im Moment alle Python-Modulverwaltungsfunktionen scheiße sein? Warum nicht
man bietet einfaches upgrade + upgrade --all Befehl?

Original Comment By: Anonymous

Ich hätte nichts dagegen, eine Implementierung zu versuchen, aber zuerst ein paar Fragen.

Ist der allgemeine Konsens, dass ein neuer "upgrade"-Befehl, der ein '--all' unterstützt,
Option zu Pip hinzugefügt werden?

Das Ausführen eines Pip-Upgrades sollte sich nur auf die Umgebung auswirken, in der es ausgeführt wird
von einer virtuellen Umgebung ausführen, dann werden nur Pakete aktualisiert, die in dieser Umgebung lokal sind;
das gleiche für nicht-virtualenvs

Original Comment By: Kelsey Hightower

Kelsey: Nach meiner Lektüre der obigen Diskussion sehe ich keine echten
Widerspruch dagegen. Ich denke, es ist eine gute Ergänzung. Der Hauptkantenfall ist
bearbeitbare VCS-Installationen - wie Ian vorgeschlagen hat, denke ich, ein "Upgrade"-Befehl
sollte diese nicht anfassen. Definieren, was "Upgrade" im Kontext aller
bearbeitbare Möglichkeiten (einschließlich lokaler Repositorys, die bearbeitbar installiert sind und keine
Herkunft) wäre so gut wie unmöglich, denke ich, und auch wenn einige halbwegs funktionieren
Definition zusammengestellt werden könnte, es würde nur den Wartungsaufwand erhöhen
Belastung der bereits fragilen VCS-Backends. Aber für nicht bearbeitbare - gehen Sie für
es!

Original Comment By: Carl Meyer

Carl: Cool, ich werde anfangen und dieses Ticket mit den Ergebnissen aktualisieren.

Original Comment By: Kelsey Hightower

Bei der Arbeit am Upgrade-Befehl kamen folgende Fragen auf:

• Welche Methoden sollten Pip-Upgrade unterstützen, um anzugeben, welche Pakete zu verwenden sind?
  Aktualisierung? Sollen wir eine Anforderungsdatei unterstützen?
• Wie soll pip upgrade mit Paketen umgehen, die noch nicht installiert sind?
  Sollen wir fehlende Pakete installieren?

Anwendungsfälle für pip-Upgrades und deren Handhabung:

# pip upgrade some_installed_package

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

Anforderung nicht erfüllt Upgrade auf die angeforderte Version. Das beinhaltet
Upgrade auf eine ältere Version.

# pip upgrade --all

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

Version falls vorhanden.

# pip upgrade some_other_package

Warning: some_other_package not installed, use pip install

some_other_package.

Mein Ziel ist es, den Upgrade-Befehl wirklich einfach zu halten. Sie können upgraden
bestimmte nicht bearbeitbare Pakete zu einer neuen oder älteren Version; oder du kannst upgraden
alle nicht bearbeitbaren Pakete auf eine neuere Version.

Die Gedanken?

Original Comment By: Kelsey Hightower

Ich denke, "pip upgrade" sollte ein genauer Alias ​​​​für "pip install --upgrade" sein, da
es funktioniert jetzt. Das bedeutet, dass die angeforderten Pakete installiert werden, wenn sie
werden nicht installiert, und ja, es akzeptiert Anforderungsdateien mit -r. Sein sollte
fast ohne neuen Code machbar sein.

Upgrade – für alle wird ein Code benötigt, um die aktuelle Liste zu finden
installierte aktualisierbare Pakete; dann sollte es nur diese Liste zur Installation übergeben
--upgrade, wie oben.

Original Comment By: Carl Meyer

Karl, danke für die Antwort. Ich bin so ziemlich deinen Weg gegangen
beschrieben. Heute später sollte ich in der Lage sein, einige Beispielläufe zu posten.

Original Comment By: Kelsey Hightower

Ich habe den größten Teil des Codes fertig, nur noch ein wenig Politur, bevor ich den Code poste
zur Durchsicht.

MACHEN:

• Tests
• Anforderungsdatei filtern; Nicht-editierbares zur Liste der Pakete hinzufügen zu
  Aktualisierung.

Ausführen von pip mit dem Upgrade-Befehl

# 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

Letzte Fragen (hoffe ich):

• Sollte pip upgrade die Anforderungsdatei parsen und herausfiltern
  bearbeitbar? Was ist mit URL-Anforderungen?

Für jedes nicht bearbeitbare Element in der Anforderungsdatei möchte ich die
Indizes für eine spätere Version. Dazu müsste ich die
Paketinformationen aus jeder Zeile in der Anforderungsdatei.

Alle Tipps sind willkommen (derzeit pip.req.parse_requirements ).

• Sollte pip upgrade die Indizes nach einer späteren zu installierenden Version durchsuchen?
  (Das mache ich gerade). Wenn nicht, wie sollte der Upgrade-Befehl ermitteln?
  wenn es ein Upgrade gibt?

Im Moment füge ich Pakete nur dann zur Upgrade-Liste hinzu, wenn:

• Das Paket ist nicht installiert
• Ein Upgrade ist verfügbar (spätere Version aus den Indizes), und nicht explizit
  Version wurde angefordert
• Die angeforderte Version unterscheidet sich von der installierten (Version miss
  Spiel).
• Ich verschiebe die Anforderungsdatei auf den Installationsbefehl, bis ich filtere
  die nicht bearbeitbaren Anforderungen heraus.

Original Comment By: Kelsey Hightower

Carl, nachdem ich deinen Beitrag noch einmal gelesen habe, scheint es, als würde ich mehr tun als das, was ist
erforderlich. Ich werde meine Filiale hochladen, damit Sie einen Blick darauf werfen können. ich bin vielleicht gegangen
über Bord, indem Sie PyPi auf eine neuere Version überprüfen.

Original Comment By: Kelsey Hightower

Carl, nachdem ich deinen Beitrag noch einmal gelesen habe, scheint es, als würde ich mehr tun als das, was ist
erforderlich. Ich werde meine Filiale hochladen, damit Sie einen Blick darauf werfen können. ich bin vielleicht gegangen
über Bord, indem Sie PyPi auf eine neuere Version überprüfen.

Original Comment By: Kelsey Hightower

Ja, es hört sich so an, als ob Sie mehr tun, als nötig wäre. Pip installieren
--upgrade erledigt alles, was Sie bereits besprechen (überprüft nach neueren
Versionen usw.); alles "Pip-Upgrade" sollte wie ein Zweizeiler-Übergang sein
alles über pip install --upgrade.

Der einzige wirkliche Code, der hier geschrieben werden muss, ist der Code für "upgrade --all" zu bekommen
die vollständige Liste der installierten aktualisierbaren Pakete in der Umgebung.

Original Comment By: Carl Meyer

Ja, ich wusste es. Nun, ich habe viel gelernt. Auch wenn es dafür nicht erforderlich ist
Aufgabe, ich mag die Möglichkeit zu zeigen, was installiert und verfügbar ist während der
Upgrade-Prozess (siehe Testlauf oben).

Ich werde die Dinge neu faktorisieren und aufräumen. Aktuelle Änderungen in meiner Gabel auf der
Upgrade-Befehlszweig.

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

Original Comment By: Kelsey Hightower

Ich habe den Upgrade-Befehl nach Carls Vorschlägen abgespeckt (ich bin zu weit gegangen
an erster Stelle). Ich bin mir nicht sicher, ob mir die Ergebnisse gefallen, aber es wird gespiegelt installiert--Upgrade in der Funktionalität.

Es scheint, dass pip versucht, das Paket herunterzuladen und erneut zu installieren, selbst wenn das
Paket ist bereits installiert und aktuell. Noch schlimmer mit Upgrade--all , pip installiert alles neu, einschließlich pip selbst. Ist das wie Pip
Upgrade sollte funktionieren? Wenn ja, dann bin ich fast fertig :)

Ausführen des Befehls pip upgrade

# 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-Prototypen -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 - Ja, es gibt einige Fehler bei install --upgrade; insbesondere du
identifiziert #13 , dass es sogar Pakete neu herunterlädt und neu installiert, die
sind schon auf dem neusten Stand. Die Lösung dort ist nicht etwas anderes zu machen
Mit dem neuen Upgrade-Befehl soll der Fehler in install --upgrade behoben werden.

Mit upgrade --alles scheint es mir vernünftig, dass pip sich selbst upgraden würde
auch, wenn ein Upgrade verfügbar ist. (Persönlich werde ich niemals ein Upgrade verwenden
--alles, also weiß ich nicht, welches Verhalten Leute, die es verwenden, davon erwarten würden
Hier). Offensichtlich wäre es wieder besser, wenn #13 repariert würde.

Original Comment By: Carl Meyer

Danke Carl, ich werde das abschließen und mir #13 ansehen

Original Comment By: Kelsey Hightower

Wenn jemand Zeit hat, lesen Sie bitte meinen upgrade-command-Zweig. In der Zwischenzeit
Ich werde an Unittests arbeiten, die versuchen, die vorhandenen nicht zu duplizieren für die
Befehl installieren.

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

Original Comment By: Kelsey Hightower

@vababiy : Ich habe deinen Upgrade-Befehl ausprobiert, aber er scheint nicht richtig zu funktionieren... Also habe ich einen eigenen gemacht:

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

@jedie ich glaube, du wolltest deinen Kommentar an @khighower richten. @vbabiy hat ihren Kommentar hierher migriert, aber den Upgrade-Befehl nicht geschrieben.

+1

@kelseyhightower Irgendwelche Fortschritte?

+1

+1!

+1

+1

Bitte beenden Sie das Kommentieren des Problems mit nur einem "+1". Wir sind uns bewusst, dass die Funktion erwünscht ist, Spam in unseren Posteingang hilft jedoch nicht.

Stattdessen würde ich mich über einen Kommentar "Patch fertig!" freuen. ;)

+1

Irgendwelche Updates? Gibt es einen Plan, dies hinzuzufügen, es ist jetzt 3 Jahre alt..

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

+1

Ich dachte, das wäre schon zusammengelegt. Ich kann meine Python-Fähigkeit abstauben und es noch einmal versuchen.

Wird diese Funktion in 1.5 enthalten sein? Kann in der 1.5er Dokumentation keinen Hinweis darauf finden...

+1

Wie ist der Status dieses Problems?

Es ist blockiert von #988

Wenn es für Sie wirklich wichtig ist, gibt es Problemumgehungen für das Upgrade aller Pakete; Ich habe dazu parallel ein Skript zusammengestellt (https://github.com/ariccio/update-pip-packages), und es gibt viele andere Implementierungen an anderer Stelle im Internet.

Dieses Problem besteht aus zwei Teilen. upgrade-all kann von gh-988 blockiert werden, aber ich sehe nicht, wie upgrade blockiert wird. pip upgrade kann ein einfacher Alias ​​für pip install -U --no-deps . Dies würde eines der Hauptprobleme bei der Verwendung von install_requires in setup.py-Dateien lösen. Ist das nicht bald möglich?

pip upgrade kann ein einfacher Alias ​​für pip install sein -U --no-deps

aus der Beschreibung:

pip upgrade wäre wie pip install --upgrade außer dass es standardmäßig nicht rekursiv wäre (und eine Option --recursive anbieten würde). Sein aktuelles rekursives Standardverhalten hat vielen Kummer bereitet (#304). Wie Sie jetzt nicht-rekursive Upgrades durchführen, finden Sie hier

das ist nicht pip install -U --no-deps

„nicht rekursiv“ bedeutet in diesem Zusammenhang nicht einfach –no-deps . Bei einem nicht-rekursiven Upgrade werden Abhängigkeiten aktualisiert, jedoch nur, wenn dies zur Erfüllung der übergeordneten Anforderungen erforderlich ist.

@qwcode danke für die Klarstellung. Dann ist mir das egal. Warum würden Sie das "nicht-rekursiv" nennen, es ist immer noch rekursiv, aber nur ein bisschen intelligenter/anders?

Ich hatte aus der Diskussion in gh-571 den Eindruck, dass wirklich nicht-rekursiv die gewünschte Vorgabe ist. Das wäre sicherlich sinnvoll und würde verhindern, dass immer Code wie https://github.com/scipy/scipy/commit/8e7ee0c4b3c16 geschrieben werden muss.

in #571 ist "nicht-rekursiv" nicht --no-deps sondern die "intelligentere/andere" Rekursive, wie Sie sagen.
Beachten Sie den test_upgrade_with_needed_recursive_upgrades() Test von diesem PR.

ohne an Begriffen hängen zu bleiben, gibt es 3 Dinge:

1. das "intelligentere/andere Upgrade", dh die Art, die bei Betriebssystempaketen auftritt, die auch Upgrade-Abhängigkeiten implizieren kann (aber nur, wenn sie tatsächlich ein Upgrade _erfordern_).
2. Was pip jetzt tut, ist, alle Abhängigkeiten zu aktualisieren, unabhängig von Bedarf oder Konfliktlösung.
3. --no-deps

einige Möglichkeiten zur Unterscheidung von #1 und #2

1. "nicht rekursiv" vs "rekursiv"
2. "normal" vs "rekursiv"
3. "nur bei Bedarf rekursiv" vs "mache es trotzdem rekursiv"

Ich bin offen für die Verwendung der besten Begriffe ... bin mir nur nicht sicher, was das ist.

Ich glaube, ich mag diesen "nur wenn nötig rekursiven" Satz. Vielleicht sollte ich das hier in der Dokumentation verwenden:

Ich mag es auch. Wenn Sie die drei Optionen zusammen beschreiben würden als

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

das wäre klar.

Dann möchten Sie gute Standardeinstellungen auswählen. Sowohl für upgrade als auch für install -U entweder (a) oder (b) Sinn machen. Ich bevorzuge (a) stark, aber (b) macht auch Sinn, da das OS-Packaging genau das tut.

(c) macht standardmäßig keinen Sinn, also überdenken Sie bitte Ihre Entscheidung, install -U nicht zu ändern.

Um zu verdeutlichen, warum ich (a) stark bevorzuge: Ein ahnungsloser Benutzer, der (b) will und (a) bekommt, muss eine Nachricht mit der Aufschrift "non-recursive upgrade can't satisfy all dependencies, please use only-if-needed recursive" lesen, was nicht so schlimm ist. Wenn der Standardwert (b) wäre, könnte dieser ahnungslose Benutzer mit einem Upgrade oder sogar einer fehlerhaften Installation eines Pakets enden, das er wirklich nicht anfassen wollte. Das kann Stunden oder sogar Tage dauern, um sich davon zu erholen.

(c) macht standardmäßig keinen Sinn, also überdenken Sie bitte Ihre Entscheidung, install -U . nicht zu ändern

der Grund, install -U Ruhe zu lassen, sind nur Kompatibilitätsgründe und dann schließlich die Einstellung.

Wenn der Standardwert (b) wäre, kann dieser ahnungslose Benutzer mit einem Upgrade enden
oder sogar eine kaputte Installation eines Pakets, das er wirklich nicht anfassen wollte

Wenn ein Benutzer möchte, dass erforderliche Abhängigkeits-Upgrades nicht erfüllt werden, sollte er dies ausdrücklich mit --no-deps . Es gibt keine Möglichkeit in meinem Kopf, die jemals die Standardeinstellung sein könnte. dieses Verhalten würde mehr Schaden anrichten, als Sie in Betracht ziehen (was der Ausreißerfall ist). Immer wieder würden Benutzer nicht über die benötigten Abhängigkeits-Upgrades verfügen.

Die Einstellung von install -U hört sich gut an.

Ich stimme zu, dass (b) häufiger vorkommt als (a). Selbst wenn es 100x häufiger wäre, was meiner Meinung nach nicht der Fall ist, ist mehr Schaden nicht wahr. Das Lesen einer eindeutigen Fehlermeldung vor Beginn der Installation ist so viel besser als beispielsweise ein Kompilierungsfehler auf halbem Weg, dass imho (a) immer noch die bessere Standardeinstellung ist.

Sich auf --no-deps mag für sehr erfahrene Benutzer in Ordnung sein, aber neue Benutzer werden es erst erfahren, wenn etwas schief geht.

Wie auch immer, es sieht so aus, als ob ich Sie nicht überzeugen kann. Dann zurück zum Handbuch

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')

es ist.

@qwcode danke für die ausführliche Erklärung. Ich hoffe, dass dies in naher Zukunft vorangetrieben wird - nur wenn nötig rekursiv wäre eine enorme Verbesserung gegenüber dem aktuellen Verhalten.

Da ich diese Woche wieder viele Stunden damit verbringe, Probleme zu lösen, warum wir install_requires , füge ich ein :+1: hinzu, um vom aktuellen Verhalten wegzukommen.

Gibt es Updates zu diesem Thema?

Wir haben jetzt 2015 und ich muss noch von pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U Stackoverflow kopieren

Ja, im Wesentlichen hängt der gesamte Fortschritt mit diesem Problem zusammen.

GitHub macht einen recht guten Job beim Querverweisen von Dingen. Alle diese sind anklickbar! (Ich bin sicher, Sie wissen das?)

Ja, sicher, aber ich verstehe nicht, warum diese "einfache" Funktion eine solche Verzögerung hat.

Was ist der Grund dafür?

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

Ja, im Wesentlichen hängt der gesamte Fortschritt mit diesem Problem zusammen.

GitHub macht einen recht guten Job beim Querverweisen von Dingen. Alle diese sind anklickbar! (Ich bin sicher, Sie wissen das?)

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Was pip upgrade-all angeht, scheint der Konsens darin zu bestehen, auf die Arbeit im Zusammenhang mit #988 zu warten, bevor neue, glänzende Befehle veröffentlicht werden, die letztendlich immer noch fehlerhaft sind und für eine Arbeitsumgebung gefährlich sein können. Eine einfache Version von upgrade-all , die die Anforderungen nicht richtig auflöst, kann leicht vorhandene Pakete beschädigen

+1

Was machst du 4 Jahre lang?

+1

+1

+1

@muhaturk Momentan warte... https://github.com/pypa/pip/issues/59#issuecomment -93646462

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 ...sorry für den Spam, aber pip freeze --local | grep -v '^\-e' | cut -d = -f 1 | xargs -n1 pip install -U laufen zu lassen tut weh!

+1

Falls jemand daran interessiert ist, daran zu arbeiten, denke ich, dass die obigen Kommentare etwas verwirrend sind – AFAICT der tatsächliche Status ist, dass pip upgrade-all derzeit durch die Notwendigkeit eines geeigneten Systems zur Auflösung von Abhängigkeiten blockiert ist, aber pip upgrade könnte jederzeit implementiert werden. Wenn jemand an diesem Teil arbeiten möchte, wäre das extrem toll :-).

(Siehe auch den hier beginnenden Thread und die Antwort von @dstufft hier und den Kommentar hier , der der obigen Einschätzung zustimmt.)

hier ist eine weitere Diskussion aus der pypa-dev-Liste von vor einem Jahr (die zustimmt, dass pip upgrade FOO jetzt durchgeführt werden könnte) https://groups.google.com/forum/#!searchin/pypa -dev/pip$20 upgrade/pypa-dev/vVLmo1PevTg/oBkHCPBLb9YJ

Danke @qwcode! Ich habe auch gerade die neue Beschreibung unter https://pip.pypa.io/en/latest/user_guide/#only -if-needed-recursive-upgrade gesehen, das ist hilfreich.

+1

Wenn ich mich nicht irre:

Wenn xxx nicht installiert ist:

• pip upgrade xxx entspricht pip install xxx
• pip upgrade xxx --recursive wäre das Äquivalent von pip install xxx --upgrade

Wenn xxx installiert ist:

• pip upgrade xxx --recursive wäre immer noch das Äquivalent von pip install xxx --upgrade (von Design her)
• aber es gibt derzeit kein Äquivalent für pip upgrade xxx , dies könnte pip install xxx --upgrade-only-if-needed/--upgrade-lazy

Es ist nicht klar, was der Mehrwert eines neuen Befehls gegenüber dem Hinzufügen einer neuen Option zu pip install ?

Es ist nicht klar, was der Mehrwert eines neuen Befehls gegenüber dem Hinzufügen einer neuen Option zu pip install ?

Das Standardverhalten von pip install -U ist für viele Projekte nicht akzeptabel. Siehe meinen Kommentar oben (https://github.com/pypa/pip/issues/59#issuecomment-52434862). Und hier ist eine längere Erklärung: http://article.gmane.org/gmane.comp.python.distutils.devel/24218

Wenn dies nicht akzeptabel ist, planen Sie vermutlich, Ihre Verwendung von pip install --upgrade to pip upgrade zu ändern?
Warum könnten Sie nicht stattdessen Ihre aktuelle pip install --upgrade-Nutzung in pip install --upgrade-only-needed ändern?
Was bietet ein neuer Befehl, was eine neue Option nicht kann?

Es ist alles, um Kuhwege zu pflastern. Es ist nicht der persönliche Gebrauch von @rgommer, um den er sich Sorgen macht, sondern seine Benutzer. Die Leute werden nach der "offensichtlichen" Antwort greifen, wenn sie es nicht besser wissen, und im Moment ist die offensichtliche Antwort für einige wichtige Teile des Python-Ökosystems problematisch.

In der Tat. Die Leute lesen keine Dokumente. In der Tat werden wir alle Installationsdokumente reparieren, die wir finden können, aber sobald ein Benutzer -U oder --upgrade sieht, wird er diese verwenden. Die Wahrscheinlichkeit, dass Leute --no-deps oder --only-as-needed oder was auch immer benutzen, bevor sie ernsthaft davon gebissen wurden, ist gering.

Warum könnten Sie nicht stattdessen Ihre aktuelle pip install --upgrade-Nutzung in pip install --upgrade-only-needed ändern?

Und um es klar zu sagen: Wir vermeiden pip install --upgrade jetzt _und_ verwenden deshalb nicht install_requires . So schlimm ist es.

Ich denke, hier liegt ein kleines Missverständnis vor – IIUC @xavfernandez stimmt dem Hinzufügen der nicht-rekursiven Upgrade-Funktionalität zu. Ihre Frage ist nur, warum die Benutzeroberfläche dieser Funktionalität als neuer Befehl auf oberster Ebene und nicht als neue Option für pip install .

@xavfernandez : Beachten Sie, dass derzeit in #3194 eine Diskussion darüber stattfindet, was die klarste Benutzeroberfläche für diese Funktionalität wäre.

(Und pip install -U wird veraltet und dann entfernt, damit die Frage beantwortet wird, woher Benutzer wissen, dass sie es nicht verwenden sollen :-).)

Ich glaube hier liegt ein kleines Missverständnis vor

Ich bin mir ziemlich sicher, dass es das nicht gibt. Und ja, wir diskutieren nur über die Benutzeroberfläche. Aber das ist wichtig.

Yup nur über die Benutzeroberfläche diskutieren und ich stimme zu, dass es wichtig ist. Aber was ich kommen sehe ist, dass es, sobald das Pip-Upgrade veröffentlicht ist, keinen Grund mehr gibt, pip install weiter zu verwenden ...
Und die Benutzeroberfläche zum Installieren eines Pakets wird zu "pip upgrade foo"

Es gibt keinen Grund, pip install weiterhin zu verwenden

was ist ein problem warum? Das Problem (zumindest für @qwcode in den Kommentaren oben) beim Ändern von pip install --upgrade in das richtige Verhalten bricht die Abwärtskompatibilität. pip upgrade ist also der Weg, um diese Unterbrechung zu vermeiden _und_ die richtige Vorgabe zu erhalten.

@rgommers : pip upgrade foo ausführen soll, wenn ich nicht einmal foo installiert habe? funktioniert nicht (diskutieren Sie hin und her, bis sie tatsächlich versuchen, den Befehl auszuführen, anstatt davon auszugehen, dass es nicht funktioniert und so zu tun, als ob sie ihn ausgeführt hätten)

Auf #3194 habe ich den Kommentar gemacht, dass vielleicht der richtige Weg darin besteht, einfach --upgrade von pip install zu entfernen, pip install immer ein Upgrade der explizit benannten Elemente durchzuführen und die Standardeinstellung zu einer minimalen Upgrade-Strategie für Abhängigkeiten mit einem --recursive Flag, um das aktuelle Verhalten beim Upgrade zu erhalten.

Ich glaube, ich stimme zu, dass ich das Gefühl habe, dass mit #3194 die Standard-UX pip upgrade foo anstelle von pip install [-U] foo . Das einzige Problem, das ich damit habe, ist, dass es irgendwie verwirrend ist, die beiden Befehle zu haben, und da ich denke, dass pip upgrade der "richtige" Befehl für die Leute wäre, finde ich es mies, das Offensichtliche zu haben Name sei der falsche Name.

Ich habe Migräne, also könnte ich auch einfach nicht ganz richtig denken, aber ich habe das Gefühl, herauszufinden, wie ich mit dem Weg der Ablehnung zu diesem Vorschlag umgehen soll, könnte der richtige Weg sein.

Nun, ich werde nicht argumentieren, dass Rückwärtskompat hier wichtig ist. Ich war immer dafür, das Verhalten von pip install --upgrade ändern. Es ist das sauberste und die Kosten scheinen gering zu sein. Aber es sah für mich so aus, als hätte @qwcode ein Veto pip upgrade die nächstbeste Sache (und bereits vor einem Jahr von den Pip-Entwicklern in Ordnung gebracht).

Wenn wir jetzt zu den Änderungen der Standardeinstellungen/des Verhaltens für pip install möchten, großartig.

@dstufft das macht für mich total Sinn - so schlimm können die Kopfschmerzen nicht sein :)

Da wir zustimmen, --upgrade zu veralten, könnten wir das beibehalten und zwei Optionen zu pip install hinzufügen: --upgrade-only-needed und --upgrade-eager , wobei die zweite ein Alias ​​für das veraltete --upgrade ist

@xavfernandez Den Benutzern Entscheidungen --upgrade-only-needed und --upgrade-eager .

@xavfernandez also schlagen Sie vor, dass der Befehl in der pip install --upgrade-only-needed lautet ? Scheint hässlich.

Es wäre viel besser, etwas zu haben, das dem Äquivalent der semantischen Version des Pinnings entspricht, das in zB npm , hex oder Cargo verfügbar ist. Das müsste im Python-Kontext sicherlich angepasst werden, da (a) PEP 440- Versionen nicht genau auf semantische Versionierung abbilden können und können und (b) die Python-Community im Allgemeinen nicht unbedingt auf semantikähnliche Versionierung in ihren Releases achtet, selbst innerhalb von PEP 440.

Nichtsdestotrotz wäre etwas in dieser Richtung sehr hilfreich, ebenso wie die Idee, eine bestimmte Version zu fixieren.

Angesichts der Einschränkungen könnte kurzfristig eine praktikable Option darin bestehen, etwas Analoges zu den Befehlen upgrade und upgrade --all von Homebrew zu tun, wobei letztere einfach alles aktualisieren (möglicherweise beim ersten Mal mit einer Warnung). ).

Auf lange Sicht wäre es jedoch enorm nützlich, gemeinsame Konventionen darüber zu schaffen, was Versionen in der Python-Packaging-Community bedeuten, und der Aufbau von pip Unterstützung könnte ein großer Teil davon sein.

Der offensichtliche Migrationspfad wäre:

Pip-Version X:

• Optionen hinzufügen pip install --eager , pip install --no-eager , wobei --eager bedeutet, dass wir bei Anforderungen ohne Versionsbeschränkung versuchen, die neueste Version zu installieren, auch wenn bereits eine Version installiert ist, und --no-eager bedeutet, dass wir zufrieden sind, wenn eine Version installiert ist
• auch Option pip install --eager-recursive mit der aktuellen -U Semantik hinzufügen
• --no-eager bleibt die Standardeinstellung
• Wenn keine dieser Optionen angegeben ist und pip install eine Anforderung ohne angehängte Versionsnummer erfüllt und diese Anforderung bereits erfüllt ist, geben Sie eine Warnung aus, dass wir Ihr Paket nicht aktualisiert haben, sondern in Zukunft wir werden, also sollten Sie --no-eager wenn Sie das aktuelle Verhalten beibehalten möchten
• pip install -U eine Einstellungswarnung hinzufügen und Leute an pip install --eager-recursive

Pip-Version Y:

• ändere die Standardeinstellung für pip install auf --eager

Pip-Version Z:

• pip install -U entfernen

Ich habe unterschiedliche Versionen von Y und Z erstellt, weil ich --eager benötige, also könnten wir diese Änderung vielleicht in einem aggressiveren Zeitplan vornehmen, während wir pip install -U eine Weile beibehalten, da viele Dokumentationen bereits darauf verweisen dazu, und es schadet nicht. Aber offensichtlich ist Y = Z eine Option :-)

@chriskrycho : Das hört sich alles nach großartigen Sachen an, aber in dieser Diskussion geht es darum, wie man mit der Situation

Absolut; mein Punkt (den ich jetzt anerkenne, dass ich ihn nicht explizit gemacht habe!) war einfach zu bemerken, dass jede Lösung, die hier angenommen wird, nicht im Widerspruch zu einer solchen Vorgehensweise in der Zukunft stehen sollte.

Was ist der normale Einstellungspfad für pip? Zeit-/versionsbasiert? Wie lange muss etwas veraltet sein, bevor es entfernt wird?

Übrigens denke ich, dass "eifrig" ein Wort ist, das Benutzer nicht verstehen werden. rekursiv / nur nach Bedarf rekursiv / immer rekursiv ist viel klarer.

Normalerweise führen wir einen Verfallszyklus von zwei Versionen durch.

Hauptversionen nehme ich an? Minor-Versionen sind wirklich schnell (7.0 -> 7.1 war ein Monat). In der Regel ein halbes Jahr zwischen den Hauptversionen, also 1 Jahr Warnungen wegen veralteter Versionen?

Ja, tut mir leid. Hauptversionen. Wenn wir etwas in 8.x ablehnen, wird es eine gelbe Warnung für den Rest von 8.x, eine rote Warnung für alle 9.x und in 10.x entfernt.

Danke.

Kopieren Sie den Kommentar von @dstufft von https://github.com/pypa/pip/pull/3194#issuecomment -152357835 hier, weil es die beste Zusammenfassung der Situation ist:

Ich denke, das tl; dr ist, dass ich absolut denke, dass wir das "Standardverhalten" korrigieren müssen, wir müssen uns nur auf die spezifische Implementierung der Behebung festlegen:

1. Behalten Sie die UX bei pip install --upgrade und ändern Sie die Standardeinstellung.
2. Verschieben Sie die UX mit der "richtigen" Standardeinstellung zum Pip-Upgrade und fügen Sie ein --rekursives Flag hinzu.
3. Verschieben Sie die UX nach pip install, entfernen Sie --upgrade und fügen Sie ein --recursive-Flag hinzu.

Mein 2c:

(1) hat eine gute UX, kann jetzt gemacht werden
(2) eine etwas schlechtere UX (habe sowohl install als auch upgrade ), kann jetzt gemacht werden
(3) zweitbeste UX, das Ändern von pip install kann jetzt durchgeführt werden, das Entfernen von --upgrade wird nur in 10.0 durchgeführt (veraltet in 8.0 und 9.0).

Ich sehe nicht, warum das Rückwärtskompat-Problem (das in jedem Fall geringfügig sein sollte) für (1) schlimmer wäre als für (3). (1) scheint also am besten zu sein. Wenn bw compat ein echtes Problem ist, wählen Sie (2).

Wie auch immer, es ist Zeit, die Nacht zu beenden.

Ich denke, der Unterschied zwischen (3) und (1) hängt davon ab, ob wir der Meinung sind, dass install-or-upgrade die häufigste Operation ist, die die Leute wollen - wenn ja, dann ist es wahrscheinlich am besten, es zum kurzen Befehl wie in (3) zu machen. Es ist aber auch keine große Sache.

Übrigens denke ich, dass "eifrig" ein Wort ist, das Benutzer nicht verstehen werden. rekursiv / nur nach Bedarf rekursiv / immer rekursiv ist viel klarer.

Ich hänge überhaupt nicht an der "eifrigen" Schreibweise, aber rekursiv macht einfach keinen Sinn als Hauptwort zum Ein- und Ausschalten von Upgrades. Ich denke, wir könnten --upgrade-non-recursive (zukünftiger Standard), --upgrade-recursive , --upgrade-none oder so verwenden, aber es stellt immer noch das verwirrende rekursive Verhalten in den Vordergrund (ich hätte keine Ahnung, was --upgrade-non-recursive meinte, wenn ich nicht bereits mit dem seltsamen rekursiven Verhalten der Legacy-Option -U vertraut wäre), und --upgrade-none klingt irreführend, als würde es sicherstellen, dass keine Pakete aktualisiert werden, selbst wenn dies zur Erhaltung der Selbst- Konsistenz.

Wenn wir diesen Weg gehen, kümmere ich mich nicht so sehr um den Zeitraum der Rechtschreibung, da die Option, die die meisten Leute wollen, nur die Standardoption wäre und die Optionen für rekursives Upgrade und kein Upgrade beide spezielle selten verwendete Dinge sind, die die meisten Benutzer verwenden ignorieren könnte.

--upgrade-non-recursive (zukünftige Standardeinstellung) ...

das ist natürlich verwirrend. Sie ignorieren jedoch die einfachste Option, die darin besteht, diesen Schalter überhaupt nicht bereitzustellen. denn wenn es mit dem Standardverhalten identisch ist, warum sollten Sie es dann jemals brauchen?

Ich denke, der Unterschied zwischen (3) und (1) hängt davon ab, ob wir der Meinung sind, dass die Installation oder das Upgrade die häufigste Operation ist, die die Leute wünschen

Ich würde "installieren" erwarten. Zumindest weiß ich, dass ich nur Pakete aktualisiere, die ich absichtlich stark nutze, aber jedes Mal, wenn ich etwas Interessantes / Nützliches sehe, ist es einfach pip install pkgname entfernt.

(aber nicht, dass ich ein typischer Benutzer wäre, also könnte meine Erwartung falsch sein)

Ich glaube, ich wäre dafür:

• Kein neues pip upgrade , das ein Alias ​​für pip install
• pip install (ohne --upgrade* Option) Verhalten ändert sich nicht
• pip install --some_name würde nur versuchen, die Pakete zu aktualisieren, die in der Befehlszeile angegeben sind, und nicht deren Abhängigkeiten
• pip install --some_other_name um das alte --upgrade Verhalten verfügbar zu halten

Und dann gibt es zwei Möglichkeiten:

• wir brauchen/wollen keinen Veraltungspfad, dann kann --some_name --upgrade und --some_other_name kann das sein, was am besten erscheint
• Wir brauchen einen veralteten Pfad, dann gibt --upgrade in pip8 eine Warnung aus, dass es veraltet ist und wir sollten --some_other_name , um das alte Verhalten beizubehalten oder besser zu einem sichereren --some_name wechseln um nur die angegebenen Pakete und ihre Abhängigkeiten nur bei Bedarf zu aktualisieren.

In diesem zweiten Fall kann --some_name nicht --upgrade . Also müssen wir zwei neue Optionsnamen für --some_name und --some_other_name

Es scheint mir, dass die offensichtlich "beste" Lösung darin besteht, pip install als Befehl beizubehalten und das Verhalten von --upgrade zu ändern, um Abhängigkeiten nicht zu aktualisieren. Das einzige wirkliche Problem ist die Abwärtskompatibilität, aber haben wir _irgendwelche_ Benutzer argumentiert, dass sie sich auf das aktuelle Verhalten verlassen?

Persönlich neige ich zu der Ansicht "gehen Sie es an und greifen Sie mit der Abwärtskompatibilität an". Ich könnte argumentieren, dass das aktuelle Verhalten tatsächlich ein Fehler ist und diese Änderung eine Fehlerbehebung wäre. Aber ich denke, wir müssen irgendwann sagen können, dass wir einen guten Punkt erreicht haben und wir werden eine viel strengere Sichtweise auf die Abwärtskompatibilität haben. Ich glaube, wir sind noch nicht an diesem Punkt angelangt, aber wir müssen möglicherweise damit beginnen, der Community mitzuteilen, was unserer Meinung nach noch getan werden muss, um an diesen Punkt zu gelangen.

Es besteht immer noch (IMO) Bedarf für eine Art pip install --upgrade :all: Befehl, um alle installierten Pakete zu aktualisieren. Aber das ist eine neue Funktionalität und ist hier nicht relevant.

Das aktuelle Verhalten _ist_ nützlich, insbesondere für Projekte wie Pyramid, bei denen es sich nicht um ein einzelnes Projekt, sondern um eine Sammlung von Projekten handelt. Es wäre nützlich, etwas wie pip install --upgrade-recursive Pyramid tun zu können, um Pyramid und alle seine Abhängigkeiten auf die neueste Version zu aktualisieren. Das gesamte rekursive Ding zu entfernen bedeutet, dass ich entweder alle Abhängigkeiten manuell aufspüren und pip install --upgrade Pyramid dep1 dep2 dep3 dep4 (mit dem gesamten Abhängigkeitsbaum) ausführen muss, oder ich muss ein hypothetisches pip install --upgrade :all: und möglicherweise mehr aktualisieren Dinge, als ich eigentlich upgraden möchte. In #3194 erwähnte mindestens ein Benutzer, dass er möchte, dass das aktuelle Verhalten über ein Flag verfügbar ist, da es in einigen Fällen nützlich ist.

Gibt es einen Grund (außer der Abwärtskompatibilität), es nicht so zu machen, dass pip install implizit ein "minimales" Upgrade durchführt? Ich versuche herauszufinden, in welcher Situation ich eigentlich möchte, dass es nur installiert und kein Upgrade durchgeführt wird (IOW, eine, bei der die neueste Version in Ordnung ist, wenn ich sie noch nicht installiert habe, aber nicht, wenn ich sie habe installiert) und ich habe ein Problem mit einem Fall, in dem ich das aktuelle Verhalten haben möchte.

Ich mag die Idee eines _new_ pip upgrade [--recursive] Befehls wie in #3194 (und veraltet install --upgrade )

Ich habe Bedenken bezüglich aller Entscheidungen, die die Kompatibilität beeinträchtigen oder komplexe veraltete Versionen haben oder die ein ohnehin schon Optionen schweres pip install mit weiteren Änderungen oder Komplexität belasten. Außerdem bin ich persönlich von einem "Upgrade"-Befehl angezogen, der standardmäßig nur Upgrades ähnlich der Funktionsweise von Distributionstools ausführt. "install" installiert und Upgrades "upgrade"...

Ich neige zu der Ansicht "go go for it, and to Heck mit Abwärtskompatibilität"-Ansicht

Ich bin nicht :) zumindest für solche Kernlogiken.

Machen Sie es so, dass pip install implizit ein "minimales" Upgrade durchführt

für mich scheint dies ein Nichtstarter zu sein, oder? Berücksichtigen Sie die Anzahl der möglicherweise auftretenden automatisierten Build-Brüche. Außerdem werden die Leute an einem bestimmten Punkt in ein konzeptionelles Modell über das, was pip install ist, eingesperrt... und dies würde ein erneutes Laden eines neuen mentalen Modells erzwingen. die Leute mögen das nicht.

@qwcode Ich weiß es nicht, ich glaube nicht, dass es in Ordnung wäre. Das Hauptproblem bei pip upgrade besteht darin, dass Sie entweder die Möglichkeit entfernen, den Leuten die Möglichkeit zu geben, "Gib mir die neueste Version davon unabhängig davon, ob sie installiert ist oder nicht" zu sagen, oder Sie haben zwei Befehle, die fast genau dasselbe tun ( pip install und pip upgrade ). Kurzfristig könnte es zu einem Bruch kommen, aber ich mache mir ein bisschen Sorgen über das tatsächliche mentale Modell von pip upgrade weil ich sehe, dass die Leute weit verbreitet ihre Installationsanweisungen von pip install foo auf pip upgrade foo (aber warum aktualisiere ich etwas, das ich noch nicht installiert habe?!).

Äh, ich denke, es wäre in Ordnung, meine ich.

weit verbreitet und ersetzen ihre Installationsanweisungen pip install foo durch pip upgrade foo

Roger, deshalb denke ich, dass upgrade einfach upgraden sollte. Was den "Scheiß" angeht --fill-in-missing , ich hänge nicht daran fest, also verstehe mich nicht so, dass ich das haben muss, aber siehe unten.

"Geben Sie mir die neueste Version davon, unabhängig davon, ob sie installiert ist oder nicht"

• wenn ich FOO , dann pip install FOO und ich bekomme die neueste Version.
• wenn ich FOO , dann pip upgrade FOO und ich bekomme die neueste Version.

Ich glaube wir reden hier von 2 Fällen:

1. Ich weiß nicht, ob ich FOO , und ich möchte, dass der Befehl _one_ die neuesten FOO erhält, ob ich sie habe oder nicht.
2. Ich möchte, dass der Befehl _one_ das Neueste von FOO und BAR erhält. Ich habe FOO installiert, aber nicht BAR .

Schulden wir den Benutzern _einen_ Befehl dafür? Ich würde Einfachheit und Klarheit in den Befehlen vorziehen, anstatt den Leuten Abkürzungen zu geben. Aber wenn Benutzer es verlangen, dann kommt so etwas wie --fill-in-missing Spiel.

Außerdem bin ich persönlich von einem "Upgrade"-Befehl angezogen, der standardmäßig nur Upgrades ähnlich der Funktionsweise von Distributionstools ausführt. "install" installiert und Upgrades "upgrade"...

Klarstellung: Ich habe gerade überprüft, wie drei beliebte Distributionstools funktionieren, und AFAICT (teilweise basiert dies auf Manpages, b/c ich benutze diese nicht alle selbst):

• geeignet:
  
  
  
  • apt install <pkg> führt einen "Upstall" durch -- entweder Upgrades oder Installationen, je nachdem, ob es bereits installiert ist oder nicht.
  
  
  • apt upgrade aktualisiert alle installierten Pakete
  
  
  • apt upgrade <pkg> existiert nicht, die einzige Möglichkeit, ein einzelnes Paket zu aktualisieren, ist apt install <pkg> (das auch verschiedene Arten von Versionsspezifizierern akzeptiert)
  
  
• lecker:
  
  
  
  • yum install <pkg> führt einen "Upstall" durch
  
  
  • yum upgrade aktualisiert alle installierten Pakete
  
  
  • yum upgrade <pkg> aktualisiert eine angegebene Paketliste. Ich weiß nicht, was passiert, wenn sie nicht bereits installiert sind.
  
  
• hausgebraut:
  
  
  
  • brew install <pkg> führt einen "Upstall" durch
  
  
  • brew upgrade aktualisiert alle Pakete
  
  
  • brew upgrade <pkg> aktualisiert eine angegebene Paketliste. Ich weiß nicht, was passiert, wenn sie nicht bereits installiert sind.
  
  

Die Verwendung von install für Upgrades ist also das, was Distributionstools tun :-). Das heißt nicht, dass wir es auch müssen; nur ein Datenpunkt.

Ich weiß nicht, ob ich FOO habe, und ich möchte, dass ein Befehl das neueste FOO erhält, ob ich es habe oder nicht.

Ich denke, der offensichtlichste Anwendungsfall dafür liegt in der Dokumentation. Beispiel: die Django-Dokumente, die ich in dem anderen Thread verlinkt habe, die die Leute anweisen, pip install -U <some package> auszuführen. Sie möchten den Leuten nicht sagen, dass sie " pip install <pkg> ausführen sollen, außer wenn Sie es bereits installiert haben, führen Sie pip upgrade <pkg> ", weil das für Neulinge viel zu verwirrend ist, aber wenn install tut Wenn Sie nicht upgraden, dann nur zu sagen, dass sie pip install <pkg> ausführen sollen, wird auch Verwirrung stiften, da die Leute anfangen, Ihr Tutorial mit einer installierten alten Version durchzuarbeiten und dann keine Ahnung haben, warum die Dinge nicht richtig funktionieren, und Sie dafür verantwortlich machen. Sie benötigen also auf jeden Fall einen einzigen "upstall" -Befehl, der einfach und offensichtlich in die Dokumentation einzufügen ist.

Follow-up zum Verhalten von Homebrew zum Vergleich: brew upgrade schlägt fehl, wenn Sie versuchen, ein nicht installiertes Paket zu installieren:

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

Außerdem ändert sich das aktuelle Verhalten von brew upgrade (siehe Diskussion hier ); in einer zukünftigen Version wird es so umgestellt, dass --all erforderlich ist, um alle installierten Pakete zu aktualisieren.

Klärungspunkt

Ich wusste, dass das jemand aufgreifen würde. :)
Fast hätte ich auf mich selbst reagiert. Ich habe mich auf Upgrades konzentriert.

leckeres Upgrade[...] Ich weiß nicht, was passiert, wenn sie nicht bereits installiert sind.

es tut nichts

lecker installierenführt einen "Upstall" durch

true, aber das Standardverhalten besteht darin, zur Bestätigung aufzufordern, was pip nicht hat.

die Django-Dokumente, die ich im anderen Thread verlinkt habe

Um es klar zu sagen, es waren nicht die eigentlichen Django-Dokumente. die Django-Dokumente sagen pip install Django (https://docs.djangoproject.com/en/1.8/topics/install/)

Es ist eigentlich eine schlechte Sache, wenn man bedenkt, wie -U derzeit funktioniert, Leute daran zu gewöhnen, install -U benutzen.

In Ihrem verlinkten Beispiel war es für redis das meiner Meinung nach keine Abhängigkeiten hat, also ist es in diesem Fall in Ordnung.

wird Verwirrung stiften, wenn die Leute anfangen, Ihr Tutorial durchzuarbeiten
mit einer alten Version [...] Du brauchst also definitiv einen einzigen "upstall"-Befehl

IDK, Es ist für mich nicht so offensichtlich, dass Tutorials den Leuten sagen sollten, dass sie im Allgemeinen aufrüsten sollen. Wenn jemand ein Tutorial für FOO macht und FOO bereits installiert hat, dann sollte er vielleicht nicht blindlings "upstall".... vielleicht würde ein Upgrade die bestehende Umgebung beschädigen.

Ich denke, die Tutorials sollten den Leuten sagen, dass sie "upstall" (großartiger Begriff!) installiert haben, eher neigen sie dazu, sich die neuesten Dokumente anzusehen.

Ich stimme auch zu, dass die Art und Weise, wie -U derzeit funktioniert, eine schlechte Angewohnheit ist, die Leute dazu zu bringen, es wahllos zu verwenden, aber das Wichtigste, was ich denke, ist das vorgeschlagene Verhalten, das ich nicht für eine schlechte Angewohnheit halte , aber eher eine gute Sache. Wenn Sie sicherstellen müssen, dass eine bestimmte Version installiert ist, sollten Sie == bereits verwenden die aktuell installierte Version ODER die neueste Version ist installiert (wobei ich mir immer noch kein Szenario vorstellen kann, in dem dies tatsächlich das ist, was jemand will).

Ich denke, die Tutorials sollten den Leuten sagen, dass sie "upstall" sollen

Aber noch einmal, was ist diese Umgebung, in der sie sich befinden, in der es offensichtlich in Ordnung ist, ein Upgrade durchzuführen? Wenn es sich um eine Python-Umgebung für ein Distributionssystem handelt, dann sicherlich nicht. Wenn es sich um eine andere Umgebung handelt, die für eine Anwendung vorgesehen ist, kann ein Upstall schädlich sein. Wenn es sich um eine Umgebung handelt, die sie gerade für das Tutorial erstellt haben, müssen sie nicht aktualisieren.

Ein wichtiger Punkt hierbei ist, dass PyPI kein "kuratiertes" Repo ist, wie es bei Distro-Repos der Fall ist. Sie können ziemlich sicher sein, dass ein "Upstall" vor einem Standard-Distributions-Repository sicher ist ... das wissen Sie bei PyPI nicht. Jedes Upgrade ist ein bisschen ein Glücksspiel. "install", wie es ist, ist konservativ.

Denken Sie daran, dass pip install sich wie ein "Upstall" ohne Fixing #988 verhalten wird, wird die Dinge kaputt machen.

Überlegen Sie, wo A und B installiert sind und A B<2 . Jetzt starte ich das neue pip install B , das B auf v3 oder was auch immer aktualisiert (weil ich die installierten Einschränkungen nicht berücksichtigt), und jetzt ist meine Umgebung kaputt.

für Leute, die sicherstellen müssen, dass die aktuell installierte Version ODER die neueste Version installiert ist (obwohl ich mir immer noch kein Szenario vorstellen kann, in dem dies tatsächlich das ist, was jemand will).

Es ist trivial, sich solche Szenarien auszudenken. Beispiel (leider nicht erfunden): derzeit wird statsmodels von den neuesten pandas (0.17.0) unterbrochen. Ich bin ein Benutzer von beiden. Ich habe eine Reihe von Python-Versionen installiert und venvs herumliegen. Ich weiß also, dass ich für jedes Python/venv pandas nur installieren möchte, wenn es noch nicht vorhanden ist. Wenn ja, werde ich wahrscheinlich auch statsmodels und dann wird "upstall" es kaputt machen.

@rgommers Hmm , du bist dir also absolut sicher, dass du nirgendwo einen Panda 0.17.0 in einer virtuellen Umgebung hast? Ich denke, es könnte passieren, obwohl ich denke, dass ich das wahrscheinlich mit pip install pandas!=0.17.0 oder pip install pandas<0.17 buchstabieren würde, aber ich denke, es ist nicht ganz unvernünftig, sich auf das zu verlassen, was Sie bereits installiert haben.

Hmm, Sie sind sich also absolut sicher, dass Sie nirgendwo einen Pandas 0.17.0 in einer virtuellen Umgebung haben?

Das ist nicht was ich sagte. Ich habe ein Venv mit Pandas 0.17.0, nur eines, in dem ich keine Statistikmodelle habe. pip install pandas<0.17 wird die Arbeit erledigen, aber ich war nicht auf die Idee gekommen, das zu verwenden (hauptsächlich, weil ich es nicht brauchte, der aktuelle Befehl install funktioniert für diesen Zweck).

Jedenfalls habe ich keine große Vorliebe für oder gegen Upstall. Ich wollte nur ein realistisches Szenario aufzeigen, als Sie sagten, Sie könnten sich keins einfallen lassen.

+1

Diese Diskussion scheint ins Stocken geraten zu sein, ohne zu einem Abschluss zu kommen. Jede Option in der Tabelle ist eine wesentliche Verbesserung gegenüber dem aktuellen Status. Es sieht so aus, als ob alle relevanten Vor- und Nachteile berücksichtigt wurden; Es gibt nur Meinungsverschiedenheiten über die relative Bedeutung von Rückwärtskompat gegenüber der optimalen API. Vielleicht können die Pip-Entwickler versuchen, eine Entscheidung zu treffen?

@rgommers haben sie wahrscheinlich eine Entscheidung getroffen? https://pip.pypa.io/en/stable/user_guide/#only -if-needed-recursive-upgrade

@rgommers haben sie wahrscheinlich eine Entscheidung getroffen? https://pip.pypa.io/en/stable/user_guide/#only -if-needed-recursive-upgrade

@Liso77 danke, aber nein - es ist wirklich die Diskussion in diesem Thread, die abgeschlossen werden muss. Die Dokumentation, auf die Sie verlinkt haben, weist nur hierher zurück.

@rgommers Von dem Link, den ich oben gepostet habe, habe ich gelesen, dass Entwickler einen Upgrade-Befehl
Ich bin sicher, Sie haben mehr über dieses Thema nachgedacht und Sie sehen subtilere Dinge, die ich tue. Also bitte schreibt was (wenn ihr sowas meint) noch offen ist. Wenn Sie meinen, dass es gut sein könnte, dass Entwickler hier explizit ihre Entscheidung schreiben und dieses Thema schließlich schließen - stimme ich zu.

Übrigens. Situation könnte viel weniger problematisch sein, wenn wir so etwas hätten wie

pip freeze > checkpoint.txt
pip checkout checkpoint.txt

was eine Rückkehr zur Installation an jedem "Checkpoint" garantieren könnte. (pip install -r ist im Moment nicht gut) Ich dachte daran, diesen Vorschlag in eine neue Ausgabe aufzunehmen, aber ich bin mir sicher, dass ich mehr studieren und analysieren muss, um einen wirklich nützlichen Vorschlag zu machen. Ich sehe, es gibt viele Vorbehalte, aber ich mag es wirklich, die Möglichkeit dazu zu haben

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>

Ich meine, das könnte (mit Hilfe von jemandem_trusted (oder einer Community mit vielen Komponententests) helfen) so etwas wie das oben beschriebene Pandas- und Statsmodels-Problem lösen.

(nützlich für dieses Thema ist auch: https://pypi.python.org/pypi/peep)

@Liso77 es ist einfach: Die Diskussion zu diesem Thema ist noch nicht abgeschlossen. Es wartet ein PR mit dem implementierten upgrade Befehl (gh-3194), aber die Pip-Entwickler (zumindest qwcode und @dstufft , und wahrscheinlich auch @xavfernandez und @pfmoore) müssen entscheiden, ob sie das wollen , oder sie möchten stattdessen das Verhalten von pip install ändern. Bis das passiert, wird sich nichts ändern.

+1

Es scheint also, dass die Einführung des neuen Upgrade-Befehls vereinbart wurde und die letzte ungeklärte Debatte ist, ob es einen "upstall" -Befehl geben sollte oder nicht, und wenn ja, welcher Hauptbefehl (installieren oder aktualisieren) sollte ihn als Schalter oder Standard erhalten .

Zusammen mit meiner persönlichen Meinung:

Ich denke, es lohnt sich, einen ausfallsicheren singulären Befehl für die Installation zu haben, _wenn nur_ für Fälle, in denen Sie programmgesteuert überprüfen möchten, ob eine Umgebung aus irgendeinem Grund auf dem neuesten Stand ist. Warum "programmatisch"? Weil es nicht interaktiv ist, dh es muss kein Benutzer auf einen Fehler, eine Warnung oder eine andere Nachricht reagieren, die ihn auf den Bruder- oder Schwesterbefehl verweist, weil ein Paket bereits existiert oder nicht existiert.
Optional könnte eine Eingabeaufforderung hinzugefügt werden, in der der Benutzer gefragt wird, ob er ein Upgrade oder eine Installation durchführen möchte, anstatt sich nur zu beschweren.

Allerdings sollte dieser "upstall"-Befehl nicht der Standard eines der beiden Befehle (install/upgrade) sein und erfordert daher den Aufruf einer Option. Dies fügt den semantisch klar definierten Verben "install" und "upgrade" mehr Klarheit hinzu, und meiner Meinung nach machen alle Paketmanager, die standardmäßig auf einem dieser Verben upstallieren, es falsch. Aufforderung zum Handeln (wie es yum zu tun scheint) ist in Ordnung.

Damit bleiben uns upgrade --install (kürzer als --install-missing ) und install --upgrade . Semantisch: "Upgrade auf die neueste Version [und installieren, wenn nicht vorhanden]" und "Neueste installieren [oder auf die neueste Version aktualisieren, falls bereits vorhanden]". Imo hier kein großer Unterschied. install --upgrade ist die bereits vorhandene Version und wäre erkennbar, aber nicht abwärtskompatibel.
Hier ist noch einer für die Mischung: Ein neuer Befehl namens install-upgrade (oder upstall ?), bei dem weder bei der Installation noch beim Upgrade die Option "auch das andere" verfügbar ist, aber ein neuer Befehl eingeführt wird mit klare Semantik an einer wichtigen Stelle: der Befehlsname selbst. Dies wäre meine Präferenz.

TL;DR : upgrade und upgrade-install einführen, install --upgrade veraltet. Alle Funktionen mit klarer Semantik.
Fügen Sie Nachrichten oder optional Aufforderungen zum Installieren und Aktualisieren von Befehlen hinzu, wenn deren Operationen aufgrund eines bereits vorhandenen oder nicht vorhandenen Pakets fehlschlagen.

Habe das heute morgen nochmal manuell gemacht. Gibt es Neuigkeiten zu dieser Funktionsanfrage?

+1

+1

+1

Alle, bitte nutzt die Daumen-hoch-Reaktion im OP und hört auf, den Posteingang aller zu spammen.

Da Pip ein anderes QA-Modell als Linux-Distributionen hat, bin ich mir ziemlich sicher, dass ein zufälliger Upgrade-All-Befehl nur ein Bruch in der Herstellung ist

pypi hat keine Datenbank mit Paketversionen und Kompatibilität, die tatsächlich verifiziert und getestet wurde.
also im Gegensatz zu einer Distribution mit QA hat pypi praktisch keine eigene QA und verlässt sich komplett auf die hochgeladenen Projekte (die qualitativ unterschiedlich sind)

Mit den aktuellen Einschränkungen bin ich davon überzeugt, dass es eher ein Fluch als ein Segen ist
Und wenn sich jemand fragt, warum Distributionen so veraltet sind, kostet die QA viel Zeit und Mühe ^^

Alle, bitte nutzt die Daumen-hoch-Reaktion im OP und hört auf, den Posteingang aller zu spammen.

Beachten Sie, dass wir eigentlich keine _irgendwelche_ Art von "Ich möchte das"-Antwort von Leuten brauchen. Wir sind uns bewusst, dass die Leute das wollen, was fehlt, ist jemand, der bereit ist, einen Fix zu entwickeln, der all die verschiedenen Bedenken und Probleme berücksichtigt, die bereits angesprochen wurden und die bei einer PR-Überprüfung unweigerlich auftauchen werden.

Ich persönlich würde es daher begrüßen, wenn die Leute davon absehen würden, dieses Problem zu pingen, es sei denn, sie verfügen über einen funktionierenden Code, der zumindest einen Ausgangspunkt für die Implementierung bietet - und sie sind bereit, ihn bis zur Implementierung zu verfolgen.

Ansonsten werden wir es nachholen, wenn wir können. Ich persönlich spreche dieses Problem regelmäßig an und bin ein Kern-Pip-Entwickler, daher kann ich garantieren, dass ich es tun werde, wenn ich selbst jemals genug Zeit habe, um daran zu arbeiten. In der Zwischenzeit "irgendwelche Fortschritte?" Kommentare neigen dazu, mich einfach zu demotivieren, weil sie sich meistens so anfühlen, als würden Leute das Recht fordern, mir zu diktieren, wie ich meine Hobbyzeit verbringe...

ein Ausgangspunkt für die Umsetzung

Ich dachte, das sei der Zweck von https://github.com/pypa/pip/pull/3194? Von da an mündete die Diskussion in mehrere Alternativen für die Befehlsbenennung und das Verhalten ohne einen Konsens der Core-Entwickler. Würde es helfen, mehrere dieser Alternativen zu implementieren? Oder braucht https://github.com/pypa/pip/pull/3194 nur eine Aktualisierung?

@sfriesel Du hast es verpasst "und bist bereit, es

Weit über 50 % der Arbeit an einem solchen Vorschlag sind „Management“ (Vorschläge dokumentieren, Diskussionen managen, Konsens herstellen). Es ist nicht unbedingt das, was die Leute gerne tun, aber mit einer Codebasis, die so weit verbreitet ist wie pip, ist es ein wesentlicher Bestandteil. (Und ja, das ist ein Problem - es ist viel schöner zu sagen "Ich schreibe Code als Hobby" als "Ich mache Projektmanagement als Hobby" :-))

@pfmoore Stimme voll und ganz zu.

Die Vielzahl von Vorschlägen und Diskussionen, die über die Jahre verteilt auf viele Standorte zu diesem Thema bezogen sind, macht es äußerst schwierig, sich diesem Thema zu nähern und sich in kurzer Zeit ein klares Bild zu machen .

@RonnyPfannschmidt

pypi hat keine Datenbank mit Paketversionen

Es ist wahr. Dies sind Informationen, die von den Paketen zur Laufzeit (der setup.py) bereitgestellt werden und den Prozess der Auflösung der Abhängigkeiten etwas komplexer machen. Darüber hinaus listen einige Pakete (sogar prominente wie scipy) aufgrund des Verhaltens der aktuellen Logik keine Abhängigkeiten (wie numpy) auf, wenn sie installiert sind, um unnötiges Neukompilieren zu vermeiden.

Das würde unter anderem durch PEP 426 gelöst werden, aber ich weiß nicht, was der Status dieses PEP ist.

@pfmoore

Beachten Sie, dass wir eigentlich keine "Ich möchte das"-Antwort von Leuten brauchen

Es ist einfach verlockend, +1 zu sagen oder einen Daumen nach oben zu drücken, um zu sagen, dass Sie dies gerne sehen würden. Es gibt der Person das Gefühl, etwas zu diesem Thema beigetragen und dazu beigetragen zu haben. Ich sage nicht, dass Pip-Entwickler motiviert oder überzeugt werden müssen, es ist nur so, dass das jeder sagen möchte. Und...

Ich würde es begrüßen, wenn die Leute davon absehen würden, dieses Problem zu pingen, es sei denn, sie haben einen funktionierenden Code

Wenn Sie einen Daumen nach oben setzen, erhalten Sie keine (nervigen) Benachrichtigungen / E-Mails und wir sehen immer noch die Anzahl der Personen, die Interesse gezeigt haben. Ich denke, das sollte niemanden stören, aber ich könnte mich irren.

Wenn Sie einen Daumen nach oben setzen, erhalten Sie keine (nervigen) Benachrichtigungen / E-Mails und wir sehen immer noch die Anzahl der Personen, die Interesse gezeigt haben. Ich denke, das sollte niemanden stören, aber ich könnte mich irren.

Ah, mir war nicht klar, dass dadurch die Benachrichtigungen vermieden werden. Ja, das ist eine gute Idee.

Der nächste Schritt dazu ist wahrscheinlich entweder das OP oder jemand anderes, der bereit ist, die Verantwortung für die PR zu übernehmen, eine Zusammenfassung der aktuellen Position im PEP-Stil zu verfassen, was die verschiedenen ausstehenden Probleme sind und was er als das vorschlägt Lösung für diese verschiedenen Probleme und eine Aufforderung zur Einreichung von Kommentaren, um die Diskussion wieder aufzunehmen.

Für was es wert ist, habe ich früher einen Bericht über dies und die Abhängigkeitsauflösung im PEP-Stil verfasst. Ich werde es aufteilen und aktualisieren, indem ich all die Dinge hinzufüge, die in den letzten Monaten vorgeschlagen wurden. Ich werde den für den Upgrade-Befehl als Gist posten, sobald er fertig ist (~ 2 Tage?) und von hier aus darauf verlinken.

Ich bin noch nicht bereit, die PR zu übernehmen. Ich beabsichtige, dazu beizutragen, die Diskussionen neu zu entfachen und zu einem endgültigen Design zu gelangen, das umgesetzt werden kann. Wenn einige Sachen um mich herum Plan laufen, soll ich in der Lage sein , dies bis zur Umsetzung zu folgen , aber ich will nicht durch nur noch , um es im Anschluss an diesen zu begehen.

/cc @qwcode @dstufft @pfmoore @xavfernandez

Hier ist der Link zu meinem Bericht: https://gist.github.com/pradyunsg/a5abeac4af90fbdc54bb266c32c0d2d8

Ich habe anfangs nur auf verschiedene Orte (~30 Links) verlinkt, auf die der Leser verweisen kann, und versucht, alle Kommentarthreads zu kopieren und dann zu bearbeiten, um sie anzupassen. Das Dokument war ziemlich lang und meine Meinungen sind durchgerutscht. Am Ende habe ich bei Null angefangen. Es ist jetzt jedoch kürzer und nicht rechthaberisch. Ich habe es immer noch als WIP markiert.

Wenn es irgendwelche Probleme gibt, kommentieren Sie bitte das Wesentliche. Ich werde die Korrekturen so schnell wie möglich vornehmen.

WARNUNG: _LEICHT_ LANGER KOMMENTAR VORAUS

Ich mag die Idee, das bestehende Verhalten von --upgrade beheben. Gibt es diesbezüglich andere Bedenken als die Abwärtskompatibilität? Das Hinzufügen eines upgrade Befehls scheint keine gute Idee zu sein, da sich Installation und Upgrade stark überschneiden.

FWIW, git hat etwas Ähnliches gemacht, was wir über --upgrade besprechen und das Standardverhalten von git push im Jahr 2014 geändert haben .

Wenn Sie daran interessiert sind, das Verhalten von pip install --upgrade ändern, finden Sie hier einen Seeding-Vorschlag (siehe P1) für diese Diskussion:

• Ab der nächsten Hauptversion (9.0) gibt pip install --upgrade eine Warnung aus:

```
PipDeprecationWarning: pip wird die Aktualisierung von Abhängigkeiten auf die neueste Version beenden
Version bedingungslos standardmäßig ab Version 11.0.

Um das aktuelle Verhalten beizubehalten, nachdem sich das Standardverhalten geändert hat, zu
der Installationsbefehl übergeben --upgrade-strategy eager .

Um das neue Verhalten sofort zu verwenden, zum Installationsbefehl
passieren --upgrade-strategy non-eager .

Um diese Nachricht zu löschen,.

Für weitere Details lesen Sie.
```

Die verlinkte Dokumentationsseite würde einen schnellen Überblick über die Änderung und ihre Auswirkungen geben. Es würde dann die häufigste Frage beantworten: "Was soll ich tun?" und "Welche Upgrade-Strategie sollte ich verwenden?" auf die direkteste Weise zumutbar.

• Die Nachricht könnte eine Bereinigung gebrauchen.
• Die Option könnte sogar 2 Flags sein, --upgrade-eager und --upgrade-non-eager oder so. Das ist Bikeshedding, also der letzte Schritt.
  
  
  
  • Sofern nicht etwas Drastisches passiert, ändert pip install --upgrade in Version 11.0 das Verhalten beim Upgrade von Abhängigkeiten auf nicht eifrig.
  
  

Bearbeiten: Ich habe einen 3-Hauptversionszyklus für die Änderung festgelegt, nur um den Leuten mehr Zeit zum Umschalten zu geben. Es könnte unnötig sein. Vielleicht reicht es, wenn eine Hauptversion Warnungen ausdruckt und die nächste Änderung vornimmt?

@dstufft hatte eine ähnliche (gleiche?) Idee.

Wenn ein Upgrade-Befehl der richtige Weg ist, ist hier ein Seeding-Vorschlag für die Wiederaufnahme dieser Diskussion (beziehen Sie sich auf P2, wenn Sie möchten):

1. pip upgrade kopiert die meisten Optionen und Verhaltensweisen von pip install .
2. --dry-run Flag wird zu install und upgrade Befehlen hinzugefügt, die ausgeben, was pip versucht, wenn es tatsächlich ausgeführt würde.
3. pip install <out_of_date_pkg> ändert das Verhalten nicht.
4. pip upgrade <not_installed_pkg> würde fehlschlagen.
5. pip upgrade <up_to_date_pkg> würde nichts tun, sagen, warum es nichts getan hat und beenden mit einem Null-Exit-Code.
6. pip upgrade <out_of_date_pkg> würde ein nicht eifriges rekursives Upgrade durchführen.
   
   
   
   • :white_check_mark: Standardmäßig auf nicht eifrige rekursive Upgrades
   
   
7. pip upgrade --eager package würde sich wie das heutige pip install --upgrade verhalten.
   
   
   
   • :white_check_mark: Opt-in für das aktuelle Verhalten zulassen
   
   
8. pip install --upgrade würde ein RemovedInPip10Warning drucken.
   Denn es würde entfernt werden.

Außerdem, was ist Ihre Meinung zu:

1. Den Upgrade-Befehl interaktiv machen? (so etwas wie das, was apt-get macht)
   
   
   
   • pip install <pkg> sich wie die Installationsdatei des Paketmanagers des Betriebssystems zu verhalten?
   
   
2. Haben Sie standardmäßig --only-binary im neuen Upgrade-Befehl?
   
   
   
   • Wenn es in Ordnung ist, was ist mit dem Hinzufügen von --only-source und --no-source im Upgrade-Befehl?
   
   
3. Hinzufügen einer Option zum "Halten" der Aktualisierung eines Pakets? IMO, dies ist eine Voraussetzung für upgrade-all .
4. Ist es sinnvoll, zwischen diesen Fällen zu unterscheiden, dh unterschiedliche CLI zu erfordern?
   
   
   
   • installieren: nicht installiert -> aktuell
   
   
   • Upgrade: veraltet -> aktuell
   
   
   • upstall: {nicht installiert, veraltet} -> aktuell
   
   

Ich habe nichts über die "Installation als Upstall" vorgeschlagen, weil ich keine starke Meinung dazu habe. Es stimmt mit Paketmanagern auf Betriebssystemebene überein, wäre aber eine wichtige bahnbrechende Änderung. Ich bin mir nicht sicher, wie nützlich es wäre oder wie das genaue Verhalten und die Schnittstelle aussehen würden ...

Vielleicht hilft es, darüber zu schlafen.

Persönlich sehe ich keinen großen Wert darin, einem Verhalten zu folgen, über das, wenn überhaupt, nur wenige Menschen glücklich sind. Ich frage mich, ob es besser oder schlechter wäre, einen für Python 2 (umfassende Stabilität) und einen anderen für Python 3 (umfassende Veränderungen) zu haben.

@ekevoo

Ich frage mich, ob es besser oder schlechter wäre, einen für Python 2 (umfassende Stabilität) und einen anderen für Python 3 (umfassende Veränderungen) zu haben.

Erstens, das ist off-topic. Zweitens, wenn Sie dies tun, wird es am Ende zu Divergenzen kommen. Das wird Leute, die derzeit Python 2 verwenden, entfremden, weil es (hoffentlich) eines Tages EOL erreichen wird und sie zu Python 3 wechseln müssen, um sich an ein anders verhaltendes Werkzeug anzupassen. Daher sollte pip keine Divergenz bewirken (und wird es auch nicht, IMO). Könnte es dann genauso gut in einem einzigen Tool zusammenhalten.

OTOH, ich verstehe, was Sie darüber denken, wie viel Abwärtskompatibilität akzeptabel ist ...

Eine Warnung in Pip 9 plus zusätzliche Optionen, um das Verhalten von pip install --upgrade , --eager/non-eager (oder einem anderen Namen) zu optimieren, scheint mir in Ordnung zu sein.

Stoßen. Noch eine Benachrichtigung für alle.

@pfmoore @dstufft @qwcode Ich möchte nicht neugierig sein, aber könnten Sie sich bitte etwas Zeit dafür nehmen, am Wochenende oder in der kommenden Woche?

Okay, also meine Kommentare:

Zu den beiden Möglichkeiten habe ich keine Meinung. Wählen Sie diejenige aus, die Sie für die bessere Option halten, implementieren Sie sie und wir werden sehen, wie es weitergeht.

Zu Ihren weiteren Fragen:

1. Ich bin -1, wenn es darum geht, den Befehl interaktiv zu machen. Es sei denn, es gibt ein bestimmtes Problem, über das der Benutzer eine Entscheidung treffen muss, nach dem Motto "Diese Konsequenz dessen, wonach Sie gefragt haben, war Ihnen eindeutig nicht bewusst und könnte ein Problem sein - möchten Sie fortfahren", dann ist es einfach nutzloses Geräusch. Ich bin generell gegen "Sind Sie sicher"-Aufforderungen. Wenn Sie einen konkreten Vorschlag für eine Aufforderung haben, der Ihrer Meinung nach hinzugefügt werden sollte, können Sie ihn gerne mit den enthaltenen Details erneut fragen.
2. Wir sollten Upgrades nicht von Installationen unterscheiden, also nein zu --only-binary standardmäßig. Für meinen persönlichen Gebrauch werde ich wahrscheinlich immer zuerst pip upgrade --only-binary wollen, aber ich _will_, dass es explizit ist.
3. Ich bin mir nicht sicher, was Sie mit dem "Halten" von Updates meinen. Bitte klären Sie. Aber als allgemeine Antwort würde ich sagen, machen Sie sich zunächst keine Mühe, lassen Sie uns die anfängliche PR frei von "optionalen Extras" - sie können später hinzugefügt werden.
4. Ist das nicht das Hauptthema der Debatte in den verschiedenen Diskussionen über dieses Feature? Beeinflusst es zunächst nicht die grundlegende Frage von install --upgrade vs. upgrade ? Ich kann mich nicht erinnern, dass diese Frage gelöst wurde, daher bin ich ein wenig überrascht, dass Sie eine "einfache" Antwort auf diese Frage erwarten? Ich habe sicherlich keine gute Antwort.

(Übrigens habe ich keinen einfachen Zugriff auf das Wesentliche. Wenn es also Inhalte gibt, die nicht in Ihrer Zusammenfassung enthalten sind, habe ich sie leider übersehen).

Ich weiß, es ist harte Arbeit, eine PR zu schreiben, und es ist demotivierend, wenn sie sich in Debatten und Fragen verzettelt, aber letztendlich denke ich, dass jemand eine schreiben und sie veröffentlichen muss "Dies ist die Lösung". Ich schlage vor - irgendwelche Kommentare?"

Wir sollten Upgrades nicht anders machen als Installationen [snip] Ich werde wahrscheinlich immer pip upgrade --only-binary in erster Linie wollen, aber ich möchte, dass es explizit ist.

Wenn Sie wahrscheinlich immer etwas wollen, sollte es Standard ^{1 sein} . Aber ich denke, dass es eine gute Idee ist, die Konsistenz zwischen install und einem möglichen upgrade Befehl aufrechtzuerhalten.

Ich bin mir nicht sicher, was Sie mit dem "Halten" von Updates meinen.

Ich lasse dies ruhen, bis wir über das Hinzufügen von Upgrade-all-Funktionen sprechen.

Notiz an mich selbst: apt-mark Konzepte für Pip

Ich bin -1, wenn es darum geht, den Befehl interaktiv zu machen. Es sei denn, es gibt ein bestimmtes Problem, über das der Benutzer eine Entscheidung treffen muss

Dito.

Ist das nicht das Hauptthema der Debatte in den verschiedenen Diskussionen über dieses Feature?

Genau deshalb wollte ich wissen, was ihr denkt.

Ich kann mich nicht erinnern, dass diese Frage gelöst wurde, daher bin ich ein wenig überrascht, dass Sie eine "einfache" Antwort auf diese Frage erwarten?

Ich erwarte noch keine "einfache" Antwort. Ich hoffe, wir kommen durch Diskussion zu einer, vorzugsweise einfachen, Antwort.

Übrigens habe ich keinen einfachen Zugriff auf das Wesentliche. Wenn es also Inhalte gibt, die nicht in Ihrer Zusammenfassung enthalten sind, habe ich es verpasst, sorry

Es ist mehr als eine Zusammenfassung, es ist eine Fortsetzung der Zuschreibung. Bitte lesen Sie es, sobald Sie dies tun können.

Wählen Sie diejenige aus, die Sie für die bessere Option halten, implementieren Sie sie und wir werden sehen, wie es weitergeht.
[schnipsen]
Ich denke, jemand wird eine [PR] schreiben müssen und sie veröffentlichen als "Dies ist die Lösung, die ich vorschlage - irgendwelche Kommentare?"

Ich dachte nach dem Motto "Lass uns zuerst genau herausfinden, was wir wollen" und dann loslegen und es umsetzen.

^{1 es} sei denn, es zerstört die Welt eines anderen

Wir sollten Upgrades nicht anders machen als Installationen [snip] Ich werde wahrscheinlich immer pip upgrade --only-binary in erster Linie wollen, aber ich möchte, dass es explizit ist.
Wenn Sie wahrscheinlich immer etwas wollen, sollte es standardmäßig sein. Aber ich denke, dass die Aufrechterhaltung der Konsistenz über die Installation und einen möglichen Upgrade-Befehl hinweg eine gute Idee ist.

Wenn _jeder_ wahrscheinlich immer etwas will, sollte es (vielleicht) eine Vorgabe sein. Aber ich habe nur meine eigenen Vorlieben kommentiert. Ich habe ehrlich gesagt keine Ahnung, ob --only-binary ist, was die meisten Leute wollen (es hängt wahrscheinlich davon ab, ob wir langfristig oder kurzfristig sprechen).

Es gibt einen starken Unterschied zwischen Binärdateien (Wheels), Quellen, die überall erstellt werden können (normalerweise reines Python) und Quellen, die einen Compiler oder andere externe Voraussetzungen benötigen. Leider kann pip die beiden letzteren nicht unterscheiden, und das macht --only-binary weniger nützlich (insbesondere als Standard).

Und ich schätze die Konsistenz zwischen den Befehlen über die "Tue, was ich meine"-Standardeinstellungen, was wiederum nur meine persönliche Präferenz sein kann.

Es ist mehr als eine Zusammenfassung, es ist eine Fortsetzung der Zuschreibung. Bitte lesen Sie es, sobald Sie dies tun können.

Ich habe es gelesen, es hat nicht viel hinzugefügt, was mir nicht bewusst war (da ich die verschiedenen Threads dazu verfolgt habe), also bleiben meine Kommentare. Aber es ist eine gute Zusammenfassung des aktuellen Stands, also danke fürs Schreiben.

Wir sollten Upgrades nicht anders machen als Installationen [snip] Ich werde wahrscheinlich immer pip upgrade --only-binary in erster Linie wollen, aber ich möchte, dass es explizit ist.

Wenn Sie wahrscheinlich immer etwas wollen, sollte es standardmäßig sein. Aber ich denke, dass die Aufrechterhaltung der Konsistenz über die Installation und einen möglichen Upgrade-Befehl hinweg eine gute Idee ist.

Wenn _jeder_ wahrscheinlich immer etwas will, sollte es (vielleicht) eine Vorgabe sein. Aber ich habe nur meine eigenen Vorlieben kommentiert.

Klarstellung: Das "Sie" in meinem Kommentar bezog sich auf die Endbenutzer (Plural), wobei @pfmoore in diesem speziellen Fall einer war. Ich hätte wirklich ein anderes Wort verwenden sollen.

Einige Gedanken zu Upgrade-Strategien. Persönliche Meinung, das alles natürlich :-)

Angenommen, ich mache pip upgrade foo

1. Wenn foo derzeit nicht installiert ist, erwarte ich einen Fehler. Für mich sind "Installieren" und "Upgrade" zwei separate Aktivitäten, die ich nicht zusammenführen möchte.
2. Wenn keine neuere Version als die aktuell installierte Version verfügbar ist (siehe unten zu --only-binary ), erwarte ich eine Benachrichtigung, dass nichts zu tun ist.
3. Andernfalls erwarte ich, dass foo auf die neueste Version aktualisiert wird. Darum habe ich gebeten, also sollte es passieren.
   
   
   
   • Ich bin nicht davon überzeugt, dass das Hinzufügen von Einschränkungen sinnvoll ist. Was würde pip upgrade foo>1.0 bedeuten, wenn ich 1.1 installiert habe, aber 1.2 verfügbar ist? Es ist kein Upgrade, wenn 1.1 dort belassen wird, aber wenn es auf 1.2 aktualisiert wird, ist es dasselbe wie pip upgrade foo . Möglicherweise könnten Sie etwas wie pip upgrade foo<2.0 Bedeutung zuschreiben, aber das wäre IMO ein sehr ungewöhnlicher Fall und die Komplexität nicht wert. Nehmen wir also an, pip upgrade braucht nur eine Liste von Paketnamen (im Gegensatz zu Anforderungen).
   
   
   • Ebenso kann ich pip upgrade <path_to_archive/wheel> nicht interpretieren. Nehmen wir an, es ist zunächst nicht erlaubt.
   
   
4. Möglicherweise möchte ich Pip erlauben oder nicht, dass er versucht, aus dem Quellcode zu erstellen (dies muss eine Entscheidung des Benutzers sein, da pip nicht sagen kann, ob das Bauen aus dem Quellcode funktioniert, und es nicht möglich ist, es mit einer anderen Version erneut zu versuchen, wenn a Quell-Build schlägt fehl). Also muss --only-binary eine Benutzeroption sein, und wenn angegeben, bedeutet dies, dass pip die Quellverteilung ignorieren sollte, wenn er herausfindet, "was verfügbar ist". (Wir könnten natürlich standardmäßig nur Binärdateien verwenden und eine Option --allow-source , aber upgrade sollte in dieser Hinsicht mit install übereinstimmen).

OK, das sind also die explizit angegebenen Pakete. Ich bezweifle, dass da irgendetwas Kontroverses ist (außer vielleicht für die Teile, von denen ich sage, dass wir sie bis später weglassen sollten). Nun zu den Abhängigkeiten.

• Die wichtigste Regel meiner Meinung nach ist, dass wir niemals etwas mit Abhängigkeiten tun sollten, es sei denn, wir aktualisieren das benutzerdefinierte Paket _eigentlich_. Das ist also der Ausgangspunkt. Wenn das Ziel nicht aktualisiert wird, betrachten Sie die Abhängigkeiten nicht einmal. Immer.
• Meiner Ansicht nach müssen _alle_ Abhängigkeiten gleich behandelt werden - ob es sich um direkte oder indirekte Abhängigkeiten des benutzerdefinierten Pakets handelt, ist irrelevant. Das finde ich nicht umstritten.
• Eine grundlegende Annahme hierbei sollte sein, dass der Benutzer die Liste der Abhängigkeiten nicht kennt. Implizite Abhängigkeiten haben schließlich den Zweck, dass der Benutzer sie _nicht_ verwalten muss. Daher ist jede Lösung, bei der der Benutzer explizit über eine Abhängigkeit informiert werden muss, meiner Ansicht nach fehlerhaft (es sei denn, ein Befehl schlägt mit einer Nachricht über eine bestimmte Abhängigkeit fehl, in diesem Fall könnte der Benutzer mit dieser in einer Option angegebenen Abhängigkeit erneut ausgeführt werden - aber wir sollten in so vielen Fällen wie möglich zum ersten Mal arbeiten möchten, daher sollte dies nicht als die Norm angesehen werden).
• Ich würde sagen, dass der Ansatz standardmäßig darin bestehen sollte, nur Abhängigkeiten zu aktualisieren, die aktualisiert werden müssen, um die neuen Einschränkungen zu erfüllen. Hier lauert ein böses Problem, da sich die Einschränkungen ändern können, je nachdem, was aktualisiert wird. Aber ob wir dieses Problem vollständig lösen oder einfach eine "Best-Effort" -Lösung versuchen, ist nicht so wichtig (ich bezweifle, dass komplexe Abhängigkeitsgraphen mit widersprüchlichen Einschränkungen im wirklichen Leben üblich sind). Der wichtige Punkt ist der Grundsatz, dass wir nichts aktualisieren, was der Benutzer nicht um ein Upgrade gebeten hat, es sei denn, wir müssen es tun.
• Ein Flag zu haben, das sagt, "alles auf die neueste Version aktualisieren" könnte nützlich sein (zumindest aus Gründen der Abwärtskompatibilität). Noch besser wäre es, Tools (wahrscheinlich außerhalb von pip) zu haben, die Upgrade-Optionen analysieren und darüber berichten. Dann könnten die Nutzer selbst entscheiden. Aber ich weiß nicht, ob ich selbst jemals eine Notwendigkeit für eine dieser Optionen sehen würde.
• Anstelle einer "eifrigen Upgrade"-Option würde ich viel eher einen upgrade-all Befehl wünschen (oder upgrade --all wenn wir bei einem einzigen Befehl bleiben wollen). Dies sollte semantisch identisch mit upgrade wobei jedes installierte Paket auf der Befehlszeile aufgeführt ist. Sobald ich blinde Upgrades von Paketen durchführe (normalerweise kenne ich den Abhängigkeitsbaum meiner Pakete nicht oder habe ihn nicht dokumentiert), möchte ich wahrscheinlich nur "alles". Umso mehr, wenn ich virtuelle Umgebungen verwende, um Dinge zu isolieren.
• Die Frage zu --only-binary wird hier erneut angezeigt. Wenn der Benutzer --only-binary für das Haupt-Upgrade angibt, sollte natürlich davon ausgegangen werden, dass Abhängigkeiten --only-binary implizieren. Aber selbst wenn der Benutzer Quellinstallationen beim Aktualisieren des Hauptpakets zulässt, erscheint das Einführen des Risikos eines Fehlers bei der Durchführung eines Quell-Upgrades einer Abhängigkeit unvernünftig. Daher würde ich vorschlagen, dass wir immer nur Binärdateien zum Aktualisieren von Abhängigkeiten in Betracht ziehen sollten, es sei denn, der Benutzer lässt die Quelle ausdrücklich zu. Das würde bedeuten, dass eine Option --allow-source dep1,dep2,... . Ich erwarte, dass dieser Vorschlag umstritten ist, aber betrachte ein reines Python-Paket foo , das nur in Quellform verteilt wird, das von numpy abhängt. Wir haben foo 1.0 abhängig von numpy >=1.10 und foo 2.0 abhängig von numpy >=1.11. Der Benutzer hat foo 1.0 und möchte ein Upgrade durchführen. Sie haben nicht die Mittel, um numpy zu bauen. Sie müssen Quell-Upgrades für foo zulassen, aber sie wollen keine Zeit damit verschwenden, numpy 1.11 zu bauen (oder schlimmer noch, die Erstellung könnte funktionieren, aber einen nicht optimierten Build ergeben, der ihr System zerstört). Sie könnten natürlich --only-binary numpy angeben, aber sie wissen vielleicht nicht einmal, dass foo von numpy abhängt.

Das ist alles. Für mich sind die Anforderungen ziemlich klar (und ehrlich gesagt glaube ich nicht, dass sie besonders umstritten sind, wenn wir Umsetzungsprobleme ignorieren). Die Implementierung ist hier jedoch der Killer (im Grunde erfordert das Obige so ziemlich einen vollständigen SAT-Solver-Ansatz, wie zuvor erörtert wurde). Welche Kompromisse wir eingehen, weil die Implementierung eines SAT-Solvers zu schwierig ist, werden wahrscheinlich die Debatten führen.

Die Herausforderungen bei der Umsetzung sind meines Wissens:

1. Ein vollständiger SAT-Solver ist schwer. Ich weiß nicht genug, um zu verstehen, welche Alternativen einfacher sind und wie sie sich von einem SAT-Solver unterscheiden. (Nun, ein eifriges Upgrade ist, glaube ich, einfach genug - deshalb machen wir es im Moment). Insbesondere dann, wenn wir eine Situation bekommen, in der wir etwas aktualisieren, das nach dem einfachen Prinzip "Nichts aktualisieren, was Sie nicht müssen" sagt, nicht hätte aktualisiert werden sollen.
2. Ich habe alles außer den grundlegendsten Abhängigkeitsbeschränkungen beschönigt. Sobald wir uns auf Obergrenzen für Versionen oder Listen zulässiger Versionen einlassen, wird es unangenehm. Aber realistisch gesehen sind solche Fälle wahrscheinlich ziemlich selten (ich würde mich freuen, wenn jemand nach tatsächlichen Abhängigkeitsinformationen von PyPI recherchiert - ich kann das versuchen, aber ich bezweifle, dass ich die Zeit dazu bekomme).
3. Wenn wir mehrere Ziele haben - pip upgrade a b c - behandeln wir dies als 3 separate Aktionen, "Upgrade a", dann "Upgrade b", dann "Upgrade C", oder führen wir die 3 zu einer einzigen "kombinierten" zusammen Aktion irgendwie (beachten Sie, dass, weil ich vorschlage, Abhängigkeiten anders als Ziele zu behandeln, dies _nicht_ dasselbe ist wie pip upgrade dummy wo Dummy von a, b und c abhängt und wir annehmen, dass Dummy aktualisiert wurde).

Wenn jemand einen der obigen Kommentare oder Behauptungen bestreiten möchte, ist das großartig. Das meiste davon ist nur meine Meinung, und ich arbeite ehrlich gesagt nicht an komplexen Umgebungen - meine Verwendung wird wahrscheinlich hauptsächlich darauf abzielen, eine Systeminstallation und ein paar virtuelle Umgebungen unter Windows aufrechtzuerhalten (daher sind Debatten über Binär- und Quellinstallationen wichtig für mich, aber komplexe Abhängigkeitsgraphen nicht so sehr). Je mehr Anwendungsfälle wir mit unseren Annahmen vergleichen können, desto besser.

Wir haben also derzeit zwei Operationen, pip install und pip install --upgrade , aber ich denke, dass diese beiden Dinge etwas bewirken, was im wirklichen Leben eigentlich niemand passieren möchte.

Für pip install wir dieses seltsame Verhalten, bei dem Sie möglicherweise die neueste Version erhalten (oder auch nicht!), basierend auf dem, was bereits auf Ihrem System installiert ist. Ich denke, diese Art von Seltsamkeit macht die Verwendung von Pip schwieriger, und ich denke nicht, dass es wirklich viel Sinn macht (in welcher Situation wäre es Ihnen wichtig, kein Upgrade durchzuführen, aber Sie möchten immer noch die neueste Version installieren, wenn Sie dies noch nicht getan haben?) es?). Ich denke, dass die Tatsache, dass dieser Befehl dieses seltsame Vielleicht-neueste-vielleicht-nicht-Verhalten hat, der Grund dafür ist, dass viele Leute nach pip install ---upgrade als Hauptbefehl greifen und nicht nach pip install .

pip install --upgrade ist jedoch nicht viel besser, obwohl es Ihnen ein konsistentes Verhalten verleiht, es ist übermäßig eifrig, es erstreckt sich auf ein vollständiges Upgrade von _allem_, von dem der Benutzer möglicherweise nicht einmal weiß, dass es in seinen pip install --upgrade verwickelt ist

Ich denke, wir sollten hier einen Pfad finden, um `pip install ... more consistent. In that I mean pip install zu machen, sollte immer die neueste akzeptable Version haben (bei gegebenen Bezeichnern und Modifizierer-Flags wie--only-binary ``) unabhängig davon, was zuvor installiert wurde.

Ich denke, dass es in Ordnung wäre, diesem Befehl eine Art von --eager oder --recursive oder --upgrade-all-the-things zu geben.

Ich denke nicht, dass ein pip upgrade Befehl, der eine Liste von Paketen benötigt, etwas ist, was wir tun sollten. Ich denke, wenn wir einen solchen Befehl hinzufügen, sollte er verwendet werden, um einfach alles, was installiert ist, auf die neuesten Versionen zu aktualisieren (unter Berücksichtigung von Informationen zur Abhängigkeitskette sowie von Modifikatoren wie --only-binary ).

Hä? Also schlägt pip install foo nicht immer fehl, wenn foo installiert ist? Das scheint mir falsch zu sein, ich würde erwarten, dass es nur "bereits installiert" sagt.

Ich bin nicht daran interessiert, dass pip install "installieren oder aktualisieren" ist. Es ist besser, explizit zu sein und so.

Im Moment "fehlt" pip install foo nie, je nachdem ob etwas installiert ist oder nicht, es wird einfach nichts tun und sagen, dass X bereits installiert ist. Meine Behauptung ist, dass Verhalten nicht sehr nützlich ist. "Behaupten, dass irgendeine Version, irgendeine Version, was auch immer installiert ist" scheint mir kein nützliches Verhalten zu sein. Es passt auch nicht zu anderen Paketmanagern, die ich gewohnt bin, apt-get oder so zu mögen.

OK, ich kann sehen, dass dieses Verhalten nicht nützlich ist (obwohl ich persönlich das stillschweigende Akzeptieren von "bereits installiert" als ziemlich harmlos halte). Aber ich würde es vorziehen, wenn eine Installation eines bereits installierten Pakets fehlschlägt, anstatt es aktualisieren zu lassen.

Was würden Sie von pip install foo-1.0-none-any.whl erwarten, wenn foo 2.0 bereits installiert wäre? Herunterstufen? Stille nichts tun? Ich würde lieber einen netten, einfachen "bereits installierten" Fehler sehen als ein komplexes Regelwerk, an das sich die Leute in der Praxis wahrscheinlich nicht erinnern würden.

Ich habe nicht viel Erfahrung mit Linux-Paketmanagern, daher kann ich die Ähnlichkeiten (oder anderweitig) mit pip nicht kommentieren. Aber ich glaube nicht, dass ich erwarten würde, dass apt-get install foo aktualisiert wird, also kann ich nur antworten, dass ich das auch seltsam finden würde, wenn Sie sagen, dass dies der Fall ist.

"Behaupten, dass irgendeine Version, irgendeine Version, was auch immer installiert ist" scheint mir kein nützliches Verhalten zu sein.

Kurze Nebenfrage dazu: Was ist mit "Bestätigen Sie, dass diese spezielle Version installiert ist"?

Egal, dieses Verhalten haben wir heute.

@pfmoore :

Was würden Sie von pip install foo-1.0-none-any.whl erwarten, wenn foo 2.0 bereits installiert ist? Herunterstufen? Stille nichts tun? Ich würde lieber einen netten, einfachen "bereits installierten" Fehler sehen als ein komplexes Regelwerk, an das sich die Leute in der Praxis wahrscheinlich nicht erinnern würden.

Huh, Erwartungen sind überraschende Dinge. Ich würde sagen, dass Pip in diesem Fall _offensichtlich_ downgraden sollte. Der Benutzer hat ausdrücklich gesagt, dass er dieses spezielle Rad von Pip installieren möchte, also sollte pip dieses spezielle Rad installieren. Daran ist nichts Komplexes. Aber der Fall "Verteilungspfad/Datei ist explizit angegeben" ist #536 -- wahrscheinlich sollten wir diese Diskussion mehr darauf konzentrieren, was passiert, wenn der Benutzer "pip install foo" sagt, was zum Paketindex geht und ein foo 2.0 findet. wenn foo 1.0 bereits installiert ist.

Ich stimme Donalds Position hier sehr zu. Wenn wir von der Frage ausgehen "was soll pip install tun?", dann kann ich sehen, wie man argumentieren könnte, dass im Namen 'install' steht, also sollte es nur Dinge installieren, sie niemals aktualisieren ( naja, es sei denn, es gibt eine Einschränkung). Aber wenn wir von der Frage ausgehen "Welche Operationen wollen die Benutzer?", dann ist ein Befehl, der möglicherweise die neueste installiert oder Sie mit einer alten Version zurücklässt, wirklich seltsam und nicht intuitiv. Ich behaupte, dass in 99% der Fälle, in denen Benutzer pip install x , dies daran liegt, dass sie (a) entweder nicht sicher sind, ob es installiert ist oder es nicht wissen, UND (b) sicherstellen möchten, dass sie lassen Sie es installieren, da sie es zum ersten Mal verwenden werden. (Wenn es nicht das erste Mal wäre, wüssten sie, dass es installiert wurde, also würden sie pip install nicht ausführen.) In dieser Situation ist es das Richtige, ihnen die neueste Version zur Verfügung zu stellen.

@nchammas :

Was ist mit "Bestätigen, dass diese spezielle Version installiert ist"? Das scheint mir nützlich zu sein, da ich einen idempotenten Installationsbefehl habe.

Für "spezifische Version" gibt es pip install x==<version> .

Ich kann mir auch vorstellen, dass es für einige Arten von Scripting/programmatischem Gebrauch nützlich sein könnte, einen pip require x Befehl zu haben, der dieselbe Semantik hat wie die Installation eines Pakets mit Dist-Requires: x , dh es stellt sicher, dass einige Version installiert ist, aber ohne Garantie, was. Dies wäre jedoch ein Befehl auf niedrigerer Ebene, der nicht für Endbenutzer gedacht ist.

Eine Möglichkeit, über den Unterschied zwischen diesen nachzudenken: Wenn x nicht installiert ist, dann wäre es in Ordnung, wenn pip require x eine beliebige alte Version installiert. (Und zum Teufel, vielleicht sollte es das, um die Leute dazu zu zwingen, sich dagegen zu wehren .) Aber niemand würde jemals akzeptieren, dass pip install x irgendeine zufällige alte Version installiert.

(Dies ist ein Gedankenexperiment, ich bin nicht wirklich dafür, dass einfache Dist-Requires: x oder pip require x in einer Umgebung ohne x eine zufällige alte Version von x auswählen sollten

Nun, ich denke, es gibt auch einen anderen Fall, in dem Benutzer pip install x , wenn sie bereits wissen, dass es installiert ist, aber sie sind an Systeme mit dem Verhalten im Debian-Stil gewöhnt, bei denen install immer aktualisiert wird . Offensichtlich möchten diese Benutzer auch, dass es aktualisiert wird :-).

Ich würde lieber keinen pip upgrade Befehl hinzufügen.

pip-Benutzer haben bereits einige Erwartungen an das Verhalten von pip.
Der Hauptschmerzpunkt kommt vom pip instal --upgrade Standardverhalten, also konzentrieren wir uns darauf.

Eine Warnung in Pip 9 plus zusätzliche Optionen zum Optimieren des Verhaltens von pip install --upgrade , (--eager/non-eager) gefolgt von einer Änderung des Standardverhaltens in Pip 10 scheint einfach genug, sollte den Hauptschmerz beseitigen Ursprung und unterbricht nicht das mentale Modell von Pip-Benutzern.

Ja, ich versuche definitiv, dies von "Welche Operationen möchte ein Benutzer ausführen" im Vergleich zu "Welche Operationen sollte der X-Befehl ausführen" anzugehen. Ich nehme dann diese Operation auf hoher Ebene, von der ich _glaube_, dass Benutzer sie ausführen möchten, und versuche, sie einem einzelnen benannten Befehl zuzuordnen (so explizit es auch sein mag, pip install-the-latest-version ist nicht sehr benutzerfreundlich). .

Das ist natürlich alles sehr unscharf, aber ich kann sagen, dass ich in 99% der Fälle pip install -U <whatever> tue, weil dies am besten zu dem passt, was ich von einem Installationsprogramm erwarte, wenn man die derzeit verfügbaren Versionen berücksichtigt. Ich sehe auch in verschiedenen Automatisierungsskripten Leute, die pip install -U . Es ist auch das, was andere beliebte Paketmanager für Sprachen standardmäßig tun, wie npm. In den Fällen, in denen ich sehe, dass Leute -U , liegt das an der rekursiven Natur, nicht daran, dass sie nicht die neueste Version der Dinge installieren möchten.

pip-Benutzer haben bereits einige Erwartungen an das Verhalten von pip.

TBH, die Haupterwartung, die ich als Benutzer an pip habe, ist jedoch, dass es bei etwa 50% der Aufrufe etwas Überraschendes und offensichtlich Falsches macht. Und ich bin nicht der einzige -- siehe zB @glyphs Vortrag bei pycon letzte Woche, wo er bemerkte, dass pip großartig ist, außer dass alle Standardeinstellungen kaputt sind und unbreak-me-Flags erfordern. Dies ist keine Kritik an den Pip-Entwicklern, ich verstehe, dass Sie/wir alle unter einer komplexen Reihe von Einschränkungen arbeiten, und es ist kein Argument dafür, dass wir Dinge einfach so kaputt machen sollten, um sie zu brechen -- pip hat viele Stücke und viele davon sind in Ordnung! Aber angesichts des Gesamtzustands der Standardeinstellungen von Pop bin ich _wirklich_ nicht überzeugt von Argumenten der Form "pip hat immer X gemacht, daher sollte pip immer X tun". Wenn Sie argumentieren möchten, dass pip install das Upgrade verweigert, dann ist das cool, aber ich würde dieses Argument lieber auf die tatsächlichen Vorzüge und nicht nur auf die Trägheit verweisen.

Ja, ich stimme @njsmith und @glyph hier

Diese spezielle Änderung gehört vielleicht nicht dazu, aber ich denke, sie ist es.

Ja, ich versuche definitiv, dies von "Welche Operationen möchte ein Benutzer ausführen" im Vergleich zu "Welche Operationen sollte der X-Befehl ausführen" anzugehen. Ich nehme dann diese hochrangige Operation, von der ich denke, dass die Benutzer sie ausführen möchten, und versuche, sie einem einzelnen benannten Befehl zuzuordnen (so explizit es auch sein mag, pip install-the-latest-version ist nicht sehr benutzerfreundlich). .

OK. Angenommen, ich bin bereit, mich (etwas) davon überzeugt zu zählen. Wenn wir jedoch davon ausgehen, dass dies richtig ist, was ist mit Abhängigkeiten? Ich bin zu 100% überzeugt, dass "versuchen Sie, Numpy aus dem Quellcode zu installieren" fast immer nicht das ist, was gewollt ist. Wir installieren also nur numpy von Rädern, es sei denn, der Benutzer erwähnt numpy explizit. Nehmen Sie das vorerst als gegeben an und nehmen Sie dann an, wir haben die Situation, die ich zuvor beschrieben habe.

• Der Benutzer hat foo 1.0 und numpy 1.10 installiert, foo 1.0 hängt von numpy ab >= 1.10
• PyPI hat foo 2.0 verfügbar, abhängig von numpy >= 1.11. Es gibt keine stumpfen 1.11er Räder.

Was macht pip install foo ? Vermutlich den Benutzer bei 1.0 belassen, da es sich um eine funktionierende Installation handelt? Aber sollte es erfolgreich sein (da foo installiert ist) oder fehlschlagen (da die neueste Version nicht installiert werden konnte)? Wenn ersteres, wie findet der Benutzer heraus, dass sein System veraltet ist? Wenn letzteres, wie sagt der Benutzer "Ich möchte nur sicherstellen, dass foo da ist"? OK, der Benutzer kann pip list --outdated tun, sehen, dass foo 2.0 existiert und pip install foo tun (Übrigens, das kommt mir immer noch total seltsam vor, ich habe foo, aber ich weiß, dass es eine neue Version gibt, also Ich tue pip install???Egal...) Und ein Erfolg, aber 1.0 bleibt installiert?

Ein Grund, warum ich zwei Befehle bevorzuge, ist, dass die Absicht des Benutzers völlig klar ist, so dass Randfälle wie dieser richtig gehandhabt werden können, weil wir die Erwartungen des Benutzers kennen.

Vielleicht ist das alles offensichtlich, wenn Sie an apt-get gewöhnt sind. Aber ich kann definitiv sagen, dass es jemandem wie mir, der es nicht ist, überhaupt nicht klar ist.

Wenn Sie argumentieren möchten, dass pip install das Upgrade verweigert, dann ist das cool, aber ich würde dieses Argument lieber auf die tatsächlichen Vorzüge und nicht nur auf die Trägheit verweisen.

Meine Argumentation basiert eher auf expliziten als auf impliziten. Ganz sicher _nicht_ bei "das haben wir schon immer so gemacht". Ich habe kein Problem mit der Idee, dass apt-Benutzer möglicherweise daran gewöhnt sind, "zu installieren", was "möglicherweise Upgrade" bedeutet. Ich bin mir wirklich nicht so sicher, ob andere Benutzer es sind.

Ein Gedanke - hat apt ein "Paket bereits vorhanden - Upgrade?" prompt? Ich könnte mir vorstellen, dass install-as-upgrade für mich weniger überraschend wäre, wenn es "install-or-ask-if-I-sould-upgrade" wäre... Natürlich verhält sich pip im Moment interaktiv nicht so, obwohl Natürlich ist es eine Option, dies zu tun.

Das ist eine interessante Frage-- Andere Paketmanager umgehen das meistens, indem sie entweder überhaupt keine Binärpakete haben, also _immer_ nach Quelle, oder indem sie sich so ziemlich nur mit Binärpaketen befassen, also _immer_ binär. Wir befinden uns in einer Art Seltsamkeit dazwischen, was es schwieriger macht.

Angesichts dessen denke ich, dass wir im Moment standardmäßig das Quellpaket numpy 1.11 herunterladen und versuchen sollten, es zu installieren, aber wenn sie --only-binary , dann unseren hypothetischen Resolver (den wir dringend brauchen, SAT oder Backtracking oder was auch immer) würde sehen, dass foo-2.0 keine auflösbare Installation ist und wird dann auf die Installation von foo-1.0 zurückgreifen. Dies ist keine großartige Standardeinstellung, insbesondere für Benutzer unter Windows, bei denen das Kompilieren _viel_ schwieriger ist, aber ich denke, es spiegelt die Realität von heute wider.

Abgesehen davon möchte ich wirklich versuchen, die Dinge in eine Welt zu bringen, in der wir das Verhalten von pip wieder ändern können, sodass wir standardmäßig nur binär sind und eine Opt-in für Quellfreigaben erfordern, aber ich glaube nicht, dass wir noch an einem Ort sind, an dem wir das tun können.

@pfmoore : Ich denke, die Frage zwischen Binär- und pip upgrade Befehl stellen. Obwohl es sich also um echte Probleme handelt, die wir angehen müssen, verschiebt die Aufteilung von Upgrade und Installation die Probleme nur, anstatt sie zu vereinfachen? Außerdem liefern wir im speziellen Fall von numpy jetzt Räder für praktisch alle Plattformen, die wir unterstützen möchten :-).

Aber so würde ich vorschlagen, diese Probleme für pip install foo (insbesondere diesen Befehl – ​​ich spreche nicht von pip install foo==whatever oder pip install ./foo-*.whl oder pip install bar wobei bar hat Requires-Dist: foo ):

1) Fragen Sie den Index ab, um die neueste Kandidatenversion von foo ; nenne das $LATEST . Wenn keine Kandidatenversionen vorhanden sind, wird ein Fehler ausgegeben.

2) Wenn $LATEST bereits installiert ist, dann erfolgreich beenden.

3) Prüfen Sie, ob es eine Distribution von $LATEST gibt, die in der aktuellen Umgebung installiert werden kann. (Beispielgründe, warum dies nicht der Fall sein könnte: Es gibt nur Räder, aber keine sdists, und die Räder stimmen nicht mit der aktuellen Umgebung überein. Es gibt kein passendes Rad und es ist ein sdist vorhanden, aber der Benutzer hat --binary-only :all: Es gibt kein passendes Rad, und es gibt ein sdist, aber das sdist hat ein Flag mit der Aufschrift "Ich arbeite nur an Python 3" und der Benutzer führt Python 2 aus - die Ipython/Jupyter-Leute werden es wahrscheinlich tun schlagen dies bald als neues Feature vor, b/c sie wollen die Unterstützung von Python 2 für neue Releases im Januar einstellen, während sie weiterhin ein Python-2-unterstützendes LTS bereitstellen.)

4) Wenn $LATEST _keine_ brauchbare Distribution hat: Geben Sie eine Warnung aus, um dem Benutzer mitzuteilen, dass eine neuere Version verfügbar ist, aber nicht für seine Umgebung, idealerweise mit einem Hinweis, was er tun muss, wenn dies wirklich der Fall ist die neue Version möchten (zB "ipython 6.0.1 ist verfügbar, erfordert aber Python >= 3.4, und Sie haben Python 2.7 - erwägen Sie ein Upgrade von Python" oder "numpy 1.12 ist verfügbar, aber es gibt keine Binärdatei für ppc64 und Sie haben Bauen aus dem Quellcode deaktiviert – ziehen Sie --allow-source numpy Betracht). Entfernen Sie dann $LATEST aus der Liste der Kandidatenversionen und fahren Sie mit Schritt 1 fort.

5) Wenn $LATEST _hat_ eine brauchbare Distribution hat, versuchen Sie diese Distribution zu installieren.

6) Wenn die Installation fehlschlägt (zB b/c ist es ein sdist und es gibt keinen Compiler), dann Fehler. Andernfalls erfolgreich beenden.

@njsmith binary-only ist etwas orthogonal, stimmte zu, aber IMO, wenn wir versuchen, Befehle zu entwerfen, die "tun, was der Benutzer erwartet", dann ist es

@dstufft das Problem mit "install numpy, es sei denn, der Benutzer sagt --binary-only wurde im Beispiel in meinem vorherigen epischen Beitrag erklärt - (1) sagen wir, dass foo nur in Quellform verfügbar ist und (2) der Benutzer möglicherweise nicht (und sollte es auch nicht müssen) wissen, dass foo von numpy abhängt. Dann kann der Benutzer nicht --only-binary :all: sagen und hat keine Ahnung, dass er --only-binary numpy braucht, bis _nach_ einer (langen) fehlgeschlagenen Kompilierung (möglicherweise noch schlimmer) eine erfolgreiche Kompilierung, die den Benutzer mit einem nicht optimierten numpy zurücklässt (heute kompiliert numpy sofort unter Windows, liefert aber einen nicht optimierten Build).

Ich stimme voll und ganz zu, dass wir langfristig standardmäßig nur Binärdateien verwenden sollten, aber wir sind noch lange nicht in der Nähe davon (zumindest sollte dies bedeuten, dass so ziemlich jedes reine Python-Paket als Rad verfügbar ist).

@pradyunsg Wie Sie sehen, gibt es hier noch viele ungelöste Probleme. Haben Sie noch Interesse, dies voranzutreiben? Ich zögere, eine weitere lange Debatte anzustoßen, wenn sie einfach wieder ins Stocken gerät...

@pradyunsg Wie Sie sehen, gibt es hier noch viele ungelöste Probleme. Haben Sie noch Interesse, dies voranzutreiben? Ich zögere, eine weitere lange Debatte anzustoßen, wenn sie einfach wieder ins Stocken gerät...

Ich habe damit gerechnet. Ich bin daran interessiert, dies voranzubringen. Lass uns das machen! :Lächeln:

Ich schlage vor, eine Liste mit allem zu erstellen, was ein _Benutzer_ von Pip erwartet, und dann Lösungen für jeden von ihnen vorzuschlagen, bis alle (oder eine ausreichende Anzahl) von ihnen durch einen pip-Befehl (mit Optionen/Standardeinstellungen) gelöst sind oder mit behandelt werden können "keine Aktion".

Zu Beginn ist hier eine höchstwahrscheinlich unvollständige Liste:

1. Ein Benutzer möchte ein Paket installieren, das noch nicht installiert ist.
2. Ein Benutzer versucht, ein bereits installiertes Paket zu installieren.
3. Ein Benutzer möchte ein installiertes Paket aktualisieren.
4. Ein Benutzer versucht, ein nicht installiertes Paket zu aktualisieren.
5. Ein Benutzer möchte sicherstellen, dass er die neueste Version eines Pakets installiert hat, unabhängig davon, ob es bereits installiert war oder nicht.
6. Ein Benutzer möchte normalerweise nicht, dass alle Abhängigkeiten aktualisiert werden, sondern nur erfüllt werden.
7. Ein Benutzer möchte ein Paket aktualisieren/installieren, aber nicht aus dem Quellcode erstellen (weder das Paket noch seine Abhängigkeiten). Wahrscheinlich wahrscheinlicher als:
8. Ein Benutzer ist bereit, von der Quelle aus zu aktualisieren/zu installieren.

Meine persönlichen Vorschläge dazu als Nutzer:

1) & 7) pip install foo sollte versuchen, auf die neueste verfügbare Version aufzulösen (unter Berücksichtigung von Abhängigkeiten) und sie zu installieren. Der Algorithmus wäre der von @njsmith .
2) pip install foo → eine Warnung anzeigen, dass foo bereits installiert ist und vorschlagen, pip upgrade foo
3) & 7) pip upgrade foo versucht, die neueste verfügbare Version von foo zu installieren, wieder dem Algorithmus von @njsmith folgend. Wenn eine neuere Version nicht installiert werden kann, weil sie für die Plattform nicht verfügbar ist und kein sdist vorhanden ist oder der Benutzer nicht aus dem Quellcode erstellen möchte, zeigen Sie dies an. In beiden Fällen erfolgreich und nur fehlschlagen, wenn die Installation selbst fehlgeschlagen ist.
4) pip upgrade foo schlägt fehl, wenn das Paket nicht installiert ist.
5) pip install-uprade foo oder pip install foo --ensure-latest oder pip install foo --upgrade (im Grunde das gleiche wie derzeit, außer nicht eifrig).
7) Alle Operationen sollten nicht eifrig sein und ein --eager Flag wäre verfügbar, um die alte Funktionalität von install --upgrade . Wenn noch keine Abhängigkeit installiert ist, installieren Sie die neueste. Wenn es bereits zufrieden ist, tun Sie nichts. Wenn sie nicht erfüllt ist, installieren Sie die neueste noch zufriedenstellende Version (für Anforderungen mit oberer Grenze).
8) pip upgrade foo --allow-source oder pip upgrade foo --allow-source numpy , wenn foo von nicht-binären numpy-Releases abhängt. Bearbeiten: Ich weiß nicht, ob dies anwendbar wäre, siehe Kommentar unten.

Fühlen Sie sich frei, die Liste zu erweitern und Ihre eigenen Vorschläge zu veröffentlichen.

@pfmoore Ich bin mir nicht sicher, was die Alternative ist? Der Zustand der Welt ist heute, dass Wheels an Boden gewinnen, aber sie sind nicht annähernd allgegenwärtig, daher bin ich mir nicht sicher, ob ich wirklich eine gute Option sehe, die derzeit standardmäßig keine Source-Releases zulässt.

@dstufft Mein Vorschlag war, Quellen für explizit benannte Pakete zuzulassen, aber standardmäßig nur Binärdateien für Abhängigkeiten zu verwenden. Auf diese Weise bekommt der Benutzer keine "überraschenden" Build-Schritte. Es ist sicher ein Kompromiss, aber es spiegelt wider, was ich im Moment manuell tun (müssen) muss.

@FichteFoll Mein Hauptanwendungsfall ist vor allem die Funktion "Alle aktualisieren". Suchen Sie nach allem, was derzeit installiert ist, und aktualisieren Sie, wenn neuere Versionen verfügbar sind.

Die Pakete, die ich installiert habe, haben normalerweise nichts anderes als ">=" Abhängigkeiten (und die meisten haben nicht einmal das), also gibt es hier nichts Kompliziertes. Schnapp dir einfach die neueste Version. Meine größte Einschränkung ist, dass es einige Pakete gibt, die ich nicht erstellen kann (numpy, scipy, lxml, pyyaml, matplotlib, pyqt), also möchte ich nur Binärdateien für diese. Ich kann wahrscheinlich einfach --only-binary <these> in mein pip.ini (oder ich hoffe zumindest, dass ich es kann ...)

Sekundär: Installieren Sie das Paket XXX (neueste Version) sowie alle seine Abhängigkeiten, die ich noch nicht habe. Aktualisieren Sie keine Abhängigkeiten, die ich bereits habe, wenn sie die Einschränkungen des neuen Pakets erfüllen. Ich weiß immer, dass ich derzeit kein XXX habe.

Tertiär: Aktualisieren Sie ein einzelnes Paket XXX, das ich (weiß, dass ich) installiert habe. Ändern Sie keine anderen Pakete, es sei denn, dies ist erforderlich, um Abhängigkeitsbeschränkungen aufrechtzuerhalten (und selbst das ist theoretisch - ich habe die Situation im wirklichen Leben noch nie erlebt, daher weiß ich nicht, was die beste Lösung für mich wäre). Meine Absicht ist immer "Upgrade auf die neueste Version". Ich habe noch nie eine Situation erlebt, in der dies Abhängigkeiten von bereits installierten Paketen aufheben würde. Wenn ja, _glaube_ ich hätte gerne eine Warnung, dass ich nicht die neueste Version (und warum) habe, plus ein Upgrade auf die neueste Version, die akzeptabel ist. Meiner Meinung nach bedeutet diese Situation derzeit pip install -U obwohl das Verhalten für Abhängigkeiten nicht das ist, was ich möchte. Der Hauptgrund, warum ich dies tun würde, ist jedoch das derzeitige Fehlen eines geeigneten "upgrade all" (oder um Fälle zu behandeln, in denen ein neuer "upgrade all" -Befehl nicht wie gewünscht funktioniert).

Die ganze Diskussion über Abhängigkeiten und Beschränkungen ist meiner Erfahrung nach fast ausschließlich theoretisch. Ich habe derzeit 160 Pakete in meinem System Python installiert (eine Mischung aus wissenschaftlichen, Datenanalyse-, Web- und allgemeinen Programmiermodulen). 100 von ihnen haben keine Anforderungen. Für den Rest gibt es nichts Komplexeres als eine Liste von Paketen - keine Versionseinschränkungen oder etwas Komplexeres als Requires: six, dask, pillow, networkx . Die längste Liste von Abhängigkeiten hatte 9 Elemente.

@pfmoore Wird das nicht viele Dinge kaputt machen? Eine kurze Liste von Dingen, die mir spontan einfallen und von denen ich weiß, dass sie sehr beliebte Pakete sind, hängt davon ab:

• SQLAlchemy (erfordert optional einen Compiler, verwendet ansonsten reines Python).
• PyYAML (erfordert optional einen Compiler, verwendet ansonsten reines Python).
• Markupsafe (erfordert optional einen Compiler, verwendet ansonsten reines Python).
• PyCrypto (erfordert immer einen Compiler)
• pycparser (erfordert nie einen Compiler)
• httplib2 (erfordert nie einen Compiler)
• anyjson (erfordert nie einen Compiler)
• zope.interface (erfordert optional einen Compiler, verwendet ansonsten Pure Python).
• docopt (erfordert nie einen Compiler)
• Mako (erfordert nie einen Compiler)
• es ist gefährlich (erfordert nie einen Compiler)
• amqp (erfordert nie einen Compiler)
• orderdict (erfordert nie einen Compiler)

und so weiter, eine lange Liste der beliebtesten Pakete und ob sie Räder haben oder nicht, können Sie unter http://pythonwheels.com/ einsehen.

@pfmoore

Suchen Sie nach allem, was derzeit installiert ist, und aktualisieren Sie, wenn neuere Versionen verfügbar sind.

Ich habe diesen Befehl vor einiger Zeit aus einer SO-Frage bezogen, die ich derzeit dafür verwende. Es ist suboptimal, funktioniert aber für die meisten meiner Pakete, außer einem. (Es verwendet den py Launcher, da ich unter Windows arbeite.)

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

Das einzige Problem, das ich damit habe, ist das Paket Flake8, das diese Anforderungen hat:

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)

Insbesondere pyflakes ist ein Problem, da eine neuere Version verfügbar ist und mit dem obigen Befehl aktualisiert wird, was dazu führt, dass Flake8 nichts tut (da es die Version überprüft).
Dies ist also in der Tat etwas, das berücksichtigt werden muss, und ich möchte auch eine ordnungsgemäße Upgrade-Funktionalität haben (ohne die Anforderungen zu beeinträchtigen!).

@dstufft warum? Wenn foo von pyyaml ​​abhängt und ich darum bitte, foo zu aktualisieren, wird pyyaml ​​nicht aktualisiert (keine neuen Binärdateien), aber foo kann trotzdem aktualisiert werden, da immer noch das ursprüngliche pyyaml ​​vorhanden ist.

Für neue Abhängigkeiten (oder bei einer Installation, bei der eine Abhängigkeit nicht immer vorhanden ist) müssen Sie installieren. Wenn also keine Binärdatei vorhanden ist, nehmen Sie die Quelle. Ich persönlich würde in Betracht ziehen, "ältere Version mit Binärdatei vor neuerer Version mit Quellcode zu wählen", aber das kommt der Standardeinstellung von --binary-only gefährlich nahe, wofür ich nicht bereit bin.

Hmm, vielleicht liegt mein Problem tatsächlich an der Option --only-binary , die zu grob ist. Wenn wir eine Option --prefer-binary , die besagte "Nur Binärdateien verwenden, es sei denn, dies bedeutet, dass es keine Kandidaten gibt, in diesem Fall versuchen Sie es erneut, die Quelle zuzulassen", vermute ich, dass viele meiner Bedenken zu einem Bruch führen würden gelindert werden könnte. Was, wie @njsmith vorgeschlagen hat, bedeutet, dass die Binär- / --only-binary verfügbar"...).

Insbesondere Pyflakes ist ein Problem

OK, das ist keine Situation, die ich habe (wie gesagt, ich habe nichts mit so komplexen Abhängigkeiten installiert). Ich habe kein Problem damit, "Alle aktualisieren" zu verfeinern, um Dinge auf "die neueste Version, die nicht zu Brüchen führt", zu aktualisieren, aber AIUI, die den "SAT-Löser" -Ansatz benötigt, um die richtige Lösung zu finden. Dies ist jedoch ein Implementierungsproblem - das Design sollte in der Tat immer korrekte Ergebnisse liefern.

@pfmoore Ich denke, eine --prefer-binary Flagge könnte eine gute Option sein, unabhängig vom Ergebnis dieses Tickets. Wird wahrscheinlich mit einer Warnung gebündelt, wenn dadurch nicht die neueste Version installiert wird, die sonst installiert worden wäre.

@FicheFoll : Ich denke nicht, dass der Versuch, die gesamte Benutzeroberfläche aus den ersten Prinzipien neu abzuleiten, sehr produktiv sein wird. Es gibt einen relativ klar definierten Teil des Problems, der für dieses spezielle Thema aktuell ist, und wenn wir versuchen, den Umfang auf alles gleichzeitig auszuweiten, wird es einfach wieder stecken bleiben.

Bei diesem Thema sieht es so aus, als ob der Hauptunterschied zwischen uns ist: Angenommen, ein Benutzer hat das mentale Modell, dass pip install foo nur für den Übergang von deinstalliert zu installiert ist, und dass er versteht, dass foo ist bereits installiert. Ich behaupte, dass ein Benutzer mit diesem mentalen Modell _niemals pip install foo _ eingeben wird. Wenn also ein Benutzer pip install foo eingibt, während foo bereits installiert ist, können wir daraus schließen, dass sein mentales Modell nicht Ihrem (2) entspricht. _Entweder_ der erste Teil ist falsch: Sie wissen, dass foo installiert ist und erwarten, dass pip wie einige andere beliebte Paketmanager aktualisiert wird, _oder_, der zweite Teil ist falsch: Sie wissen nicht, dass foo installiert ist , in diesem Fall erwarten sie, dass install ihnen die neueste Version hinterlässt (weil install das macht, wenn Pakete nicht installiert sind und sie denken, dass dieses Paket nicht installiert ist).

Um es festzuhalten, einer der Gründe, warum ich es nicht mag, dass pip install ... immer von deinstalliert zu installiert wechselt und pip upgrade ... immer nur von installiert zu einer neueren Installation wechselt, ist, dass ich den Benutzer finde Erfahrung ziemlich mies. Software, die weiß, was sie tun soll, aber anstatt das zu tun, sagt sie, dass sie einen anderen Befehl aufrufen soll, ist unglaublich frustrierend.

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

Würde nichts für mich tun, außer mich zu ärgern, obwohl es technisch "richtig" ist.

Die Kehrseite davon ist, wenn Sie sagen "ok, wenn pip install foobar bereits foobar installiert hat, dann tun wir so, als ob es nicht installiert wäre, und wenn Sie pip upgrade foobar tun, dann wir verhalten, als wäre es bereits installiert, am Ende haben wir zwei Befehle, die im Grunde das gleiche tun, außer mit _vielleicht_ kleinen Unterschieden in der genauen Verarbeitung der Dinge, was mir sagt, dass sie wie ein einzelner Befehl mit einigen --options , um mit den Randfällen umzugehen. Ich denke, das ist besser, weil es bedeutet, dass Benutzer nicht im Voraus entscheiden müssen, welche sie möchten, es gibt einen Befehl zum Installieren von Sachen und für die meisten Benutzer wird dies der Fall sein tun im Allgemeinen das Richtige.Wenn ein Benutzer in einem bestimmten Szenario einige Entscheidungen von seiner Seite erfordert, muss er die Kosten für die Auswahl der zu verwendenden --flags bezahlen.

OK. Betrachten Sie mich als überzeugt. Ich habe einige Nachforschungen angestellt und sogar die Windows-Installer, mit denen ich (angeblich :-)) vertraut bin, führen die Installation als Upgrade durch (wenn Sie etwas wie VirtualBox installieren, heißt es "Sie haben bereits eine frühere Version installiert, oder?) ein Upgrade durchführen möchten?") Powershell hat ein Installationspaket, das nichts Spezifisches sagt, aber es gibt kein Upgrade-Paket. usw. Ich denke also, dass es die Norm ist, nur den einzigen Befehl "installieren" zu haben.

Was natürlich bedeutet, dass diese PR, sofern nicht jemand anders argumentieren möchte, technisch einfach als "nicht umsetzbar" abgeschlossen werden kann. Aber es ist immer noch so gut wie jeder andere, um zu diskutieren, _wie_ wir den install-Befehl umgestalten wollen, denke ich.

OTOH, vielleicht schließen wir dies als abgelehnt, und jemand öffnet ein neues Problem mit einem konkreten Vorschlag, wie der Installationsbefehl geändert werden sollte. Es könnte zumindest einen klareren Ausgangspunkt für Diskussionen bieten.

Eine Frage. Glaubt irgendjemand, dass wir schon an einem Punkt sind, an dem jemand aus all den Vorschlägen hier und anderswo einen vollständigen Verhaltensvorschlag zusammenstellen könnte? Wie werden Abhängigkeiten gehandhabt, was passiert mit Einschränkungen (und wenn sie kollidieren), Binärdatei vs. Quelle, wie wir das Szenario "Alle aktualisieren" unterstützen usw.? Mein persönliches Gefühl ist, dass wir jemanden brauchen, der diese Entscheidung trifft, der Diskussion einen Bezugspunkt gibt, oder wir könnten einfach ewig über Details diskutieren. Ich könnte das wahrscheinlich tun, aber es ist unwahrscheinlich, dass ich in der Lage bin, das umzusetzen, was ich vorschlage (z. B. würde ich einen Ansatz der "optimalen Abhängigkeitsauflösung" vorschlagen, der eine SAT-Löser-AIUI impliziert). Es wäre also besser, wenn jemand, der bereit wäre, seinen Vorschlag umzusetzen, aktiv wird (und sich mit der unvermeidlichen Debatte und dem Fahrradabwurf auseinandersetzt :-)).

Ich bin immer noch besorgt über einige der Auswirkungen der hier gemachten Punkte, aber ich bin mir nicht sicher, ob ich die Energie habe, sie zu diskutieren, bis eine reale Möglichkeit einer Umsetzung besteht.

Ich stimme den neuesten https://github.com/pypa/pip/issues/59#issuecomment -224341218 von @dstufft voll und ganz zu
Deshalb plädiere ich (noch einmal) für die einfache Lösung der Optionen --eager / --non-eager .

Ich stimme auch dem Kommentar von @dstufft zu, wie bereits erwähnt (wir verwenden einen einzigen install Befehl und keinen update Befehl).

Ich bin mir jedoch nicht sicher, was --eager / --non-eager beinhaltet. Ich denke, --non-eager bedeutet, nichts zu aktualisieren, was nicht aktualisiert werden muss (entweder weil der Benutzer es explizit angegeben hat oder weil es zu alt ist, um die neuen Abhängigkeiten zu erfüllen). Bedeutet --eager dann ein Upgrade jeder Abhängigkeit auf die neueste mögliche Version, ob notwendig oder nicht? Welches wäre die Standardeinstellung? (Ich würde für --non-eager argumentieren)

Und eine Frage - würde dies wissenschaftliche Pakete ermutigen, ihre Abhängigkeiten korrekt zu deklarieren? Das muss eine wichtige Überlegung sein.

Fahrradschuppen Punkt. Die Optionsnamen --eager und --non-eager sind ziemlich uninteressant. Ich denke, wir brauchen bessere Bedingungen. Vielleicht etwas explizites wie --upgrade-dependencies .

Dieser PR schlägt auch einen upgrade-all Befehl vor, der für mich der Hauptanwendungsfall ist. Wollen Sie damit sagen, dass wir diesen Befehl ablehnen oder Sie einfach keine Meinung dazu haben?

Mein Verständnis von --eager und -non-eager stimmt mit dem überein, was --non-eager sein sollte der Standard. Ich stimme auch zu, dass der Name irgendwie mies ist, obwohl ich keine bessere Lösung habe, die kein Bissen ist. Vielleicht --[no-]recursive oder so, ich weiß es nicht.

Ich denke, so etwas wie ein upgrade-all Befehl könnte eine gute Ergänzung sein (solange er sicherstellt, dass die Versionsspezifizierer von nichts verletzt werden). Ich würde dies jedoch wahrscheinlich nur upgrade und einfach keine Argumente brauchen, um die Funktionsweise einzuschränken.

tl;dr
Diskussion für ein upgrade-all-packages - bleibt hier.
Diskussion für Preferred-Binär - Über zu #3785
Diskussion für Install-as-Upgrade - Über zu #3786

Wenn wir eine --prefer-binary-Option hätten, die besagte "nur Binärdateien verwenden, es sei denn, dies bedeutet, dass es keine Kandidaten gibt. In diesem Fall versuchen Sie es erneut, die Quelle zuzulassen"

Das ist eine gute Idee. Obwohl es mit diesem Thema zu tun hat, denke ich, dass es ein eigenes Thema verdient. ( Der Kommentar von

Mein Verständnis dessen, was --eager und -non-eager bedeutet, stimmt mit dem überein, was

Ein eifriges Upgrade würde die neuesten zulässigen Versionen aller (Unter-) Abhängigkeiten installieren Ein nicht eifriges Upgrade würde eine (Unter-) Abhängigkeit nur

Die Optionsnamen --eager und --non-eager sind ziemlich uninteressant.

Ich stimme zu. Ich mag die Idee, das Verhalten hinter einer einzigen Flagge zu platzieren.
--upgrade-strategy=eager/non-eager

Es ist auch ein Bissen, aber es vermittelt die Absicht deutlicher. Ist es zu ausführlich? Könnte sein.

Ich denke, der Fahrradabwurf wird am besten nach der Finalisierung der Semantik durchgeführt.

Glaubt irgendjemand, dass wir schon an einem Punkt sind, an dem jemand aus all den Vorschlägen hier und anderswo einen vollständigen Verhaltensvorschlag zusammenstellen könnte?

Ich glaube schon. Wir müssen zumindest einige grundlegende Tatsachen feststellen, über die wir uns einig sind. Ich bin dabei.

OTOH, vielleicht schließen wir dies als abgelehnt, und jemand öffnet ein neues Problem mit einem konkreten Vorschlag, wie der Installationsbefehl geändert werden sollte. Es könnte zumindest einen klareren Ausgangspunkt für Diskussionen bieten.

Ich denke, wir sollten dieses Thema vorerst offen lassen, da es ein upgrade-all vorschlägt. Sie haben bereits bemerkt, dass kein Upgrade stattfindet. Ich habe #3786 für weitere Diskussionen über den Befehl install-as-upgrade geöffnet.

Ich bin immer noch besorgt über einige der Auswirkungen der hier gemachten Punkte, aber ich bin mir nicht sicher, ob ich die Energie habe, sie zu diskutieren, bis eine reale Möglichkeit einer Umsetzung besteht.

Ich bin bereit, dies bis zur Umsetzung voranzutreiben. Ich möchte auf keinen Fall die Bemühungen aller anderen verschwenden, einen Konsens darüber zu erzielen.

Ich denke, alle sind sich einig, dass ein 'Upgrade the World'-Befehl wirklich schön wäre, aber IIUC ist blockiert, während wir darauf warten, dass die Resolver-Arbeit landet. In der Zwischenzeit habe ich in der neuen speziellen Ausgabe von @pradyunsg für diese Diskussion einen konkreteren Vorschlag für Einzelpaket-Upgrades gepostet .

Ich denke, alle sind sich einig, dass ein 'Upgrade the World'-Befehl wirklich schön wäre, aber IIUC ist blockiert, während wir darauf warten, dass die Resolver-Arbeit landet.

Tatsächlich wird dieses Problem jetzt von # 988 ordnungsgemäß blockiert. Nennung der Heftnummer zur Querverlinkung der beiden Hefte.

Ich habe es fast vergessen...

Ich bin mir nicht sicher, was Sie mit dem "Halten" von Updates meinen. Bitte klären Sie.

Jetzt, da dieses Problem ausschließlich für Upgrades gilt, sollte ich das klären.

Es kann Situationen geben, in denen es nützlich sein kann, ein Upgrade eines bestimmten Pakets zu verhindern, wenn wir upgrade-all ausführen. Das Besondere, das ich im Hinterkopf habe, ist ... Wenn pkg installiert ist und ich mich nicht darum kümmern möchte, eine potenziell neuere Version neu zu konfigurieren, möchte ich also verhindern, dass pip dieses bestimmte Paket aktualisiert, wenn ich "Upgrade the" ausführe Welt'. Im Wesentlichen halte ich das Upgrade von pkg zurück.

Ein Flag, das eine durch Kommas getrennte Liste von Paketen benötigt, um ein Upgrade zu verhindern, wäre in Ordnung.

Dies hinzuzufügen, sobald ein SAT-Löser auf den Markt kommt, sollte einfach sein. Es sind nur ein paar zusätzliche Klauseln IIUC. (Ja, ich bin auch dabei, SAT-Solver aufzufrischen)

Ich weiß nicht, ob das so üblich ist oder jemand will. Aber ich glaube nicht, dass das in meinem Kopf entstanden ist. Irgendjemand muss es irgendwo in irgendeinem Thread erwähnt haben.

Ah ich sehe. Das macht Sinn und scheint eine vernünftige Sache zu sein.

Kurze Anfrage: Könnte jemand bitte der Beschreibung einen kleinen Hinweis hinzufügen, dass der Upgrade-Befehl nicht ausgeführt wird? Vielleicht, wenn Sie möchten, schreiben Sie auch eine kleine Zusammenfassung, warum das so ist.

_{_geht schlafen_}

Zwei nette Funktionen, die apt hat (und ich denke, andere ausgereifte Systempaketmanager wie dnf haben ähnliche Funktionen):

• Das Markieren eines Pakets als "gehalten" ist ein dauerhaftes Flag, das an das Paket angehängt ist und bewirkt, dass es von upgrade-the-world-Befehlen übersprungen wird. Wird oft auf Pakete gesetzt, die Sie lokal downgraden oder patchen mussten.
• Nachverfolgen, welche Pakete explizit vom Benutzer angefordert wurden und welche Pakete nur implizit installiert wurden, um Abhängigkeitsbeschränkungen zu erfüllen. Letztere können durch ein Upgrade der Welt entfernt werden, wenn sie nicht mehr abhängig sind.

Beides kann als Sonderfall von neueren Projektumgebungs-Paketmanagern wie npm und cargo angesehen werden, wo sie zwischen einer Art menschenorientierter "Anforderungsdatei" und einer vollständig spezifizierten "Sperrdatei" unterscheiden. Ein explizit gehaltenes Paket ist wie ein Paket mit einer vom Menschen angegebenen Versionseinschränkung, und ein explizit installiertes Paket ist eines, das in der vom Menschen bearbeitbaren Datei aufgeführt ist.

Dito. Wenn wir 'upgrade the world' hinzufügen, müssen wir die Möglichkeit hinzufügen, Pakete zu markieren (als held / user-installed und möglicherweise mehr), um Informationen hinzuzufügen, um eine bessere Vorgehensweise zu bestimmen die Upgrades. Ich sehe das als Voraussetzung, nicht als Nice-to-have.

Ich mag die Technik von Cargo und gefällt mir eigentlich. Die Verwendung von Dateien und nicht irgendeiner Form von Metadaten-versteckt-hinter-einem-Cli-Befehl macht es viel einfacher zu verstehen, zu verwalten und auch möglich, eine reproduzierbare Umgebung zu schaffen.

Ich würde mich wirklich freuen, wenn ich irgendeine Form von pyproject.lock sehe ...

200. Kommentar. Beeindruckend. :smiley:

Hinzufügen eines Verweises auf #654 zum "Markieren" von Paketen, von denen wir gesprochen haben.

Können Sie erklären, was Fracht macht? Wo würden Sie sehen, dass die Datei pyproject.lock auf dem Computer des Benutzers gespeichert ist?

Die Sperrdatei von Rusts Cargo wird im Projekt-Root gespeichert, um die Version der derzeit installierten Abhängigkeiten aufzuzeichnen. Wenn Sie diese Datei an git übergeben, können Sie einen konsistenten Satz von Abhängigkeitsversionen mit anderen Entwicklern und CI teilen. Der Composer von PHP hat eine ähnliche Sperrdatei, Composer.lock.

Ich ging immer davon aus, dass pips 'pip Freeze' und 'pip install -r' ähnliches bewirken sollten, und es war nur bedauerlich, dass das Sperrdateiformat von Menschen leicht lesbar/beschreibbar war und die Leute es direkt bearbeiten. War Requirements.txt nicht ursprünglich als Lockfile gedacht?

@triplepoint Danke für die Erklärung. Das klingt in der Tat eher nach einer Anforderungsdatei. Anforderungsdateien sind jedoch optional, versionsbasiert und pro Projekt. Die Markierung (wie ich sie verstehe) sollte pro Umgebung (virtualenv oder Systeminstallation) erfolgen und sollte einfach sagen "Paket X nicht automatisch aktualisieren" (aber manuelles Upgrade zulassen, wenn der Benutzer explizit ein Upgrade dieses Pakets namentlich anfordert).

Um die Diskussionen über upgrade-all und "Upgrade-Verhalten" zu entwirren, hier Kommentare von @rbtcollins und @ncoghlan in der Diskussion zu der Liste zu letzterem, dass für eine erste Implementierung von upgrade-all kein SAT-Löser erforderlich ist.

Robert:

Mir ist klar, dass der Konsens über das Ticket darin besteht, dass es blockiert ist, aber ich tue es nicht
eigentlich zustimmen.

Ja, Sie können es nicht _richtig_ ohne einen vollständigen Resolver machen, aber Sie können es tun
eine Näherung, die viel besser wäre als nichts (nur eng
die für alle Anforderungen angegebenen Spezifizierer). Das ist eigentlich
sinnvoll, wenn es sich um einen vermutlich guten Satz von Versionen handelt
(die Installation behandelt nicht).

Nick:

"yum upgrade" hat jahrelang ohne einen richtigen SAT-Solver gut funktioniert, und der Paketsatz in einer typischen Linux-Installation ist viel größer als in einer typischen virtuellen Umgebung (obwohl die Distribution die Wahrscheinlichkeit von widersprüchlichen Anforderungen beim ersten Auftreten verringert) Ort).

Das erneute Ausführen von pip-compile und dann das Ausführen einer pip-sync ist bereits ein funktionales Äquivalent zu einem Upgrade-All-Vorgang (wie auch das Zerstören und Wiederherstellen eines venv), daher stimme ich zu, dass es nicht erforderlich ist, die Frage der Unterstützung von Bulk-Upgrades zu koppeln baseline pip mit der Änderung des Verhaltens beim Aktualisieren benannter Komponenten.

IMO, pip upgrade-all ist bei weitem der wichtigste Vorschlag auf dem Tisch aus all den verschiedenen Diskussionen über die "Upgrade-Funktionalität". "Alle aktualisieren" wäre eine offensichtliche Möglichkeit, Ihr System auf dem neuesten Stand zu halten, wodurch Fragen zu nicht eifrigen Updates weniger dringend sind und die Dinge auf älteren Ebenen viel weniger dringend sind, sowie eine derzeit bestehende Lücke schließen.

Ein vollständiger Löser wäre zwar schön, aber ich sehe keinen Grund, warum der Ausgangspunkt für pip upgrade-all nicht sein sollte, dass er das tut, was pip install -U <list every package that's installed here> tut. Das erwarte ich als Benutzer, und in den meisten Fällen tut es genau das, was benötigt wird. Die komplexen Eckfälle um widersprüchliche Anforderungen können in erster Linie unter Bezugnahme auf das Obige behandelt werden. Wenn dies nicht ausreicht, können wir entweder das Verhalten von install -U ändern, um es zu beheben, oder den Befehl update-all Sonderfällen umwandeln oder sogar einen vollständigen Solver implementieren.

Werden Sie dies in den nächsten 10 Jahren umsetzen?

FWIW, ich werde es dieses Wochenende noch einmal besuchen.

@magicgoose sagte:
Werden Sie dies in den nächsten 10 Jahren umsetzen?

@pfmoore hat es besser gesagt als ich kann:

Wir sind uns bewusst, dass die Leute das wollen, was fehlt, ist jemand, der bereit ist, einen Fix zu entwickeln, der all die verschiedenen Bedenken und Probleme berücksichtigt, die bereits angesprochen wurden und die bei einer PR-Überprüfung unweigerlich auftauchen werden.

Ich persönlich würde es daher begrüßen, wenn die Leute davon absehen würden, dieses Problem zu pingen, es sei denn, sie verfügen über einen funktionierenden Code, der zumindest einen Ausgangspunkt für die Implementierung bietet - und sie sind bereit, ihn bis zur Implementierung zu verfolgen.

ganz persönliche Meinung

Ich denke durch die Natur von Pip (das ist die Installation von Paketen aus einem Repository, das keine globale QA hat, wie beispielsweise Debian, Redhat oder Ubuntu)
Ich halte es für notwendig und/oder akzeptabel, tatsächlich komplett auf die Implementierung und Aktualisierung aller Funktionen zu verzichten,

da wir jemals einen bekannten Go-Zustand eines installierbaren Satzes von Python-Paketen garantieren

@RonnyPfannschmidt IMO ist es für Benutzer von pip durchaus vernünftig, die Verwendung eines update-all-Befehls explizit zu verbieten, wenn dies ihren Anforderungen / ihrem Workflow entspricht. Aber nicht alle Benutzer von pip haben die gleichen strengen Anforderungen wie diese Leute. Für Benutzer mit entspannteren Bedürfnissen ist ein update-all-Befehl nützlich, und sein Fehlen erschwert es ihnen erheblich, ihre Systeme auf dem neuesten Stand zu halten. Ich denke also, dass es vernünftig ist, dass pip einen solchen Befehl bereitstellt. Es ist unsere Aufgabe, den Menschen die benötigten Tools bereitzustellen, und nicht die Durchsetzung bestimmter Richtlinien zur Verwendung dieser Tools durch die Benutzer.

@pfmoore meine persönliche Erfahrung mit dem Aktualisieren aller Pakete in einer Umgebung ist, dass es sehr regelmäßig bricht ^^

Benutzer, die ein entspanntes Update benötigen, klingen alle so, als ob Sie normale Endbenutzer meinen (die zum Beispiel nur eine normale Linux-Distribution verwenden sollten)

Ob Upgrade-All problematisch ist oder nicht, hängt _viel_ davon ab, wie viele Abhängigkeiten Sie haben und wie diszipliniert sie bei der API-Wartung vorgehen. Es kann auch in Verbindung mit einem kuratierten privaten Repository verwendet werden, um die Kontrolle darüber zu erhalten, welche Upgrades tatsächlich durchgeführt werden, anstatt sorgfältig konfigurieren zu müssen, welche Upgrade-Befehle Sie in jeder virtuellen Umgebung ausführen.

@RonnyPfannschmidt Windows-Benutzer sind immer noch mehr als Linux-Benutzer ~18 zu 1 und sie haben zu diesem Zeitpunkt nichts Vergleichbares mit einer Distributions-Paketverwaltungs-Community (während die Kerntechnologie in den neuesten Versionen vorhanden ist, die Paketierungs- und Kurator-Communitys .) sind nicht). Das bedeutet, dass sie viel mehr auf Tools auf Benutzerebene wie Pip und Conda angewiesen sind, um die Lücke zu schließen.

Wir sind uns bewusst, dass die Leute das wollen, was fehlt, ist jemand, der bereit ist, einen Fix zu entwickeln, der all die verschiedenen Bedenken und Probleme berücksichtigt, die bereits angesprochen wurden und die bei einer PR-Überprüfung unweigerlich auftauchen werden.

@pfmoore ist dir bewusst, dass solche Kommentare die Bemühungen der Mitwirkenden verunglimpfen können? So sieht es bei mir aus. Ich bin mir nicht sicher, ob Sie die ganze Geschichte dieses Problems verfolgt haben, aber in diesem speziellen Fall sind Sie sehr daneben. Das Problem betrifft viel mehr das Pip-Entwicklungsteam als alle Mitwirkenden.

Grobe Zusammenfassung nur eines Teils davon (PR gh-3194):

1. Es gibt eine dokumentierte Entscheidung, dass ein upgrade Befehl willkommen ist (auf der pip-Mailingliste sowie in den Dokumenten und auf GitHub).
2. Dann geht ein Anruf von einem prominenten Entwickler (in diesem Fall @njsmith ) aus, dass die Implementierung dieser Funktion sehr wertvoll wäre.
3. Neuer Mitwirkender taucht auf, setzt alles um, geht schnell auf alle Rezensionskommentare ein. PR bereit zum Zusammenführen.
4. Der Hauptbeitragende ändert seine Meinung darüber, dass er upgrade will.
5. Es folgen sehr lange Diskussionen, ohne Abschluss.
6. Mitwirkender gibt auf und verschwindet (die meisten Leute würden das tun, solche Dinge sind frustrierend).

Und das war noch bevor @pradyunsg auftauchte, der bemerkenswerte Beharrlichkeit zeigt.

In einem gut funktionierenden Projekt würden die Kernentwickler, die sich wirklich um das Thema kümmern, einen schnellen Treffpunkt organisieren und eine Art Entscheidung treffen. Oder delegieren Sie ein oder zwei Personen damit, genug daran zu arbeiten, um zu dieser Schlussfolgerung zu gelangen. Oder sich zumindest entschuldigen und dem PR-Einreicher danken, anstatt ihm vorzuwerfen, dass er "nicht durchgezogen" hat.

Ich weiß, dass Sie die besten Absichten haben, aber seien Sie bei solchen Kommentaren bitte etwas vorsichtiger.

Ich denke, es ist völlig vernünftig, dass sich Anforderungen und Meinungen durch Diskussionen ändern, insbesondere bei einem heiklen Thema wie diesem, auf das es keine richtige Antwort gibt. Ein Teil davon, dass ein Patch in einer Codebasis landet, besteht darin, mit Änderungen Schritt zu halten, die im Rahmen von Überprüfungen und Diskussionen über jede Änderung herausgegeben werden. Einige Änderungen sind ziemlich minimal und haben weniger davon, andere mehr. Es ist nichts falsch daran, wenn eine Person entscheidet, dass sie sich nicht damit befassen möchte und aussteigt (jeder Takt zum Hinzufügen einer Änderung führt zu einer gewissen Abnahme, einschließlich Tests, Dokumentation usw.).

Diese spezielle Änderung ist besonders unangenehm, da sie das Standardverhalten der primären Verwendung von pip ändert. Das ist hart und beängstigend und es wäre ein Bärendienst für unsere Benutzer, wenn wir es überstürzen und die Dinge nicht vollständig durcharbeiten, bevor wir uns in die eine oder andere Richtung festlegen. Dieser Befehl wird 10 bis 100 Millionen Mal im Monat verwendet. Dies ist keine kleine, einfache Änderung, und es werden nicht die Leute sein, die dieses Problem anpingen, die mit der wütenden Gegenreaktion fertig werden müssen, die sich aus einer Änderung ergibt.

Die Person, die die PR zuvor durchgeführt hat, wird ihre Zeit geschätzt, aber es ist eine Tatsache, dass sie nicht bis zum Ende durchgezogen sind. Da die Kernentwickler hier _unsere_ Zeit begrenzt sind, sind wir entweder Freiwillige oder auf viele Projekte verteilt, und wir kommen und gehen von der Teilnahme ab. Es gibt eine Menge verschiedener Probleme, die alle Aufmerksamkeit erfordern, und dies ist nur eines davon. Paul erklärte einfach, dass das Pingen dieses Problems nicht hilfreich ist (was es auch nicht ist) und dass, wenn jemand es möchte, entweder warten muss, bis jemand (einschließlich eines der Kernentwickler) sich dazu entschließt, die beträchtlichen Anstrengungen zu unternehmen, um dies zu tun ändern Sie das Standardverhalten von Millionen oder tun Sie dies selbst.

Wir sind uns bewusst, dass die Leute das wollen, was fehlt, ist jemand, der bereit ist, einen Fix zu entwickeln, der all die verschiedenen Bedenken und Probleme berücksichtigt, die bereits angesprochen wurden und die bei einer PR-Überprüfung unweigerlich auftauchen werden.

@pfmoore ist dir bewusst, dass solche Kommentare die Bemühungen der Mitwirkenden verunglimpfen können? So sieht es bei mir aus. Ich bin mir nicht sicher, ob Sie die ganze Geschichte dieses Problems verfolgt haben, aber in diesem speziellen Fall sind Sie sehr daneben.

@rgommers Ernsthaft? Dieser Kommentar stammt von vor Monaten und wurde hier aus dem Kontext gerissen (aber ehrlich gesagt habe ich kein Problem damit, dass geantwortet hat, zitiert). Ich würde vorschlagen, dass Sie, wenn Sie die gesamte Geschichte durchgesehen hätten, meinen Kommentar im Kontext gesehen hätten, und an dieser Stelle hätten Sie hoffentlich verstanden, was ich sagen wollte.

Wenn ich so "abseits" wäre, hätten Sie das im Mai sagen können, als ich es sagte, anstatt jetzt aus dem Zusammenhang zu hacken.

Wenn ich jemanden beleidigt habe, entschuldige ich mich, das war nicht meine Absicht. Ehrlich gesagt bin ich genauso frustriert wie alle anderen, dass dieses Problem so schwierig ist, ein für alle akzeptables Design zu erreichen. In meinen Kommentaren versuche ich, ein Gleichgewicht zu finden - einerseits schätze ich die Beiträge der Leute wirklich, aber andererseits ist es mir wichtig, den Leuten klar zu machen, dass bei einem Thema wie diesem die Die Codierung ist ehrlich gesagt die geringste Arbeit, die erforderlich ist. Sehr oft wissen die Mitwirkenden diese Tatsache nicht zu schätzen, und hier erhalten wir unvollständige PRs, in denen die Leute frustriert sind über die Arbeit, die erforderlich ist, um die Leute davon zu überzeugen, dass ihr Design in Ordnung ist, und/oder die Änderung zu überarbeiten, möglicherweise auf eine Art und Weise, wie sie es tun. Ich mag es nicht wirklich, die (oft widersprüchlichen und inkonsistenten!) Ansichten anderer Leute zu berücksichtigen. Mir wäre es lieber, wenn sie mit einem Verständnis dafür, worum es geht, in den Prozess eintreten, anstatt mit unrealistischen Erwartungen und infolgedessen einer schlechten Erfahrung.

Alle an den Diskussionen zu diesem Thema Beteiligten haben _viel_ Zeit investiert, um die Vor- und Nachteile verschiedener Ansätze zu diskutieren. Ich kann mir nicht vorstellen, dass es jemanden gibt, der sich darüber freut, wie lange es dauert. Persönlich fällt mir das Fehlen eines upgrade-all Befehls (nur ein Teil der Änderung und wahrscheinlich nicht der, der zuerst implementiert wird) regelmäßig auf. Gelegentlich (ehrlich gesagt, es ist viel mehr als nur "gelegentlich") kommen Leute (normalerweise Leute, die nicht wirklich zu der Diskussion oder dem Code beigetragen haben) die kommentieren: "Das ist wichtig, warum hast du es noch nicht implementiert?" Ehrlich gesagt ist es schwer, ruhig zu bleiben und solche Leute _nicht_ anzugreifen.

In einem gut funktionierenden Projekt die Kernentwickler, die sich wirklich um das Thema kümmern

Ist Ihnen klar, dass dieser Kommentar so interpretiert werden kann, dass er sagt, dass sich die Pip-Entwickler nicht darum kümmern, dies zu beheben (und implizit über Pip)? Wir alle laufen Gefahr, Dinge so zu formulieren, dass sie Menschen beleidigen können. Ich bin sicher, Sie haben dies nicht als Kritik an den Pip-Entwicklern gemeint, gehen Sie bitte davon aus, dass ich auch nicht versuche, jemanden zu beleidigen.

einen schnellen Treffpunkt organisieren und eine Entscheidung treffen würden.

Ich wäre überrascht, wenn so etwas hier funktionieren würde, aber ich bin offen dafür, es auszuprobieren. Ich bin mir nicht sicher, wer sich einmischen würde oder wie wir es schaffen würden, aber sicher, ob es hilft und jemand diesen Ansatz ausprobieren möchte. Ich würde sagen, da diese Änderung ein so großes Potenzial hat, Pip-Benutzer zu betreffen, sollte jede Entscheidung, die auf einem privaten Kanal wie diesem getroffen wird, wahrscheinlich als Vorschlag aufgeschrieben und für allgemeine Kommentare veröffentlicht werden - und ich vermute, dass dies einfach auslösen würde eine weitere Runde der gleichen Debatten, die wir geführt haben.

Oder delegieren Sie ein oder zwei Personen damit, genug daran zu arbeiten, um zu dieser Schlussfolgerung zu gelangen.

Sie sagen also, dass eine so große Entscheidung einseitig von ein paar Leuten getroffen werden sollte? Vielleicht ist das der einzige Weg, eine Lösung zu finden, aber so werden Entscheidungen bei Pip nicht wirklich getroffen (im Gegensatz zu Python haben wir keine BDFL mit Entscheidungsbefugnis der Exekutive). Sie können behaupten, dass uns das kein "gut funktionierendes Projekt" macht, wenn Sie wollen, das ist nicht meine Meinung, aber wir können da anderer Meinung sein, wenn Sie wollen.

Oder entschuldige dich zumindest und bedanke dich beim PR-Einreicher,

Ich bin mir nicht sicher, wofür wir uns entschuldigen sollen, aber wenn es hilft, dann entschuldige ich mich gerne - dafür, dass ihm niemand klargemacht hat, wie schwierig es sein würde, diesen Vorschlag zu Ende zu führen, oder half ihm, die Debatte zu leiten und die Teilnehmer zu einem Konsens zu führen. Aber um fair zu sein, ich glaube nicht, dass irgendjemand _sonstigen_ Beteiligte zu diesem Zeitpunkt wusste, dass dies der Fall sein würde, also denke ich, dass es hier hauptsächlich im Nachhinein gesprochen wird.

Meinen Dank hat er auf jeden Fall. Es ist ziemlich einfach zu sagen "das versteht sich von selbst", aber das sollte es nicht - Open Source-Projekte danken den Mitwirkenden nicht genug, und das ist ein Problem. Wo ich gerade beim Thema bin, möchte ich _allen_ danken, die zu dieser Debatte beigetragen haben - und ich meine das ganz ernst -, da ich aus Erfahrung weiß, wie anstrengend sie sein kann. Aber vor allem an @pradyunsg dafür, dass er das aktuelle Opfer all der endlosen Diskussionen und Richtungswechsel ist. Danke, dass Sie nicht aufgeben! (Noch!!)

anstatt ihm die Schuld zu geben, dass er "nicht durchgezogen" hat.

Nun, ich glaube nicht, dass es eine Schuldzuweisung gibt (obwohl es schwer zu sagen ist, ob er sich beschuldigt fühlte, da er nicht mehr in der Nähe ist). Aber es stimmt, dass seine ursprüngliche PR nicht zu Ende geführt wurde. Das ist aber nur eine Tatsache. Ich hoffe, niemand behauptet, dass Beitragende Anspruch darauf haben, dass ihre PRs akzeptiert werden, nur weil sie sie eingereicht haben. Nicht alle PRs sind beim ersten Einreichen akzeptabel, sie müssen überarbeitet und aktualisiert werden, und manchmal sind sie sogar nach all der Arbeit _noch_ nicht akzeptabel. Entschuldigung, aber so ist das Leben.

[Wenn ich in der obigen Aussage hart erscheine, entschuldige ich mich (nochmals!). Aber einen Großteil meiner Freizeit verbringe ich damit, Beschwerden zu lesen und zu bearbeiten, die ich (oder Projekte, an denen ich beteiligt bin) irgendwie nicht genug getan habe. Und es ist ein Teufelskreis - ich verliere durch das Gezeter die Motivation, in meiner Freizeit an Open Source zu arbeiten, wodurch natürlich noch weniger getan wird. Während ich versuche höflich zu bleiben, ist es manchmal nicht einfach]

Ich habe nicht vor, in dieser Metadiskussion darüber, wie die PR gehandhabt wird, noch etwas zu sagen. Ich habe heute Abend eine Stunde damit verbracht, an dieser Antwort zu arbeiten, um zu vermeiden, dass ich etwas sage, was jemanden beleidigen könnte (und ich wette, ich habe versagt :-(). Und ich hätte diese Zeit viel besser verbringen können - mit meiner Familie, entspannen, oder etwas Produktives tun.

Kann ich also vorschlagen, dass wir wieder versuchen, @pradyunsg zu helfen, eine PR zu entwickeln, mit der wir alle zufrieden sein können, und die fruchtlosen

Kann ich also vorschlagen, dass wir wieder versuchen, @pradyunsg zu helfen, eine PR zu entwickeln, mit der wir alle zufrieden sein können, und die fruchtlosen

Ja bitte. :unschuldig:

Ach, ich habe es vergessen.

@rgommers sagte:
Und das war noch bevor @pradyunsg auftauchte, der bemerkenswerte Beharrlichkeit zeigt.

Ich nehme das als Ergänzung... Danke.

@pfmoore sagte:
besonders an @pradyunsg dafür, dass er das aktuelle Opfer all der endlosen Diskussionen und Richtungswechsel ist. Danke, dass Sie nicht aufgeben!

Gern geschehen.

(Noch!!)

Ich hoffe sehr, dass es nicht in diesen Zustand kommt. Es wird ein wirklich schlimmer Zustand sein, wenn dies der Fall ist, IMO. (Ich bin so arrogant)

Ich habe das Folgende geschrieben, während ich die Geschichte durchgesehen habe, und dachte, ich könnte es genauso gut hier veröffentlichen, um es später nachzuschlagen und mich für alle Fälle von anderen korrigieren zu lassen.

• Beschlossen, daran zu arbeiten, nachdem ich erkannt hatte, wie das große nicht- technisch:technische Verhältnis sein würde (es ist viel größer, als ich _wirklich_ konservativ dachte) und erkannte, dass es bereits einen erfolglosen Versuch gegeben hatte.
• Habe einen Bericht über den Stand der Dinge gemacht, weil mir langweilig war und ich sowieso wissen musste, was passiert ist.
  
  
  
  • Habe wahrscheinlich mehr Zeit (und Platz hier?) dafür aufgewendet als nötig, aber zumindest habe ich für mich (und alle anderen?) einen guten Überblick über das Thema bekommen.
  
  
• War über aufgeregt, nachdem ich es geschrieben hatte. :smiley: Habe es der Welt gezeigt!
• Initiiert eine (lange!!!) Diskussion über die Implementierung eines Upgrade-Befehls.
  
  
  
  • In den Diskussionen kamen einige nützliche Ableger-Ideen auf. Dafür wurden neue Ausgaben erstellt.
  
  
• Die Diskussion führt zu der Idee, das Installationsverhalten in Upstall zu ändern, was standardmäßig nicht eifrige Upgrades durchführt und einen Teil der Funktionalität entfernt, die von der Option --target bereitgestellt wird - 3 Dinge.
  
  
  
  • Hier haben wir einen Fehler gemacht - die 3 (ziemlich) unabhängigen Änderungen zu bündeln und als eine zu implementieren, weil niemand diesen Teil erkannt hat.
  
  
• Ich habe das gleiche implementiert. Da die 3 Änderungen gebündelt waren, blieben sie alle hängen, als es keinen Konsens gab, das Installationsverhalten zu ändern, um die potenziell umstrittene Änderung zu aktualisieren.
• Der Mangel an Konsens löste eine lange Diskussion aus, die zu dem Punkt führte, an dem die Leute sich aus der Diskussion zurückzogen und fast bis zum Burnout getrieben wurden.
  
  
  
  • Einige der früheren Annahmen wurden gebrochen und es wurde beschlossen, zuerst eine minimale Störungsänderung vorzunehmen.
  
  
• Ich hatte keine freie Zeit, um daran zu arbeiten, also habe ich ein paar neue Themen erstellt, damit jemand anderes selbstständig daran arbeiten kann und im Idealfall nicht den gleichen Fehler wie wir hier macht.
• Ins Stocken geraten.
• Ich bin zurück! Ich werde versuchen, den Wechsel zu nicht eifrigen Upgrades standardmäßig bis zum 25. September durchzuführen.

Ja, konzentrieren wir uns einfach darauf, pip install --upgrade zu reparieren und lassen Sie alles andere vorerst weg. Das ist sowieso eine Voraussetzung für jede andere Arbeit.

@pfmoore @dstufft danke für die durchdachten Antworten. Ich wollte niemanden beleidigen, also entschuldige mich, wenn es so rüberkam.

Ich werde nicht auf alles antworten, weil hier niemand eine lange Diskussion sucht.

Du hättest es im Mai sagen können, als ich es sagte,

Ich war damals 2 Monate von Github weg, aber es hat mich gestört, als ich diesen Kommentar zum ersten Mal sah.

Sie sagen also, dass eine so große Entscheidung einseitig von ein paar Leuten getroffen werden sollte?

Alle Optionen auf dem Tisch sind viel besser als der Status Quo. Und nach 5,5 Jahren und vielen Hunderten von Kommentaren, die über mehrere Ausgaben/PRs hier und in der Mailingliste verteilt sind, bin ich nicht zuversichtlich, dass noch mehr Kommentare das Problem lösen werden. Ich hoffe, es wird gelöst, aber wenn das wieder ins Stocken gerät, dann auf jeden Fall ja - nominiere eine oder ein paar Leute und triff einfach eine Wahl.

Ich bin mir nicht sicher, wofür wir uns entschuldigen sollen, aber wenn es hilft, dann entschuldige ich mich gerne - dafür, dass ihm niemand klargemacht hat, wie schwierig es sein würde, diesen Vorschlag zu Ende zu führen, oder half ihm, die Debatte zu leiten und die Teilnehmer zu einem Konsens zu führen.

Letzteres meinte ich. Manchmal ändere ich meine Meinung bei einer Entscheidung für eines meiner Projekte, das passiert. Dann fühle ich mich dafür verantwortlich, die neue Richtung klar zu machen. Und entschuldige mich, wenn ich nicht die Zeit habe, mich mit den Folgen dieser Änderung auseinanderzusetzen (dauert nur 30 Sekunden....).

Aber es stimmt, dass seine ursprüngliche PR nicht zu Ende geführt wurde. Das ist aber nur eine Tatsache.

Das ist eine Ansicht, keine Tatsache. Aus meiner Sicht war die PR komplett - es blieb nur noch entweder auf den grünen Knopf zu drücken oder abzulehnen. Er tat alles, was ich von einem Mitwirkenden erwarten würde.

Nach Ihrer Antwort wurde mir klar, dass sich die Erwartungen der Pip-Entwickler an Mitwirkende und Kernentwickler stark von so ziemlich jedem anderen Projekt unterscheiden, mit dem ich vertraut bin. Ich erwarte von Core-Entwicklern, dass sie neue Mitwirkende anleiten, sie ermutigen, ihnen bei Bedarf Feedback geben und ihnen helfen, strittige Probleme zu lösen (für die die meisten Mitwirkenden weder die Fähigkeiten noch das Interesse haben, und diejenigen, die es tun, werden oft Core-Entwickler), wenn erforderlich. Sie sagen zu neuen Mitwirkenden: _"Sie müssen uns verwalten. Wir können unsere Meinung ändern, nicht übereinstimmen oder das Interesse verlieren - es ist Ihre Aufgabe, das zu verwalten"_. Vielleicht liegt das in der Natur dieses Projekts und es muss so sein, ich weiß es nicht.

Wo ich gerade beim Thema bin, möchte ich mich bei allen bedanken, die zu dieser Debatte beigetragen haben

Einverstanden. Danke an alle, die dazu beigetragen haben.

• und ich meine das ganz ernst - da ich aus Erfahrung weiß, wie anstrengend das sein kann.

Es entwässert. Persönlich bleibe ich hier und bei distutils-sig, weil es wichtig für das Python-Ökosystem und die Benutzer meiner Pakete ist, aber beide Orte geben mir nicht gerade positive Energie.

Nur für den Fall, dass es unter das Radar gerutscht ist - #3972 :smile:

Sie sagen zu neuen Mitwirkenden: "Sie müssen uns verwalten. Wir können unsere Meinung ändern, nicht übereinstimmen oder das Interesse verlieren - es ist Ihre Aufgabe, das zu verwalten". Vielleicht liegt das in der Natur dieses Projekts und es muss so sein, ich weiß es nicht.

Ich sagte, dass ich das nicht fortsetzen würde, aber dieser Punkt war mir klar. So denke ich nicht über unseren Ansatz, aber jetzt, wo Sie es so sagen, sehe ich, dass es so rüberkommen kann. Um ehrlich zu sein, "wir können unsere Meinung ändern, nicht übereinstimmen oder das Interesse verlieren" ist wahr - schließlich sind wir alle auch nur Menschen mit anderen Verpflichtungen - aber ich sehe es nicht als etwas an, was ein neuer Beitragender tun muss "verwalten". Es ist eher eine Realität des Umgangs mit Menschen, aber wenn zu viel daraus gemacht wird, dass das Problem auf neue Mitwirkende abgeladen wird, ist das falsch.

Danke für den Hinweis - ich werde versuchen, es im Hinterkopf zu behalten und diesen Eindruck in Zukunft zu vermeiden.

Ich denke, ein Großteil des Problems läuft darauf hinaus, dass wir stark unterbesetzt sind, was es letztendlich erschwert, Schritt zu halten und alles zu verfolgen. Es gibt mehr potenzielle Mitwirkende als wir, daher ist es leicht, sich überfordert zu fühlen, wenn mehrere Leute gleichzeitig versuchen, Änderungen vorzunehmen. Größere Änderungen oder Änderungen, bei denen es keinen klaren Konsens gibt, sind in der Regel am schwierigsten zu bewältigen, daher sind sie diejenigen, die am meisten darunter leiden :(

Der traurige Stand der Dinge ist, dass, obwohl ich denke, dass wir alle gerne hier wären, um alle Mitwirkenden durch den Prozess zu führen, aber wir einfach nicht die Manpower haben. Dies neigt auch dazu, einen zähen Zyklus zu haben, da wir nicht die Kraft dafür haben, finden wir nicht ohne weiteres neue Leute, die anscheinend wirklich angefangen haben, die Mentalität hinter der Funktionsweise von Pip zu erforschen und die es gelernt haben genug (weil wir nicht da sind, um sie zu unterrichten), um ihnen Rechte an Pip zu geben. Das bedeutet, dass wir ständig unterbesetzt sind und darum kämpfen, uns über Wasser zu halten (zumindest fühle ich mich so. Konstante 70-90-Stunden-Wochen sind wirklich hart für einen Menschen :/).

@pradyunsg Review #3972 steht auf meiner TODO-Liste, habe es nur noch nicht erreicht.

@pradyunsg Review #3972 steht auf meiner TODO-Liste, habe es nur noch nicht erreicht.

Danke!

Das bedeutet, dass wir ständig unterbesetzt sind und darum kämpfen, uns über Wasser zu halten (zumindest fühle ich mich so. Konstante 70-90-Stunden-Wochen sind wirklich hart für einen Menschen :/).

Das ist schwer. Numpy und Scipy waren in dieser Situation, als ich anfing, daran zu arbeiten. Kein Spaß. Ich schätze alles, was Sie tun.

Dieses Thema ist jetzt wirklich lang und wirklich alt, es wurde viel diskutiert, zu viel ist passiert und dieses Thema hat fast ein niedriges Signal / Rauschen erreicht. Es ist schwer zu sehen, was alles passiert ist.

FWIW, der Grund dafür, dass upgrade auf den Karten war, war die Tatsache, dass install --upgrade einen defekten Standardwert hat. Da wir der Behebung dieses Problems jetzt einen Schritt näher gekommen sind, ist es wohl am besten, wenn wir dafür ein neues Problem haben.

Ich schlage vor, dieses Problem aus den oben genannten Gründen zu schließen und neue Probleme für alles zu erstellen, was hier als ungelöst angesehen wird. Ich kann 2 Dinge sehen:

• Verschieben Sie die Standard-Upgrade-Strategie auf only-if-needed .
• Fügen Sie die Funktion "Upgrade the world" hinzu, die von # 988 abhängt.

Am 15.09.16 schrieb Nick Coghlan [email protected] :

@RonnyPfannschmidt Windows-Benutzer sind immer noch
Sie haben nichts Vergleichbares mit einer Community zur Verwaltung von Distributionspaketen
an dieser Stelle zurückgreifen (während die Kerntechnologie in letzter Zeit vorhanden ist)
Versionen, die Verpackungs- und Kurator-Community nicht). Das heißt, sie sind
viel mehr abhängig von Tools auf Benutzerebene wie Pip und Conda, um die
locker.

Ist dann nicht
conda update --all
gut genug?

@Liso77
Nun, nein. Ist es nicht.

Conda und Pip sind Werkzeuge mit unterschiedlichen Zielen. Dies ist eine großartige Lektüre zu diesem Thema. Der dritte Punkt ist am relevantesten.

Wenn die Diskussion um Upgrade-all-Oberflächen erneut (hoffentlich in einer neuen Ausgabe) erfolgt, ist meine Stimme für die Schreibweise wie folgt:

pip install --upgrade :all:

pip install --upgrade :all: ist extrem seltsam. Bleiben wir bei der POSIX-Semantik, die heutzutage praktisch jeder macht: pip install --upgrade --all

Wie wäre es mit nur pip install --upgrade ohne Paketnamen oder -spezifizierer? Zu leicht versehentlich zu laufen?

pip-tools macht das für pip-compile -P .

Vielleicht sollten wir einen Fahrradschuppen machen, sobald wir eine Art Arbeit haben
Implementierung... :)

Am Sonntag, 12. Februar 2017, 20:55 Uhr schrieb FichteFoll [email protected] :

Was ist mit nur pip install --upgrade ohne Paketnamen oder
Bezeichner? Zu leicht versehentlich zu laufen?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pypa/pip/issues/59#issuecomment-279225595 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ADH7SfnSBflH8rK3nFLw1hvYBaovjbcGks5rbyRUgaJpZM4AJ4Py
.

Wie wäre es mit einer Version von pip list --outdated , die ihre Liste in einem Format erstellt, das direkt (dh ohne sed , cut usw.) von pip install --upgrade (zB pip list --outdated --format install | xargs pip install --upgrade oder etwas Ähnliches mit Backticks)?

Welche Syntax auch immer verwendet wird, das Wichtigste ist, diesen Befehl einzuführen. Es ist unglaublich, dass das noch fehlt

In der Zwischenzeit empfehle ich Ihnen, es zu versuchen
https://github.com/jgonggrijp/pip-review
mit pip-review --local --interactive fragst du Paket für Paket ob du updaten willst, nicht sehr gut aber besser als nichts

@SMH17 Es ist völlig glaubhaft, dass es immer noch fehlt, da es genau keine kommerziellen Python-Anbieter gibt, die offiziell finanzierte Entwicklungszeit bereitstellen, um im Namen ihrer Kunden an Verbesserungen der Benutzerfreundlichkeit von Python-

Also , wenn Sie die Situation verbessern , um sehen möchten, ist es wahrscheinlich , dass das nützlichste , was Sie persönlich tun können , ist entweder Ihre Unterstützung Anbieter Python zu ermutigen Entwickler Zeit zu investieren , um die Werkzeuge zu verbessern Sie verwenden, oder wenn Sie nicht über ein Support-Anbieter noch, ermutigen Sie Ihren Arbeitgeber, einen zu zahlen.

Als zusätzlichen Kontext bezüglich der mangelnden Dringlichkeit dieses Themas sei daran erinnert, dass die allgemeinen Empfehlungen lauten:

• Behalten Sie Ihre Arbeitsumgebungsdefinitionen unter der Quellcodeverwaltung, um die Reproduzierbarkeit auf anderen Systemen zu verbessern (mit etwas wie https://github.com/jazzband/pip-tools oder https://github.com/kennethreitz/pipenv, um diese Definitionen auf dem neuesten Stand zu halten )
• streben ein routinemäßiges Upgrade auf neue Releases von Abhängigkeiten an, um das Risikofenster für unbekannte oder nicht offengelegte Sicherheitslücken zu minimieren

Das bedeutet nicht, dass die hier vorgeschlagenen Befehle nicht nützlich sind, sie sind nur deutlich weniger wertvoll, wenn die aktuelle Arbeitsumgebung bereits durch pip-compile + pip-sync oder pipenv lock gewartet wird pipenv install .

Es wäre wertvoll, die ursprüngliche Beschreibung zu aktualisieren, da ich denke, dass seit der Aktualisierung von @qwcode einige Änderungen an pip install vorgenommen wurden.

Hallo allerseits.

Ich habe einige meiner Python-Paketabhängigkeiten aufgrund des folgenden Befehls gebrochen:

pip install --upgrade packageName hat Pakete rekursiv aktualisiert.

Warum nicht das Standardverhalten der Option --upgrade ändern, dh NUR das angegebene Paket von der Befehlszeile aus deinstallieren und neu installieren?

Wie wäre es damit ?

@sebma Ich denke, dass das Standardverhalten nicht geändert werden sollte. Vielleicht könnten Sie das nächste Mal versuchen, das Flag -no-dependencies verwenden. Es sollte funktionieren :+1:

@sebma , @aaossa , ich werde euch beide wissen lassen, dass bereits so ziemlich entschieden wurde, dass sich die Standard-Upgrade-Strategie in Zukunft ändern wird (ref: https://github.com/pypa/pip/issues/3871# Ausgabekommentar-247789343). Die notwendige Funktion (dh das Argument --upgrade-strategy ) wurde in https://github.com/pypa/pip/pull/3972 hinzugefügt

Wie @pradyunsg bereits erwähnt hat , ist dieses Problem eine Art Überbleibsel . Der erste Teil ist inzwischen irgendwie erledigt (siehe meinen ersten Absatz) und der zweite Teil ist anscheinend der einzige Grund, warum dieses Paket noch offen ist. Ich weiß nicht, ob seitdem ein separates "Upgrade-All" -Problem erstellt wurde.

Ich habe einen netten interaktiven Upgrader für die Anforderungsdatei veröffentlicht: https://github.com/simion/pip-upgrader

Verschieben Sie die Standard-Upgrade-Strategie auf Nur bei Bedarf.

4500 haben dies getan.

Fügen Sie die Funktion "Upgrade the world" hinzu, die von # 988 abhängt.

4551 zur Diskussion darüber.

Auf die Punkte des aktuellen Top-Posts eingehen:

pip upgrade wäre wie pip install --upgrade, außer dass es standardmäßig nicht rekursiv ist (und eine Option --recursive anbietet). Sein aktuelles rekursives Standardverhalten hat vielen Kummer bereitet (#304). Wie Sie jetzt nicht-rekursive Upgrades durchführen, finden Sie hier.

Es wurde entschieden, keinen Upgrade-Befehl hinzuzufügen oder pip install upgrade bereits installierte Pakete zu erstellen. pip hat jetzt standardmäßig nicht-rekursive Upgrades, wobei das rekursive Verhalten hinter --upgrade-strategy eager verfügbar ist.

pip upgrade-all würde alle installierten Pakete aktualisieren.

4551 existiert und es wäre schön, eine neue Diskussion darüber zu führen; wenn #988 fertig ist.

@dstufft @xavfernandez @pfmoore Denkt jemand von euch, dass dieses Problem geschlossen werden sollte?

_{Bearbeiten (18.05.2017): Satzzeichen + Nebentext hinzugefügt}

Scheint vernünftig.

Hallo alle,
Ich habe ein einfaches Skript / ein einfaches Skript erstellt, das die Arbeit erledigt.

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

Warum macht man das nicht einfach?

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

Weil es in Wirklichkeit nicht so einfach ist, da Sie möglicherweise Versionen installieren, die einige der Abhängigkeiten Ihrer anderen Pakete nicht erfüllen.

Basierend auf und dank des Kerns von @serafeimgr habe ich ein möglicherweise nützliches Befehlszeilentool geschrieben, pip_upgrade_outdated ; Quelle auf github . Rückmeldung erwünscht.

(Siehe auch diese Ausgabe : Ja, die parallele Ausführung ist besonders gefährlich, und ja, das kann Dinge kaputt machen. Trotzdem führen viele Leute so etwas ständig von Hand und finden es möglicherweise nützlich.)

Vielen Dank, dass Sie sich die Zeit genommen haben, eine Komplettlösung zu erstellen.
Obwohl meine Empfehlung wäre, einen Weg zu finden, um diese Funktion auf Pip zu bringen.

Ich denke, pipenv & pipfile wird pip/requirements.txt sowieso ersetzen.
Vielleicht weiß @kennethreitz mehr über die Roadmap und das Feature --upgrade all.

@qoheniac | tr ... ist überflüssig.

Dieser Thread wurde automatisch gesperrt, da nach dem Schließen in letzter Zeit keine Aktivität stattgefunden hat. Bitte öffnen Sie eine neue Ausgabe für verwandte Fehler.