ubuntuusers.de

Hallo,

ich halte diese "getrickse" mit der gleichzeitigen per Nutzer und systemweise Installation aber nicht für sinnvoll. Genau dafür sind virtual environments, wo so was problems los geht.

Außerdem - und das haben wir dir auch schon bei diversen anderen Artikel gesagt - braucht, muss und soll das Wiki nicht jeden möglichen und unmöglichen Corner-Case abdecken.

Zu

pip install -U installieres_modul nicht_installiertes Modul 

wenn das nicht grundsätzlich und immer funktioniert, dann sollte das aus dem Artikel raus. Zu erklären, wann und warum das funktioniert (oder nicht) würde ich auch als Corner-Case bezeichnen.

Gruß, noisefloor

Heinrich_Schwietering schrieb:

Hi!

Und was ist das anderes, als pip komplett zu deinstallieren, und manuell wieder zu installieren? Nur ohne vorgeschrieben Befehl? Es soll da verschiedenen Möglichkeiten geben, habe ich irgendwo gehört...

so long
hank

Hallo Heinrich_Schwietering, es ist definitiv anders als das im Abschnitt Manuelle Installation beschriebene Vorgehen! Denn es muss _kein_ Installationsprogramm umständlich heruntergeladenladen werden und dann ausgeführt werden, sondern es reichen zwei Befehle 😉

noisefloor schrieb:

Hallo,

ich halte diese "getrickse" mit der gleichzeitigen per Nutzer und systemweise Installation aber nicht für sinnvoll. Genau dafür sind virtual environments, wo so was problems los geht.

Außerdem - und das haben wir dir auch schon bei diversen anderen Artikel gesagt - braucht, muss und soll das Wiki nicht jeden möglichen und unmöglichen Corner-Case abdecken.

Zu

pip install -U installieres_modul nicht_installiertes Modul 

wenn das nicht grundsätzlich und immer funktioniert, dann sollte das aus dem Artikel raus. Zu erklären, wann und warum das funktioniert (oder nicht) würde ich auch als Corner-Case bezeichnen.

Gruß, noisefloor

Hallo noisefloor,

offenbar hast Du meine Absichten betreffend meiner beiden Posts 8931300 und 8931312 nicht verstanden:

Im ersten ging es mir – wie Du es dann ja auch im Baustellen-Artikel korrigiert hast – um die Option --user, welche auch zur lokalen Aktualisierung nötig ist. Allerdings hast Du in deinem hinzugefügten Satz Ist das Modul systemweit installiert, dann muss die Option --user weg gelassen werden. vergessen, auf die Root-Rechte bzw. sudo hinzuweisen.

Im zweiten Post ging es mir dann um einen Befehl, der alle Python-Pakete "in einem Rutsch" aktualisieren kann. Das mit der dabei aufgetretenen zusätzlichen lokalen Installation von "youtube-dl" war dabei wohl so eine Art von Kollateralschaden, welchen man natürlich dadurch vermeiden kann, indem man manuelle Installationen von Python-Modulen generell lokal durchführt! In meinem Fall war "youtube-dl" allerdings vorher von mir systemweit installiert worden, da habe ich mich dann natürlich darüber gefreut, dass der kombinierte Befehl trotzdem funktioniert hat!

Vllt. sollte aber darauf hingewiesen werden, nach Anwendung des kombinierten Befehles sicherheitshalber die beiden Befehle

ls -la ~/.local/lib/python3.4/site-packages  

und

ls -la /usr/local/lib/python3.4/dist-packages  

auszuführen (natürlich auf die jeweilige Python-Version angepasst), um Doppel-installation und somit mögliche Komplikationen vermeiden zu können! ⇒ Alternative Befehle dito:

pip3 list --user 

und

pip3 list 

Allerdings listen die jeweiligen zweiten Befehle auch die durch die Paketverwaltung installierten Module auf (die sind aber nicht als solche gekennzeichnet!!!), falls man davon dann, um Doppelungen zu vermeiden, welche deinstalliert, dann könnte das ja Schaden anrichten ☹

Am Allersichersten wäre aber wohl die Abwandlung des kombinierten Befehles:

pip3 freeze --user | grep -v '^\-e' | cut -d = -f 1  | xargs -n1 pip3 install --user -U  

Die Option --force-reinstall muss ja gar nicht zwingend erwähnt werden!

Hi! linux_joy schrieb:

Hallo Heinrich_Schwietering, es ist definitiv anders als das im Abschnitt Manuelle Installation beschriebene Vorgehen! Denn es muss _kein_ Installationsprogramm umständlich heruntergeladenladen werden und dann ausgeführt werden, sondern es reichen zwei Befehle 😉

Unbestritten, aber im Problem ging es um Pakete aus den Quellen, die per Paketverwaltung installiert und entsprechend auch deinstaliert werden können. Und dann gibt es eben verschiedene Wege, das dann manuell neu zu installieren; aber das ist jedem Nutzer selbst überlassen, wie er das lösen möchte. Muss easyinstall nicht auch "umständlich" über die setuptools heruntergeladen werden?... In Wiki-Artikeln wird grundsätzlich nicht jeder Schritt beschrieben; das führt unweigerlich zu Redundanz; und auch nicht jede Ausnahme/Spezialvariante...

so long
hank

Hallo,

offenbar hast Du meine Absichten betreffend meiner beiden Posts 8931300 und 8931312 nicht verstanden:

Kann schon sein. Da hast ja immer den Hang, alles ausscheifendst zu erklären statt kurz & prägnant & übersichtlich. Dann kann schon mal was "auf der Streck" bleibem...

Ich sehe den Use Case auch nicht, dass man alle Module in einem Rutsch aktualisieren muss... Den größere Teil der Python-Module braucht man beim Programmieren mit Python - und da will man normalerweise auf keinen Fall alles "am Block" aktualiseren, zu ggf. zu Versionssprüngen und Inkompatibilitäten führt. Und an dieser auch nochmal der Hinweis: virtual environment wo immer es geht.

Du kannst du Shell-Befehl aber gerne in einen eigenen Abschntit "Tipps & Tricks" unterbringen.

Gruß, noisefloor

Hi! Heinrich_Schwietering schrieb:

Hi! linux_joy schrieb:

Hallo Heinrich_Schwietering, es ist definitiv anders als das im Abschnitt Manuelle Installation beschriebene Vorgehen! Denn es muss _kein_ Installationsprogramm umständlich heruntergeladenladen werden und dann ausgeführt werden, sondern es reichen zwei Befehle 😉

Unbestritten, aber im Problem ging es um Pakete aus den Quellen, die per Paketverwaltung installiert und entsprechend auch deinstaliert werden können. Und dann gibt es eben verschiedene Wege, das dann manuell neu zu installieren; aber das ist jedem Nutzer selbst überlassen, wie er das lösen möchte. Muss easyinstall nicht auch "umständlich" über die setuptools heruntergeladen werden?... In Wiki-Artikeln wird grundsätzlich nicht jeder Schritt beschrieben; das führt unweigerlich zu Redundanz; und auch nicht jede Ausnahme/Spezialvariante...

so long
hank

Also gut, Du hast hiermit gewonnen...

Aber ich hätte noch eine Frage: Sollte nicht sicherheitshalber vor der manuellen Installation ein eventuell aus den Paketquellen stammendes Paket python-pip bzw. python-pip deinstalliert werden? ⇒ So steht es ja bereits im Abschnitt Ubuntu 14.04, aber eben _nicht_ in Manuelle Installation ⇒ Werde ich dort gleich mit eintragen!

Hi! noisefloor schrieb:

Hallo,

offenbar hast Du meine Absichten betreffend meiner beiden Posts 8931300 und 8931312 nicht verstanden:

Kann schon sein. Da hast ja immer den Hang, alles ausscheifendst zu erklären statt kurz & prägnant & übersichtlich. Dann kann schon mal was "auf der Streck" bleibem...

Ich sehe den Use Case auch nicht, dass man alle Module in einem Rutsch aktualisieren muss... Den größere Teil der Python-Module braucht man beim Programmieren mit Python - und da will man normalerweise auf keinen Fall alles "am Block" aktualiseren, zu ggf. zu Versionssprüngen und Inkompatibilitäten führt. Und an dieser auch nochmal der Hinweis: virtual environment wo immer es geht.

Du kannst du Shell-Befehl aber gerne in einen eigenen Abschntit "Tipps & Tricks" unterbringen.

Gruß, noisefloor

Bei mir ginge es z.B. hauptsächlich um die Module "streamlink", "youtube_dl" und "youtube-dlg", also nix mit Programmieren...

Den Abschntit "Tipps & Tricks" werde ich aber sogleich anlegen! = Und der ist inzwischen auch angelegt!

Nochwas zu den Modulnamen: Sollen die im Fließtext laut Wiki/Syntax nicht in Monotype formatiert sein?

Hallo,

Artikel ist wieder im Wiki. Danke auf an linux_joy für die Ergänzungen & Präzisierungen beim "Upgrade" des Artikels ☺

Gruß, noisefloor

Hallo,

im Zuge der letzten Revision heute nacht ist der folgende Hinweis entfernt worden:

Hinweis:

Ab Python 3.4 ist das pip-Modul in der Standardinstallation von Python enthalten, so dass eine nachträgliche Installation entfällt.

Dazu zwei Fragen:

1. Müssten nun nicht auch konsequenterweise die beiden Abschnitte "Nutzung" und "pip ausführen" entsprechend angepasst werden?

2. In der Beschreibung zur letzten Revision steht u.a. auch " +bionic", was ich allerdings im Artikel vermisse.

Hallo,

hatte wohl vergessen, den letzten Stand der Bearbeitung zu speichern... Ist jetzt drin. Danke für den Hinweis.

Gruß, noisefloor

Für das Update der nicht mehr aktuellen (User) Module (ich verwende pip immer ohne sudo) habe ich ein python Script auf github pip_update_outdated

Python2:

python pip_update_outdated.py

Python 3

python3 pip_update_outdated.py

Hallo,

sollte der Vollständigkeit halber im Artikel nicht mit angegeben werden, wohin die systemweit über die Paketverwaltung installierten Module installiert werden, und wohin etwaig im Python-Modul enthaltene ausführbare Programme abgelegt werden? Ersteres ist bei mir in Lubuntu 18.04 /usr/lib/pythonX.Y/dist-packages/, Letzteres - weiß ich nicht genau - wohl /usr/bin. Genau genommen liegen bei mir Module in /usr/lib/python2.7/dist-packages, /usr/lib/python3/dist-packages und /usr/lib/python3.6/site-packages (in Letzterem aber lediglich das Modul "indicator_keyboard"). In /usr/lib sind auch noch die 2 Verzeichnisse python3.5 und python3.7, welche aber keine für uns relevanten Unterverzeichnisse haben. Zumindest /usr/lib/python3.5 hat aber direkt in sich u.a. das "venv"-Modul, /usr/lib/python3.7 hat direkt 3 Module: distutils, lib2to3 und lib-dynload.

Grund für die Ergänzung wäre m.E., dass es, falls man Module über pip systemweit installiert, trotzdem zu keinen Konflikten mit den systemweit über die Paketverwaltung installierten Modulen kommt.

Als Stellen, wo die vorstehenden Infos einzutragen wären, kämen ja eigentlich nur die Abschnitte "Wohin werden mit pip installierte Python-Module installiert?" oder "Wohin sollte man installieren?" infrage.

Was meint Ihr dazu?

Hallo,

Grund für die Ergänzung wäre m.E., dass es, falls man Module über pip systemweit installiert, trotzdem zu keinen Konflikten mit den systemweit über die Paketverwaltung installierten Modulen kommt.

Das steht bereits im Artikel. Bzw. man könnte da noch ergänze, dass die Pfade auch konfliktfrei sind. Der absolute Pfad der via Paketverwaltung installierten Module ist eigentlich egal, weil es keine Grund gibt, da von Hand irgendwas machen zu wollen.

Gruß, noisefloor

Hallo,

noisefloor schrieb:

Hallo,

Grund für die Ergänzung wäre m.E., dass es, falls man Module über pip systemweit installiert, trotzdem zu keinen Konflikten mit den systemweit über die Paketverwaltung installierten Modulen kommt.

Das steht bereits im Artikel. Bzw. man könnte da noch ergänze, dass die Pfade auch konfliktfrei sind. (...)

Wo bitte genau soll Deiner Meinung nach denn stehen, dass es, falls man Module über pip systemweit installiert, trotzdem zu keinen Konflikten mit den systemweit über die Paketverwaltung installierten Modulen kommt?

Im Gegenteil steht unter "Wohin sollte man installieren?" folgendes:

Die lokale Installation bzw. ein lokales „Virtual Environment“ hat weiterhin den Vorteil, dass man keine Konflikte bzw. Probleme mit Modulen bekommt, die systemweit über die Paketverwaltung installiert wurden.

Hallo,

in der 1. Hinweisbox.

Gruß, noisefloor