pip-Installation in globalen Site-Paketen statt in virtualenv

Für mich war dies kein Pip- oder Virtualenv-Problem. Es war ein Pythonproblem. Ich hatte meinen $ PYTHONPATH manuell in ~/.bash_profile (oder ~/.bashrc) eingestellt, nachdem ich ein paar Online-Tutorials verfolgt hatte. Dieses manuell gesetzte $ PYTHONPATH war in der virtuellen Umgebung verfügbar, da es wahrscheinlich erlaubt sein sollte.

Außerdem fügte add2virtualenv meinen Projektpfad aus irgendeinem Grund nicht in meinen $ PYTHONPATH ein.

Nur einige Gabelpfade für diejenigen, die noch feststecken können! Prost!

Ich hatte das gleiche Problem, ich habe es gelöst, indem ich das venv-Verzeichnis entfernt und es neu erstellt habe!

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. Das Aufrufen von pip install <package_name> aus dem Verzeichnis /bin in meiner virtuellen Umgebung von Python 3.3 auf meinem Mavericks Mac führte dazu, dass das Python-Paket im globalen Verzeichnis der Python 2.7-Site-Pakete installiert wurde. Dies war trotz der Tatsache, dass mein $ PATH mit dem Verzeichnis begann, das pip enthielt. Seltsam. Dies passiert nicht bei CentOS. Für mich rief die Lösung pip3 anstelle von pip auf. Als ich pip in der virtuellen Umgebung über ez_setup installiert hatte, waren drei ausführbare "pip" -Dateien im /bin-Verzeichnis installiert - pip, pip3 und pip3.3. Seltsamerweise waren alle drei Dateien genau gleich. Durch den Aufruf von pip3 install <package_name> wurde das Python-Paket ordnungsgemäß im lokalen Site-Packages-Verzeichnis installiert. Das Aufrufen von pip mit dem vollständigen Pfadnamen in der virtuellen Umgebung funktionierte ebenfalls einwandfrei. Ich würde gerne wissen, warum mein Mac $ PATH nicht so nutzt, wie ich es erwartet hätte.

Ich bin auf das gleiche Problem gestoßen, als ich ein Python-Paket aus einer virtualenv . Installierte. Die Hauptursache in meinem Fall war anders . Innerhalb der virtualenv war ich (aus Ubungs Gewohnheit heraus):

Sudo easy_install -Z <package>

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

Ich hatte ein ähnliches Problem nach dem Update auf pip==8.0.0. Musste auf das Debugging Pip zurückgreifen, um den schlechten Pfad zu finden.

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

Ich bin mir nicht sicher, wie die config-Datei dorthin gekommen ist oder wie sie leere Werte hatte, aber sie begann nach dem Aktualisieren von pip.

Für den Fall, dass jemand anderes auf dieses Problem stößt, wurde durch das Löschen der Datei ~/.pydistutils.cfg (oder das Entfernen des leeren Konfigurationspfads) das Problem in meiner Umgebung behoben, da pip wieder in die standardmäßige verteilte Konfiguration zurückkehrte.

Das erste, was Sie überprüfen müssen, ist, an welchem ​​Ort pip sich auflöst:

which pip

wenn Sie sich in einer virtuellen Umgebung befinden, würden Sie davon ausgehen, dass Sie so etwas wie:

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

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

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

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

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

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 virtualenv neu zu erstellen (löschen und erneut erstellen).

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

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

Keine der oben genannten Lösungen funktionierte für mich. 

Mein Vater war aktiv. pip -V und which pip gaben mir den korrekten virtualenv-Pfad, aber als ich pip install- Pakete mit aktiviertem vv-Code __- __- __- änderte, blieb mein pip freeze 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

Installieren Sie venv neu:

Sudo pip install virtualenv

Erstellen Sie venv:

python -m virtualenv venv_name_here

Und alle Pakete wieder korrekt in meinem venv installiert.

Kam heute durch dieselbe Ausgabe. Ich habe pip global einfach mit Sudo easy_install pip (OSX/Max) neu installiert und dann mit Sudo virtualenv nameOfVEnv meine virtualenv erneut erstellt. Nach der Aktivierung der neuen Virtualenv funktionierte der Befehl pip wie erwartet.

Ich glaube nicht, dass ich Sudo bei der ersten virtualenv-Erstellung verwendet habe, und dies war möglicherweise der Grund dafür, dass ich aus der virtualenv keinen Zugriff auf pip hatte. Ich konnte vor diesem Update auf pip2 zugreifen, was ungerade war.

Hier sind einige Vorgehensweisen, die bei der Verwendung von virtuellen Umgebungen Kopfschmerzen vermeiden können:

• Erstellen Sie einen Ordner für Ihre Projekte.
• Erstellen Sie Ihre Virtualenv -Projekte in diesem Ordner. 
• Verwenden Sie nach der Aktivierung der Umgebung Ihres Projekts niemals " Sudo pip install package".
• Nach Beendigung Ihrer Arbeit " deaktivieren Sie " immer Ihre Umgebung.
• Vermeiden Sie, Ihren Projektordner umzubenennen.

Zur besseren Darstellung dieser Praktiken ist hier eine Simulation dargestellt:

erstellen eines Ordners für Ihre Projekte/Umgebungen

$ mkdir venv

umwelt schaffen

$ cd venv/ 

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

aktivierende Umgebung

$ 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 innerhalb 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 NICHT VERFÜGBAR außerhalb der Umgebung

(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 für Sie eine völlig neue Umgebung, die $ PATH und einige andere Variablen und Einstellungen definiert. Wenn Sie Sudo pip install package verwenden, führen Sie Virtualenv als root aus. Es entgeht der gesamten Umgebung, die erstellt wurde, und installiert das Paket dann auf globalen Site-Paketen und nicht im Projekt Ordner wo Sie eine virtuelle Umgebung haben, obwohl Sie die Umgebung aktiviert haben.

Wenn Sie den Ordner Ihres Projekts umbenennen (wie in der akzeptierten Antwort erwähnt) ...

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

Zum Beispiel:

bin/pip, Linie 1 (She Bang)

bin/enable, Zeile 42 (VIRTUAL_ENV)

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

Ich hatte dieses Problem. Es stellte sich heraus, dass sich in einem meiner Ordnernamen ein Platz befand, der das Problem verursachte. Ich habe den Platz entfernt, gelöscht und mit venv wieder hergestellt, und alles war gut. 

Viele gute Diskussionen darüber, 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 für die env verwenden, und/opt/conda/envs ist das Präfix für die envs):

$ source /opt/conda/etc/profile.d/conda.sh # überspringen, falls bereits geschehen

$ conda aktiviere py36r

$ pip install pkg_xyz

$ pip Liste | grep pkg_xyz

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

Alternativ können Sie einfach folgendes ausführen, ohne conda zu aktivieren

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

Wenn Sie mit conda installieren, können Sie auch installieren, ohne Folgendes zu aktivieren:

$ conda install -n py36r pkg_abc ...

Es ist mir passiert, als ich virtualenv mit --python=python3.6 flag installierte, aber danach versuchte, pip2 install zu verwenden.
Das Erstellen von virtualenv mit dem Flag der Version, die Sie verwenden, löst Berechtigungsprobleme. Um dies zu überprüfen, versuchen Sie which pip oder which pip2 oder which pip3 (abhängig von Ihrer Wahl). Wenn eine pip den Pfad nicht zu venv zeigt, ist hier Ihr Problem. 

Ich muss aus irgendeinem Grund "Sudo" für die Installation von Paketen über pip auf meinem Ubuntu-System verwenden. Dies führt dazu, dass die Pakete in globalen Site-Paketen installiert werden. Setzen Sie dies hier für alle ein, die in Zukunft möglicherweise mit diesem Problem konfrontiert sind.

Ich hatte auch dieses Problem. Das Aufrufen von Sudo pip install führte dazu, dass Python-Pakete im globalen Verzeichnis der Site-Packages installiert wurden, und pip install funktionierte einfach einwandfrei . Daher sollte Sudo in virtualenv nicht verwendet werden.

Hatte dieses Problem nach der Installation von Divio: Es hatte meinen PATH oder meine Umgebung in gewisser Weise geändert, da ein Terminal gestartet wurde. 

Die Lösung in diesem Fall war, source ~/.bash_profile zu tun, der bereits eingerichtet sein sollte, um den ursprünglichen pyenv/pyenv-virtualenv-Status wiederherzustellen.

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

Also, mein Rat: Überprüfen Sie Ihre Umgebungsvariablen gründlich auf "Müll" oder andere Dinge, die nicht dem Standard entsprechen. Leider kann virtualenv empfindlich auf diese reagieren.

Viel Glück!

Ich hatte dieses Problem und nachdem ich die obige Lösung ausprobiert hatte, entfernte ich einfach alles und begann von vorne.

In meinem eigenen Fall habe ich Sudo verwendet, um einen der Ordner zu erstellen, in dem sich die virtuelle Umgebung befand, und Sudo gibt die Berechtigungen an root weiter

Ich war sehr sauer! Aber es hat funktioniert!

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

das Ausführen von pip install auf der virtualenv außerhalb des Projektordners funktionierte, so dass es pip von innen her sagte, ein leeres Präfix zu verwenden, das standardmäßig "/"

entfernen der Datei behoben

Gehen Sie in das bin-Verzeichnis in Ihrer virtuellen Umgebung und schreiben Sie so

./pip3 install <package-name>

Für Python 3ers

Versuchen Sie zu aktualisieren. Ich hatte genau das gleiche Problem und versuchte die Antwort von Chases, jedoch kein Erfolg. Der schnellste Weg, dies zu ändern, ist die Aktualisierung Ihrer Python Minor/Patch-Version, falls möglich. Mir ist aufgefallen, dass ich 3.5.1 ausgeführt und auf 3.5.2 aktualisiert habe. Pyvenv arbeitet wieder.

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

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

Oh Mist, ich habe vergessen, in projects zu cd, bevor ich die virtualenv erstellt und die Wiederholung klonierte. Na ja, ich bin zu faul um zu zerstören und neu zu erschaffen. Ich werde das Verzeichnis ohne Probleme verschieben.

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

Nö, will mehr Berechtigungen, was die? Ich fand es seltsam aber Sudo WEG! Anschließend wurden die Pakete an einem globalen Speicherort installiert.

Die Lektion, die ich gelernt habe, war, einfach das virtuelle Verzeichnis zu löschen. Bewegen Sie es nicht.

Dasselbe Problem. Python3.5 und pip 8.0.2 werden von Linux rpm installiert.

Ich habe keine Hauptursache gefunden und kann keine richtige Antwort geben. Anscheinend gibt es mehrere mögliche Ursachen.

Ich hoffe jedoch, dass ich helfen kann, meine Beobachtungen und einen Workaround zu teilen.

1. pyvenv mit --system-site-packages

   • ./bin enthält keine pip, pip ist in System-Site-Paketen verfügbar
   • pakete werden global installiert ( BUG? )

2. pyvenv ohne --system-site-packages

   • pip wird in ./bin installiert, es ist jedoch eine andere Version (von ensurepip)
   • pakete werden in der virtuellen Umgebung installiert (OK)

Offensichtliche Problemumgehung für pyvenv mit --system-site-packages:

• erstellen Sie es ohne die --system-site-packages-Option
• Ändern Sie include-system-site-packages = false in true in pyvenv.cfg-Datei

Es lohnt sich auch zu überprüfen, dass 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 virtualenv entfernen und erneut installieren.