pip Installation in globalen Site-Paketen anstelle von virtualenv

Wenn Sie pip3ein Paket in einem installieren, virtualenvwird das Paket im globalen Ordner "site-packages" anstatt im Ordner "virtualenv" installiert. So richte ich Python3 und virtualenv unter OS X Mavericks (10.9.1) ein:

Ich habe Python3 mit Homebrew installiert:

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
brew install python3 --with-brewed-openssl

Die $PATHVariable wurde geändert in .bash_profile; fügte die folgende Zeile hinzu:

export PATH=/usr/local/bin:$PATH

Running which python3kehrt zurück /usr/local/bin/python3(nach dem Neustart der Shell).

Hinweis: which python3Gibt immer noch / zurück usr/bin/python.

Installiert virtualenvmit pip3:

pip3 install virtualenv

Erstellen Sie als Nächstes ein neues virtualenvund aktivieren Sie es:

virtualenv testpy3 -p python3
cd testpy3
source bin/activate

Hinweis: Wenn ich -p python3 nicht spezifiziere, fehlt pip im Ordner bin in der virtuellen Umgebung.

Laufen which pipund which pip3beide Rückkehr des virtualenv Ordner:

/Users/kristof/VirtualEnvs/testpy3/bin/pip3

Wenn ich jetzt versuche, zB Markdown mit pip in der aktivierten virtuellen Umgebung zu installieren, wird pip im globalen Ordner "site-packages" anstelle des Ordners "site-packages" der virtuellen Umgebung installiert.

pip install markdown

Laufende pip listRenditen:

Markdown (2.3.1)
pip (1.4.1)
setuptools (2.0.1)
virtualenv (1.11)

Inhalt von /Users/kristof/VirtualEnvs/testpy3/lib/python3.3/site-packages:

__pycache__/
_markerlib/
easy_install.py
pip/
pip-1.5.dist-info/
pkg_resources.py
setuptools/
setuptools-2.0.2.dist-info/

Inhalt von /usr/local/lib/python3.3/site-packages:

Markdown-2.3.1-py3.3.egg-info/
__pycache__/
easy-install.pth
markdown/
pip-1.4.1-py3.3.egg/
setuptools-2.0.1-py3.3.egg
setuptools.pth
virtualenv-1.11-py3.3.egg-info/
virtualenv.py
virtualenv_support/

Wie Sie sehen können, enthält der globale Ordner "site-packages" Markdown, der Ordner "virtualenv" nicht.

Hinweis: Ich hatte Python2 und Python3 zuvor auf einer anderen VM installiert (befolgte diese Anweisungen) und hatte das gleiche Problem mit Python3. Die Installation von Paketen in einer Python2-basierten virtuellen Umgebung funktionierte jedoch einwandfrei.

Alle Tipps, Hinweise, ... wäre sehr dankbar.

Komisch, dass du das angesprochen hast, ich hatte genau das gleiche Problem. Ich habe es schließlich gelöst, bin mir aber immer noch nicht sicher, was es verursacht hat.

Versuchen Sie, Ihre bin/pipund bin/activateSkripte zu überprüfen . In bin/pip, Blick auf den shebang. Ist es richtig? Wenn nicht, korrigieren Sie es. Dann auf der Linie ~ 42in Ihnen bin/activate, überprüfen Sie , ob Ihr virtualenv Weg richtig ist. Es wird ungefähr so ​​aussehen

VIRTUAL_ENV="/Users/me/path/to/virtual/environment"

Wenn es falsch ist, korrigieren, deactivateund dann . bin/activate, und wenn unser gemeinsames Problem die gleiche Ursache hatte, sollte es funktionieren. Wenn dies immer noch nicht der Fall ist, sind Sie sowieso auf dem richtigen Weg. Ich habe die gleiche Problemlösungsroutine wie Sie durchlaufen, which pipimmer und immer wieder, dem Stack-Trace gefolgt usw.

Stellen Sie das unbedingt sicher

/Users/kristof/VirtualEnvs/testpy3/bin/pip3

ist das, was Sie wollen und sich nicht auf ein anderes Testprojekt mit ähnlichem Namen beziehen (ich hatte dieses Problem und habe keine Ahnung, wie es gestartet wurde. Mein Verdacht besteht darin, dass mehrere virtuelle Umgebungen gleichzeitig ausgeführt werden).

Wenn nichts davon funktioniert, könnte eine vorübergehende Lösung darin bestehen, wie Joe Holloway sagte:

Führen Sie einfach den Pip des virtualenv mit seinem vollständigen Pfad aus (dh verlassen Sie sich nicht darauf, den ausführbaren Pfad zu durchsuchen), und Sie müssen nicht einmal die Umgebung aktivieren. Es wird das Richtige tun.

Vielleicht nicht ideal, aber es sollte zur Not funktionieren.

Link zu meiner ursprünglichen Frage:

VirtualEnv / Pip versucht, Pakete global zu installieren

Für mich war dies kein Pip- oder Virtualenv-Problem. Es war ein Python-Problem. Ich hatte mein $ PYTHONPATH manuell in ~ / .bash_profile (oder ~ / .bashrc) eingestellt, nachdem ich einem Online-Tutorial gefolgt war. Dieses manuell festgelegte $ PYTHONPATH war in der virtuellen Umgebung verfügbar, da dies wahrscheinlich zulässig sein sollte.

Außerdem add2virtualenvwurde mein Projektpfad aus irgendeinem Grund in der virtuellen Umgebung nicht zu meinem $ PYTHONPATH hinzugefügt.

Nur ein paar Gabelpfade für diejenigen, die noch stecken bleiben könnten! Prost!

Ich hatte das gleiche Problem, ich löste es, indem ich das venv-Verzeichnis entfernte und es neu erstellte!

deactivate (if venv is activated first deactivate it)
rm -rf venv
virtualenv -p python3 venv
. ENV/bin/activate
pip3 install -r requirements.txt

Jetzt funktioniert alles wie ein Zauber.

Ich hatte auch dieses Problem. Durch das Aufrufen pip install <package_name>aus dem /binVerzeichnis in meiner virtuellen Python 3.3-Umgebung auf meinem Mavericks Mac wurde das Python-Paket im Verzeichnis der globalen Python 2.7-Site-Pakete installiert. Dies trotz der Tatsache, dass mein $ PATH mit dem Verzeichnis begann, das enthält pip. Seltsam. Dies ist unter CentOS nicht der Fall. Für mich rief die Lösung pip3statt pip. Als ich installiert hatte Pip innerhalb der virtuellen Umgebung über ez_setup , drei „Pip“ Executables im installiert worden war /binVerzeichnis - pip, pip3und pip3.3. Seltsamerweise waren alle drei Dateien genau gleich. Berufungpip3 install <package_name>Das Python-Paket wurde korrekt im lokalen Site-Packages-Verzeichnis installiert. Das Aufrufen pipmit dem vollständigen Pfadnamen in die virtuelle Umgebung funktionierte ebenfalls ordnungsgemäß. Es würde mich interessieren, warum mein Mac $ PATH nicht so verwendet, wie ich es erwarten würde.

Als Erstes muss überprüft werden, zu welchem ​​Standort pip aufgelöst wird:

which pip

Wenn Sie sich in einer virtuellen Umgebung befinden, würden Sie erwarten, dass dies Ihnen Folgendes bietet:

/path/to/virtualenv/.name_of_virtualenv/bin/pip

Es kann jedoch vorkommen, dass es aus irgendeinem Grund in Ihrem System-Pip aufgelöst wird. Zum Beispiel können Sie dies in Ihrer virtuellen Umgebung sehen (das ist schlecht):

/ usr / local / bin / pip (oder alles, was sich nicht in Ihrem virtuellen Pfad befindet).

Um dies zu lösen, überprüfen Sie Ihre pipconfig in:

~/.pipconf
~/.conf/pip
/etc/pip.conf

und stellen Sie sicher, dass nichts Ihren Python-Pfad oder Ihren Pip-Pfad zwingt (dies hat es für mich behoben).

Versuchen Sie dann, ein neues Terminal zu starten und Ihre virtuelle Umgebung neu zu erstellen (löschen und dann erneut erstellen).

Ich bin auf dasselbe Problem gestoßen, als ich ein Python-Paket aus einer virtuellen Umgebung heraus installiert habe. Die Grundursache in meinem Fall war anders. Aus der virtuellen Umgebung heraus habe ich (aus Gewohnheit unter Ubuntu) Folgendes getan:

sudo easy_install -Z <package>

Dies führte dazu, dass der bin / pip-Shebang ignoriert wurde und das nicht virtuelle Python des Roots verwendet wurde, um ihn in den globalen Site-Paketen zu installieren. Da wir eine virtuelle Umgebung haben, sollten wir das Paket ohne "sudo" installieren.

Ich bin auf das gleiche Problem gestoßen, als ich Manjaro laufen ließ. Ich habe die virtuelle Umgebung mit erstellt python3 -m ven venvund dann mit aktiviert source venv/bin/actiave. which pythonund which pipbeide zeigten auf die richtigen Binärdateien in der virtuellen Umgebung, jedoch konnte ich nicht auf der virtuellen Umgebung installieren, selbst wenn der vollständige Pfad der Binärdateien verwendet wurde. Es stellte sich heraus, dass bei der Deinstallation des Python-Pip-Pakets mit sudo pacman -R python-pip python-reportlab(musste Reportlab enthalten, um Abhängigkeiten zu erfüllen) alles wie erwartet funktionierte. Ich weiß nicht warum, aber dies ist wahrscheinlich auf eine doppelte Installation zurückzuführen, bei der das Systempaket Vorrang hat.

Ich hatte ein ähnliches Problem nach dem Update auf pip==8.0.0. Musste auf das Debuggen von Pip zurückgreifen, um den schlechten Weg aufzuspüren.

Wie sich herausstellte, hatte mein Profilverzeichnis eine distutils-Konfigurationsdatei mit einigen leeren Pfadwerten. Dies führte dazu, dass alle Pakete im selben Stammverzeichnis anstelle der entsprechenden virtuellen Umgebung installiert wurden (in meinem Fall /lib/site-packages).

Ich bin nicht sicher, wie die Konfigurationsdatei dort ankam oder wie sie leere Werte hatte, aber sie begann nach dem Update von pip.

Falls jemand anderes auf dasselbe Problem ~/.pydistutils.cfgstößt, wurde das Problem in meiner Umgebung durch einfaches Löschen der Datei (oder Entfernen des leeren Konfigurationspfads) behoben, da pip zur verteilten Standardkonfiguration zurückkehrte.

Gehen Sie in Ihrer virtuellen Umgebung zum bin-Verzeichnis und schreiben Sie wie folgt:

./pip3 install <package-name>

Ich hatte das gleiche Problem auf Macos mit Python 2 und 3 installiert.

Außerdem hatte ich Aliase, um auf Python3 und Pip3 in meinem zu verweisen .bash_profile.

alias python=/usr/local/bin/python3
alias pip=/usr/local/bin/pip3

Das Entfernen von Aliasen und das Neuerstellen der virtuellen Umgebung mithilfe python3 -m venv venvdes Problems wurde behoben.

Kam heute über das gleiche Problem. Ich habe pip einfach global mit sudo easy_install pip(OSX / Max) neu installiert und dann meine virtuelle Umgebung mit erneut erstellt sudo virtualenv nameOfVEnv. Nach dem Aktivieren der neuen virtuellen Umgebung funktionierte der pipBefehl wie erwartet.

Ich glaube nicht, dass ich bei sudoder ersten Erstellung von virtualenv verwendet habe, und das war möglicherweise der Grund dafür pip, dass ich innerhalb von virtualenv keinen Zugriff hatte. Ich konnte pip2vor diesem Fix Zugriff darauf erhalten, obwohl dies seltsam war.

Hier sind einige Vorgehensweisen, mit denen Kopfschmerzen bei der Verwendung virtueller Umgebungen vermieden werden können:

• Erstellen Sie einen Ordner für Ihre Projekte.
• Erstellen Sie Ihre Virtualenv- Projekte in diesem Ordner.
• Verwenden Sie nach dem Aktivieren der Umgebung Ihres Projekts niemals das " sudo pip install package ".
• Deaktivieren Sie nach Beendigung Ihrer Arbeit immer Ihre Umgebung.
• Vermeiden Sie das Umbenennen Ihres Projektordners.

Zur besseren Darstellung dieser Praktiken finden Sie hier eine Simulation:

Erstellen eines Ordners für Ihre Projekte / Umgebungen

$ mkdir venv

Umgebung schaffen

$ cd venv/ 

$ virtualenv google_drive
New python executable in google_drive/bin/python
Installing setuptools, pip...done.

Umgebung aktivieren

$ source google_drive/bin/activate

Pakete installieren

(google_drive) $ pip install PyDrive
Downloading/unpacking PyDrive
Downloading PyDrive-1.3.1-py2-none-any.whl
...
...
...    
Successfully installed PyDrive PyYAML google-api-python-client oauth2client six uritemplate httplib2 pyasn1 rsa pyasn1-modules
Cleaning up...

Paket in der Umgebung verfügbar

(google_drive) $ python
Python 2.7.6 (default, Oct 26 2016, 20:30:19) 
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import pydrive.auth
>>>  
>>> gdrive = pydrive.auth.GoogleAuth()
>>>

Umgebung deaktivieren

(google_drive) $ deactivate 

$ 

Paket außerhalb der Umgebung NICHT VERFÜGBAR

(google_drive) $ python
Python 2.7.6 (default, Oct 26 2016, 20:32:10) 
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import pydrive.auth
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named pydrive.auth
>>> 

Anmerkungen:

Warum nicht Sudo?

Virtualenv erstellt eine völlig neue Umgebung für Sie und definiert $ PATH und einige andere Variablen und Einstellungen. Wenn Sie das sudo pip-Installationspaket verwenden , führen Sie Virtualenv als Root aus , verlassen die gesamte erstellte Umgebung und installieren das Paket dann auf globalen Site-Paketen und nicht in dem Projektordner, in dem Sie eine virtuelle Umgebung haben, obwohl Sie haben die Umgebung aktiviert.

Wenn Sie den Ordner Ihres Projekts umbenennen (wie in der akzeptierten Antwort angegeben) ...

... müssen Sie einige Variablen aus einigen Dateien im bin- Verzeichnis Ihres Projekts anpassen .

Beispielsweise:

bin / pip, Zeile 1 (She Bang)

bin / aktivieren, Zeile 42 (VIRTUAL_ENV)

Ich hatte dieses Problem. Es stellte sich heraus, dass in einem meiner Ordnernamen ein Leerzeichen vorhanden war, das das Problem verursachte. Ich entfernte den Raum, löschte ihn und stellte ihn mit venv wieder her, und alles war gut.

Dieses Problem tritt auf, wenn Sie eine virtuelle Env-Instanz erstellen und dann den Namen des übergeordneten Ordners ändern.

Keine der oben genannten Lösungen hat bei mir funktioniert.

Mein Venv war aktiv. pip -Vund which pipgab mir den richtigen virtuellen Pfad, aber als ich pip installPakete mit aktiviertem venv -ed, pip freezeblieb mein leer.

Alle Umgebungsvariablen waren auch korrekt.

Schließlich habe ich gerade pip geändert und virtualenv entfernt:

easy_install pip==7.0.2

pip install pip==10

sudo pip uninstall virtualenv

Venv neu installieren:

sudo pip install virtualenv

Erstellen Sie venv:

python -m virtualenv venv_name_here

Und alle Pakete wieder korrekt in meinem Venv installiert.

Versuchen Sie nach dem Erstellen einer virtuellen Umgebung, pip in yourVirtualEnvName \ Scripts zu verwenden

Es sollte ein Paket in Lib \ site-packages in Ihrer virtuellen Umgebung installieren

Ich hatte auch dieses Problem. Durch das Aufrufen wurden sudo pip installPython-Pakete im globalen Verzeichnis der Site-Pakete installiert, und das Aufrufen pip installfunktionierte einwandfrei . Also kein sudo in virtualenv verwenden.

Dasselbe Problem. Python3.5 und Pip 8.0.2 wurden unter Linux installiert rpm.

Ich habe keine Hauptursache gefunden und kann keine richtige Antwort geben. Es sieht so aus, als gäbe es mehrere mögliche Ursachen.

Ich hoffe jedoch, dass ich helfen kann, meine Beobachtungen und eine Problemumgehung mitzuteilen.

1. pyvenv mit --system-site-packages

   • ./binenthält nicht pip, pipist aus System-Site-Paketen verfügbar
   • Pakete werden global installiert ( BUG? )

2. pyvenv ohne --system-site-packages

   • pipwird installiert ./bin, aber es ist eine andere Version (von ensurepip)
   • Pakete werden in der virtuellen Umgebung installiert ( OK )

Offensichtliche Abhilfe für pyvenvmit --system-site-packages:

• Erstellen Sie es ohne die --system-site-packagesOption
• include-system-site-packages = falsein truein pyvenv.cfgDatei ändern

Es lohnt sich auch zu überprüfen, ob Sie den Pfad zu Ihrer virtuellen Umgebung nicht geändert haben.

In diesem Fall hätte die erste Zeile in bin/pip(und der Rest der ausführbaren Dateien) einen falschen Pfad.

Sie können diese Dateien entweder bearbeiten und den Pfad korrigieren oder die virtuelle Umgebung entfernen und erneut installieren.

Für Python 3er

Versuchen Sie zu aktualisieren. Ich hatte genau das gleiche Problem und versuchte die Antwort von Chases, jedoch ohne Erfolg. Der schnellste Weg, dies zu überarbeiten, besteht darin, wenn möglich Ihre Python Minor / Patch-Version zu aktualisieren. Ich habe festgestellt, dass ich 3.5.1 ausgeführt und auf 3.5.2 aktualisiert habe. Pyvenv funktioniert wieder.

Dies ist mir passiert, als ich die virtuelle Umgebung am falschen Ort erstellt habe. Ich dachte dann, ich könnte das Verzeichnis an einen anderen Ort verschieben, ohne dass es etwas ausmacht. Es war wichtig.

mkdir ~/projects
virtualenv myenv
cd myenv
git clone [my repository]

Oh Mist, ich habe vergessen, eine CD zu projectserstellen, bevor ich die virtuelle Umgebung erstellt und den Repräsentanten geklont habe. Na ja, ich bin zu faul, um zu zerstören und neu zu erschaffen. Ich werde einfach das Verzeichnis ohne Probleme verschieben.

cd ~
mv myenv projects
cd projects/myenv/myrepo
pip install -r requirements

Nein, will mehr Berechtigungen, was zum? Ich fand es seltsam, aber SUDO AWAY! Anschließend wurden die Pakete an einem globalen Speicherort installiert.

Die Lektion, die ich gelernt habe, war, einfach das Verzeichnis virtualenv zu löschen. Beweg es nicht.

Hatte dieses Problem nach der Installation von Divio: Es hatte meinen PATH oder meine Umgebung in irgendeiner Weise geändert, als es ein Terminal startete.

Die Lösung in diesem Fall bestand darin, nur das zu tun, source ~/.bash_profilewas bereits eingerichtet sein sollte, um Sie zu Ihrem ursprünglichen pyenv / pyenv-virtualenv-Zustand zurückzubringen.

Es ist mir passiert, als ich virtualenv mit --python=python3.6flag installiert habe, aber danach versucht habe, es zu verwenden pip2 install.
Durch das Erstellen von virtualenv mit dem Flag der von Ihnen verwendeten Version werden Berechtigungsprobleme behoben. Zum Überprüfen versuchen which pipoder which pip2oder which pip3(abhängig von Ihrer Wahl). Wenn einer, den pipSie verwenden, den Pfad nicht venvhierher zeigt, ist dies Ihr Problem.

Irgendwie eine setup.cfg-Datei mit dem Präfix = "" im Projektordner

Das Ausführen der Pip-Installation auf der virtuellen Umgebung außerhalb des Projektordners funktionierte so, dass Pip von innen angewiesen wurde, ein leeres Präfix zu verwenden, das standardmäßig "/" lautet.

Durch Entfernen der Datei wurde das Problem behoben

Ich hatte dieses Problem und nachdem ich alle oben genannten Lösungen ausprobiert hatte, entfernte ich einfach alles und fing von vorne an.

In meinem Fall habe ich sudoeinen der Ordner erstellt, in denen die virtuelle Umgebung vorhanden war, und sudo hat die Berechtigungen an root vergeben

Ich war sehr sauer! Aber es hat funktioniert!

Ich muss aus irgendeinem Grund 'sudo' verwenden, um Pakete über pip auf meinem Ubuntu-System zu installieren. Dies führt dazu, dass die Pakete in globalen Site-Paketen installiert werden. Stellen Sie dies hier für alle bereit, die in Zukunft mit diesem Problem konfrontiert sein könnten.

Ich hatte genau das Problem aus dem Titel und habe es gelöst. Pip begann mit der Installation in den venv-Site-Paketen, nachdem ich meinen PATH bereinigt hatte: Er hatte am Anfang einen Pfad zu meinem lokalen ~ / bin-Verzeichnis.

Also, mein Rat: Überprüfen Sie Ihre Umgebungsvariablen gründlich auf "Müll" oder andere nicht standardmäßige Dinge. Leider kann virtualenv für diese empfindlich sein.

Viel Glück!

Die kurze Antwort lautet Command virtualenv mit dem Parameter "—no-site-packages".

Lange Antwort mit Erklärung: -

Nachdem ich hier und da gelaufen war und viele Themen durchgearbeitet hatte, fand ich selbst das Problem. Die obigen Antworten haben die Idee gegeben, aber ich möchte noch einmal alles durchgehen.

• Das Problem ist, dass selbst wenn Sie die Umgebung aktivieren, diese sich auf die Systemumgebung bezieht, da wir die virtuelle Umgebung erstellt haben.

• Wenn wir den Befehl virtualenv env -p python3 ausführen , wird virtualenv installiert, es wird jedoch kein no-global-site-packages.txt erstellt.

• Aus diesem Grund wird beim Aktivieren der Umgebung mit dem Befehl zur Aktivierung der Quelle dort diese Datei mit dem Namen site.py (Name kann unterschiedlich sein, ich habe es nur vergessen) ausgeführt, die überprüft, ob diese Datei nicht vorhanden ist, und Ihren env-Pfad nicht zu sys.path hinzufügt und verwenden Sie System Python.

• Um dieses Problem zu beheben, führen Sie virtualenv einfach mit einem zusätzlichen Parameter aus: no-site-packages. Diese Datei wird erstellt. Wenn Sie die Umgebung aktivieren, wird Ihr benutzerdefinierter Umgebungspfad in Ihre PATH-Variable eingefügt, sodass Sie darauf zugreifen können.

Viele gute Diskussionen oben, aber es wurden virtuelle Beispiele verwendet. Da 'conda' jetzt das empfohlene Tool zum Verwalten von virtualenv ist, habe ich die Schritte zum Ausführen von pip in conda env wie folgt zusammengefasst.

Ich werde py36r als Namen der Umgebung verwenden und / opt / conda / envs ist das Präfix der Umgebung):

$ source /opt/conda/etc/profile.d/conda.sh # skip if already done 
$ conda activate py36r
$ pip  install pkg_xyz
$ pip  list | grep pkg_xyz

Beachten Sie, dass der ausgeführte Pip in /opt/conda/envs/py36r/bin/pip(nicht /opt/conda/bin/pip) sein sollte.

Alternativ können Sie einfach Folgendes ausführen, ohne die Konda zu aktivieren

$ /opt/conda/envs/py36r/bin/pip

Wenn Sie mit conda installieren, können Sie auch ohne Aktivierung installieren:

$ conda install -n py36r pkg_abc ...

FENSTER

Für mich war die Lösung nicht zu verwenden mkvirtualenv, aber:

python -m venv path/to/your/virtualenv

Workon funktioniert korrekt.

while in virtualenv: pip -VZeigt den Pfad von virtualenv zu pip an