Was ist der Zweck von "pip install --user ..."?


186

Von pip install --help:

 --user      Install to the Python user install directory for your platform. Typically ~/.local/, or %APPDATA%\Python on
             Windows. (See the Python documentation for site.USER_BASE for full details.)

Die Dokumentation für site.USER_BASE ist ein erschreckendes Wurmloch interessanter * NIX-Themen, die ich nicht verstehe.

Was ist der Zweck --userin einfachem Englisch? Warum sollte es wichtig sein, das Paket zu installieren ~/.local/? Warum nicht einfach irgendwo eine ausführbare Datei in meinen $ PATH einfügen?


2
Sie können import site; print site.USER_SITEden Installationsort drucken. Für mich habe ich /${HOME}/.local/lib/python${PY_MAJOR}.${PY_MINOR}/site-packages.
Trevor Boyd Smith

1
Auf einem Hostcomputer /usr/local/lib/pythonX.X/dist-packagesist dies das Standardverzeichnis für Pakete, die von pip installiert wurden . Wenn ein Benutzer jedoch benutzerspezifische Pakete installieren möchte, kann er diese verwenden $ sudo pip3 --user install some_package. Dieses Paket ist für Gruppen und andere Personen, die auf diesen Host zugreifen, nicht verfügbar.
Noobninja

Antworten:


223

pip installiert standardmäßig Python-Pakete in einem Systemverzeichnis (z. B. /usr/local/lib/python3.4). Dies erfordert Root-Zugriff.

--user Pip installiert stattdessen Pakete in Ihrem Home-Verzeichnis, für die keine besonderen Berechtigungen erforderlich sind.


1
Vielen Dank; Das macht Sinn. Aber ist --useres wichtig sicherzustellen, dass das Paket nicht als root ausgeführt wird? (Ich stelle mir ähnliche Optionen wie Wireshark / kismet / burpsuite vor, um Richtlinien für den Gruppenzugriff einzurichten, wodurch nicht alle Programmfunktionen als Root ausgeführt werden können. Ist das auf dem richtigen Weg?) Oder ist die --userOption nur gemeint zu ermöglichen , um die Installation ohne root - Rechte? Wenn das der Fall ist, warum benutze ich es nie sudo pip install foo_package? Ich habe noch nie Root-Privilegien benötigt, um über Pip zu installieren.
Rob Truxal

12
@ Rob Truxal. Ich denke, der Punkt ist, dass das Paket von anderen Benutzern nicht gesehen wird. Vielleicht möchten Sie eine ältere / neuere Version eines Pakets, aber wenn Sie es auf dem System installieren, werden Sie Ihre Arbeitskollegen durcheinander bringen.
NDEthos

4
Oh! Bei dem --userParameter geht es um Benutzerisolation! Das macht wie eine lächerliche Menge Sinn. Danke @NDEthos!
Rob Truxal

ok hier ist eine (noobische) frage: Angenommen, ich habe mich als Benutzer foo angemeldet und dann diesen Befehl pip install --user -r require.txt .. ausgeführt und alles gut installiert. Dann habe ich mich als Benutzerleiste angemeldet und das Python-Programm wie folgt ausgeführt: sudo -u foo ./odoo-bin .. Wird es aus den Python-Paketen gelesen, die für den foo-Benutzer installiert wurden? oder wie geht das
Abbood

1
Gibt es auch eine Möglichkeit, nur die Pakete aufzulisten, die für den aktuellen Benutzer installiert sind? dh so etwas wie pip freeze --user?
Abbood

24

--userinstalliert in site.USER_SITE.

Für meinen Fall war es /Users/.../Library/Python/2.7/bin. Also habe ich das zu meinem PFAD hinzugefügt (in ~/.bash_profileDatei):

export PATH=$PATH:/Users/.../Library/Python/2.7/bin

15

Andere Antworten erwähnen site.USER_SITE, wo Python-Pakete platziert werden. Wenn Sie nach Binärdateien suchen, gehen diese ein {site.USER_BASE}/bin.

Wenn Sie dieses Verzeichnis zum Suchpfad Ihrer Shell hinzufügen möchten, verwenden Sie:

export PATH="${PATH}:$(python3 -c 'import site; print(site.USER_BASE)')/bin"

11

Nur eine Warnung:

Nach diesem Thema , --userwird derzeit in einer virtuellen env ist nicht gültig pip, da ein Benutzer Lage nicht wirklich sinnvoll für eine virtuelle Umgebung macht.

Verwenden Sie es also nicht pip install --user some_pkg in einer virtuellen Umgebung , da sonst die virtuelle Umgebung pipverwirrt wird. Siehe diese Antwort für weitere Details.


10

Der beste Weg ist zu installieren virtualenvund nicht die --userVerwirrung zu erfordern . Sie erhalten mehr Flexibilität und müssen sich nicht jedes Mal, wenn Sie ein Paket installieren, die verschiedenen Python-Versionen und -Projekte überladen.

https://virtualenv.pypa.io/en/stable/


8

Unter macOS besteht der Grund für die Verwendung des --userFlags darin, sicherzustellen, dass die Bibliotheken, auf die sich das Betriebssystem stützt, nicht beschädigt werden. Ein konservativer Ansatz für viele MacOS-Benutzer besteht darin, die Installation oder Aktualisierung von pip mit einem erforderlichen Befehl zu vermeiden sudo. Dies beinhaltet also die Installation auf/usr/local/bin ...

Ref: Installieren von Python für Neovim ( https://github.com/zchee/deoplete-jedi/wiki/Setting-up-Python-for-Neovim )

Ich bin mir nicht ganz sicher, warum die Installation /usr/local/binauf einem Mac ein Risiko darstellt, da das System nur auf Python-Binärdateien in /Library/Frameworks/und angewiesen ist /usr/bin. Ich vermute, es liegt daran, dass, wie oben erwähnt, die Installation in /usr/local/binerfordert, sudowas die Tür zu einem kostspieligen Fehler mit den Systembibliotheken öffnet. Die Installation in ~/.local/binist daher ein sicherer Weg, um dieses Risiko zu vermeiden.

Ref: Verwenden von Python auf einem Mac ( https://docs.python.org/2/using/mac.html )

In dem Maße, in dem die Installation von Paketen einen Vorteil /usr/local/binbietet, frage ich mich, ob es sinnvoll ist, den Eigentümer des Verzeichnisses von rootauf zu ändern user. Dies würde eine Verwendung vermeiden und sudogleichzeitig vor systemabhängigen Änderungen schützen. * Ist dies ein Sicherheitsstandard, ein Relikt davon, wie Unix-Systeme in der Vergangenheit häufiger verwendet wurden (als Server)? Oder zumindest ein guter Weg für Mac-Benutzer, die keinen Server hosten?

* Hinweis: Die SIP-Funktion (System Integrity Protection) von Mac scheint den Benutzer auch vor dem Ändern der systemabhängigen Bibliotheken zu schützen.

- E.


8

Ohne virtuelle Umgebungen

pip <command> --user Ändert den Umfang des aktuellen pip-Befehls so, dass er auf dem lokalen Python-Paketinstallationsspeicherort des aktuellen Benutzerkontos und nicht auf dem standardmäßigen systemweiten Paketinstallationsspeicherort funktioniert.

Dies ist nur auf einem Mehrbenutzer-Computer wirklich wichtig. Alles, was am Systemspeicherort installiert ist, ist für alle Benutzer sichtbar. Wenn Sie also am Benutzerstandort installieren, wird die Paketinstallation von anderen Benutzern getrennt (sie sehen sie nicht und müssten sie separat installieren, um sie zu verwenden). Da es zu Versionskonflikten kommen kann, kann die Installation eines Pakets mit Abhängigkeiten, die von anderen Paketen benötigt werden, zu Problemen führen. Es ist daher am besten, nicht alle von einem bestimmten Benutzer verwendeten Pakete an den Installationsort des Systems zu verschieben.

  • Wenn es sich um einen Einzelbenutzercomputer handelt, gibt es kaum oder keinen Unterschied bei der Installation am --userStandort. Es wird in einem anderen Ordner installiert, der je nach Paket und Verwendung möglicherweise zum Pfad hinzugefügt werden muss oder nicht (viele Pakete installieren Befehlszeilentools, die sich auf dem Pfad befinden müssen, um von einer Shell ausgeführt zu werden). .
  • Wenn es sich um einen Mehrbenutzercomputer handelt, --userwird die Verwendung von root / sudo bevorzugt oder es ist eine Administratorinstallation erforderlich, die sich auf die Python-Umgebung jedes Benutzers auswirkt, außer in Fällen allgemeiner Pakete, die der Administrator standardmäßig allen Benutzern zur Verfügung stellen möchte.
    • Hinweis: Per Kommentare, auf den meisten Unix / Linux installiert es wurde darauf hingewiesen , dass das System installiert den allgemeinen Paket - Manager verwenden sollte, wie zum Beispiel apt, statt pip.

Mit virtuellen Umgebungen

Die --userOption in einer aktiven venv / virtualenv-Umgebung wird am Python-Speicherort des lokalen Benutzers installiert (wie ohne virtuelle Umgebung).

Pakete werden standardmäßig in der virtuellen Umgebung installiert. Wenn Sie sie jedoch verwenden --user, wird die Installation außerhalb der virtuellen Umgebungen im Python-Skriptverzeichnis des Benutzers erzwungen (unter Windows ist dies derzeit c:\users\<username>\appdata\roaming\python\python37\scriptsfür mich mit Python 3.7 der Fall).

Sie können jedoch nicht von einer virtuellen Umgebung aus auf ein System oder eine Benutzerinstallation zugreifen (selbst wenn Sie diese --userin einer virtuellen Umgebung verwendet haben).

Wenn Sie eine virtuelle Umgebung mit dem --system-site-packagesArgument installieren , haben Sie Zugriff auf den Systemskriptordner für Python. Ich glaube, dies beinhaltete auch den Benutzer-Python-Skriptordner, bin mir aber nicht sicher. Dies kann jedoch unbeabsichtigte Folgen haben, und es ist nicht die beabsichtigte Art, virtuelle Umgebungen zu verwenden.


Speicherort des Python-Systems und der Installationsordner für lokale Benutzer

Sie finden den Speicherort des Benutzerinstallationsordners für Python mit python -m site --user-base. Ich finde widersprüchliche Informationen in den Fragen und Antworten, in der Dokumentation und verwende diesen Befehl tatsächlich auf meinem PC, um die Standardeinstellungen zu ermitteln. Sie befinden sich jedoch unter dem Benutzer-Ausgangsverzeichnis ( ~Verknüpfung in * nix und c:\users\<username>normalerweise für Windows).


Andere Details

Die --userOption ist nicht für jeden Befehl gültig. Beispielsweise pip uninstallwerden Pakete überall dort gefunden und deinstalliert, wo sie installiert wurden (im Benutzerordner, im Ordner für die virtuelle Umgebung usw.), und die --userOption ist ungültig.

Mit installierte pip install --userElemente werden an einem lokalen Speicherort installiert, der nur vom aktuellen Benutzerkonto angezeigt wird, und erfordern keinen Root-Zugriff (unter * nix) oder Administratorzugriff (unter Windows).

Die --userOption ändert alle pip Befehle, die sie akzeptieren, um den Benutzerinstallationsordner anzuzeigen / zu bearbeiten. Wenn Sie sie verwenden pip list --user, werden nur Pakete angezeigt, mit denen sie installiert wurden pip install --user.


1
Würden Sie erwägen, den ersten Teil neu zu formulieren? Außerhalb einer virtuellen Python-Umgebung ist es wirklich am besten, die Verwendung ganz pip installohne zu vermeiden --user. Dies würde Python-Pakete an Stellen installieren, die wirklich dem Paketmanager des Systems überlassen werden sollten (zum Beispiel aptin Debian / Ubuntu). Es ist besser, sich nicht damit anzulegen, das führt zu so vielen Problemen. Wenn ein Python-Paket für alle Benutzer verfügbar sein muss, verwenden Sie den Paketmanager des Betriebssystems, tun Sie dies jedoch nicht sudo pip install .... Eine Alternative ist sudo pip install --target .... Unter Windows ist dies weniger ein Problem.
Sinoroc

Okay - Sie meinen die zweite Hälfte des letzten Aufzählungspunkts im Abschnitt "Ohne virtuelle Umgebungen"? Wenn nicht, welche spezifischen Teile? (Fühlen Sie sich frei, es direkt für dieses Update zu bearbeiten, ich bin nicht in erster Linie ein * nix-Benutzer)
LightCC

Ich sehe, wenn Sie Windows nicht verwenden, ist dies in der Tat viel weniger besorgniserregend, da es keinen zentralen Paketmanager gibt, es sei denn, Sie verwenden etwas wie Nuget . Ich werde sehen, ob ich vorbeikomme, um Ihre Antwort zu bearbeiten.
Sinoroc

@sinoroc Ich habe diesem Absatz eine Notiz hinzugefügt. Fühlen Sie sich frei, es genauer zu aktualisieren usw. oder an anderer Stelle zu bearbeiten, wenn ich einen ähnlichen Wortlaut habe.
LightCC

1

Warum nicht einfach irgendwo eine ausführbare Datei in meinen $ PATH einfügen?

~/.local/bin directorywird theoretisch erwartet, in Ihrem zu sein $PATH.

Diesen Leuten zufolge ist es ein Fehler, der $PATHbei der Verwendung nicht hinzugefügt wird systemd.

Diese Antwort erklärt es ausführlicher.

Aber auch wenn Ihre Distribution enthält das ~/.local/binVerzeichnis auf das$PATH , könnte es in der folgenden Form (innen sein ~/.profile):

if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

Dies würde erfordern, dass Sie sich abmelden und erneut anmelden , wenn das Verzeichnis vorher nicht vorhanden war.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.