Wie kann ich Pip- und Python-Benutzerpakete blockieren?

Wie kann ich Pip- und Python-Benutzerpakete blockieren?

Ich versuche zu verhindern, dass Benutzer Pip verwenden, um Pakete in ihren Home-Verzeichnissen zu installieren.

Die Ausgabe von python3 -m site --helpwürde darauf hinweisen, dass ein Superuser das Benutzerverzeichnis deaktivieren kann. Aber wie geht das? Ich habe versucht, es site.ENABLE_USER_SITEvon einem aus einzustellen sitecustomize.py, aber das hilft nicht. Das Einstellen PYTHONNOUSERSITE=1in der Umgebung oder die Übergabe -san Python funktioniert, ist aber nicht gerade eine Superuser-Optimierung.

Ich habe auch versucht, dies zu erreichen, indem ich Pip irgendwie für Benutzer deaktiviert habe. Wir wären ganz zufrieden, wenn Pakete in Venv-Umgebungen, aber nicht in Benutzer-Home-Verzeichnissen installiert würden. Gibt es etwas, das ich eingeben kann, um Installationen pip.confzwangsweise zu deaktivieren ?--user

Antwort1

Q:Gibt es etwas, das ich in pip.conf einfügen kann, um --user-Installationen zwangsweise zu deaktivieren?

A:Nein. Die Konfigurationsdatei kann immer entsprechend der Priorität überschrieben werden, die in derPip-Dokumente:

Befehlszeilenoptionen haben Vorrang vor Umgebungsvariablen, die wiederum Vorrang vor der Konfigurationsdatei haben.

Q:Ein Superuser kann das Benutzerverzeichnis deaktivieren. Aber wie funktioniert das? Die Einstellung PYTHONNOUSERSITE=1in der Umgebung oder die Übergabe -san Python funktioniert, ist aber nicht unbedingt eine Superuser-Optimierung.

A:Ich bin über Google auf diese Frage gestoßen, weil ich genau das Gegenteil herausgefunden habe. Ich sehe keine PYTHONNOUSERSITEtatsächliche Änderung des Verhaltens von Pip:

$ docker run --net=host -it python:3.8 bash

$ pip install -U pip
Requirement already up-to-date: pip in /usr/local/lib/python3.8/site-packages (20.2.2)

$ ls -ltr ~/.local
ls: cannot access '/root/.local': No such file or directory

$ PYTHONNOUSERSITE=1 pip install --user typing-extensions
Collecting typing-extensions
  Downloading typing_extensions-3.7.4.3-py3-none-any.whl (22 kB)
Installing collected packages: typing-extensions
Successfully installed typing-extensions-3.7.4.3

$ ls -ltr ~/.local
total 4
drwxr-xr-x 3 root root 4096 Aug 24 07:08 lib

DerDokumente fürPYTHONNOUSERSITEerklären Sie, dass:

Wenn dies festgelegt ist, fügt Python das Site-Packages-Verzeichnis des Benutzers nicht zu sys.path hinzu.

Auch wenn mich das Verhalten überrascht hat, nehme ich an, dass es sinnvoll ist, pip auch dann zu installieren, PYTHONUSERBASEwenn diese Variable gesetzt ist (auch wenn die resultierendeEingerichtetPaket wird im Python-Pfad nicht verfügbar sein).

Ich habe einen ... gefundenrelevantes Problem im Pip Issue Trackerund es sieht so aus, als gäbe es bereits einen Sonderfall für Venvs, bei denen Systemsite-Pakete deaktiviert sind (Standard) und keine Benutzerinstallationen durchgeführt werden dürfen (ich habe dies nicht explizit überprüft).

Wenn wir also der Lösung für den ursprünglichen Fehlerbericht folgen, gelangen wir zu einem Pull Request, der einigeinteressante Features. Es gibt nämlich anscheinend eine spezielle Datei, die ein Superuser erstellen kann, ````, die die Installation des Site-Pakets durch den Benutzer deaktiviert. Ich habe auch eineFrage zu SO in Bezug auf dieses. Also habe ich Folgendes versucht, aber leider wurde es trotzdem weiterhin in der Benutzerbasis installiert:

$ touch /usr/local/lib/python3.8/no-global-site-packages.txt

$ pip install --user typing-extensions
...
Successfully installed typing-extensions-3.7.4.3

Natürlich macht das Sinn, wenn wir die tatsächlichePull Request-Implementierungdas nur in Virtualenv-Situationen nach dieser Datei sucht. In meinem Fall möchte ich in der Lage sein,stetsDeaktivieren Sie dieses Verhalten, also werde ich mich etwas eingehender mit der Pip-Codebasis befassen ...

Es stellt sich heraus, dass die Schlüsselfunktion istdecide_user_site, welchetutehren diesite.ENABLE_USER_SITEWert, abernurnachdem es nach dem expliziten Argument gesucht hat user. Wie wir in der Funktion selbst sehen können, ist dies asymmetrisch zur Handhabung virtueller Umgebungen, was globale/Benutzerinstallationen verhindert, wenn eine virtuelle Umgebung sie deaktiviert hat. Ich halte dies für einen Fehler und habe es inhttps://github.com/pypa/pip/issues/8794.

Die Antwort lautet also: Soweit ich weiß, ist es derzeit nicht möglich, --userInstallationen in einer Basisumgebung (also einer nicht virtuellen Umgebung) zu deaktivieren. Wenn esIstmöglich, dies zu tun (hoffentlich, wenn das oben verlinkte Problem behoben ist) die -sund PYTHONNOUSERSITE=1Umgebungsvariablen können verwendet werden, aber die "Sys-Admin"-Methode, die Sie meiner Meinung nach suchen, besteht darin,site.py direkt, wie in der site.py-Implementierung erklärt.

Antwort2

Alter Thread, aber hier ist eine mögliche Lösung: Erzwingen Sie, dass Pip eine virtuelle Umgebung hat und nicht direkt auf der Site des Benutzers installiert wird.

export PIP_REQUIRE_VIRTUALENV=true

Hier ist der relevante Link: https://docs.python-guide.org/dev/pip-virtualenv/

verwandte Informationen