pip installazione in pacchetti del sito globale invece di virtualenv

L'utilizzo di pip3per installare un pacchetto in a virtualenvcausa l'installazione del pacchetto nella cartella globale dei pacchetti del sito anziché in quella nella cartella virtualenv. Ecco come ho configurato Python3 e virtualenv su OS X Mavericks (10.9.1):

Ho installato Python3 usando Homebrew:

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

Modificata la $PATHvariabile in .bash_profile; aggiunta la seguente riga:

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

L'esecuzione di which python3ritorni /usr/local/bin/python3(dopo il riavvio della shell).

Nota: which python3ritorna ancora / usr/bin/pythonsebbene.

Installato virtualenvutilizzando pip3:

pip3 install virtualenv

Quindi, creane uno nuovo virtualenve attivalo:

virtualenv testpy3 -p python3
cd testpy3
source bin/activate

Nota: se non specifichi -p python3, pip mancherà dalla cartella bin nel virtualenv.

In esecuzione which piped which pip3entrambi restituiscono la cartella virtualenv:

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

Ora, quando provo a installare, ad esempio, Markdown usando pip nel virtualenv attivato, pip verrà installato nella cartella globale dei pacchetti del sito invece che nella cartella dei pacchetti del sito di virtualenv.

pip install markdown

pip listRitorni correnti :

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

Contenuto di /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/

Contenuto di /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/

Come puoi vedere, la cartella globale dei pacchetti del sito contiene Markdown, la cartella virtualenv no.

Nota: avevo installato Python2 e Python3 su una VM diversa (ho seguito queste istruzioni) e ho avuto lo stesso problema con Python3; l'installazione di pacchetti in un virtualenv basato su Python2 ha funzionato senza problemi.

Eventuali suggerimenti, suggerimenti, ... sarebbero molto apprezzati.

Buffo che tu ne abbia parlato, ho avuto lo stesso identico problema. Alla fine l'ho risolto, ma non sono ancora sicuro di cosa l'abbia causato.

Prova a controllare i tuoi script bin/pipe bin/activate. In bin/pip, sguardo alla baracca. È corretto? In caso contrario, correggilo. Quindi in linea ~ 42nel tuo bin/activate, controlla se il tuo percorso virtualenv è corretto. Assomiglierà a questo

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

Se è sbagliato, correggilo deactivate, quindi . bin/activate, e se il nostro problema comune avesse la stessa causa, dovrebbe funzionare. Se ancora non funziona, sei sulla strada giusta, comunque. Ho seguito la stessa routine di risoluzione dei problemi che hai fatto tu, which pipripetutamente, seguendo la traccia dello stack, ecc.

Assicurati assolutamente che

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

è quello che vuoi, e non si riferisce a un altro progetto di test con lo stesso nome (ho avuto quel problema e non ho idea di come sia iniziato. Il mio sospetto è che stia eseguendo più virtualenv contemporaneamente).

Se niente di tutto questo funziona, una soluzione temporanea potrebbe essere, come ha detto Joe Holloway,

Basta eseguire il pip di virtualenv con il suo percorso completo (cioè non fare affidamento sulla ricerca del percorso eseguibile) e non è nemmeno necessario attivare l'ambiente. Farà la cosa giusta.

Forse non è l'ideale, ma dovrebbe funzionare in un pizzico.

Link alla mia domanda originale:

VirtualEnv / Pip tenta di installare pacchetti a livello globale

Per me questo non era un problema pip o virtualenv. Era un problema con Python. Avevo impostato manualmente il mio $ PYTHONPATH in ~ / .bash_profile (o ~ / .bashrc) dopo aver seguito alcuni tutorial online. Questo $ PYTHONPATH impostato manualmente era disponibile in virtualenv come probabilmente dovrebbe essere consentito.

Inoltre add2virtualenvnon aggiungevo il percorso del mio progetto al mio $ PYTHONPATH per qualche motivo all'interno di virtualenv.

Solo qualche bivio per chi potrebbe essere ancora bloccato! Saluti!

Ho avuto lo stesso problema, l'ho risolto rimuovendo la directory venv e ricreandola!

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

Ora tutto funziona come un incantesimo.

Anch'io ho avuto questo problema. La chiamata pip install <package_name>dalla /bindirectory all'interno del mio ambiente virtuale Python 3.3 sul mio Mac Mavericks ha causato l'installazione del pacchetto Python nella directory dei pacchetti del sito globale Python 2.7. Questo nonostante il fatto che il mio $ PATH sia iniziato con la directory contenente pip. Strano. Questo non accade su CentOS. Per me, la soluzione era chiamare pip3invece di pip. Quando avevo installato pip all'interno dell'ambiente virtuale tramite ez_setup , tre eseguibili "PIP" erano stati installati nella /bindirectory - pip, pip3e pip3.3. Curiosamente, tutti e tre i file erano esattamente gli stessi. Chiamandopip3 install <package_name>ha causato l'installazione corretta del pacchetto Python nella directory dei pacchetti del sito locale. Anche la chiamatapipcon il percorso completo nell'ambiente virtuale ha funzionato correttamente. Sarei interessato a sapere perché il mio Mac non utilizza $ PATH nel modo in cui mi aspetterei.

La prima cosa da verificare è in quale posizione si sta risolvendo pip:

which pip

se sei in un virtualenv ti aspetteresti che questo ti dia qualcosa del tipo:

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

Tuttavia potrebbe essere il caso che si sta risolvendo sul tuo pip di sistema per qualche motivo. Ad esempio potresti vederlo dall'interno del tuo virtualenv (questo è un male):

/ usr / local / bin / pip (o qualsiasi cosa che non sia nel tuo percorso virtualenv).

Per risolvere questo problema controlla il tuo pipconfig in:

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

e assicurati che non ci sia nulla che stia forzando il tuo percorso Python o il tuo percorso pip (questo lo ha risolto per me).

Quindi prova ad avviare un nuovo terminale e ricostruisci il tuo virtualenv (elimina e crea di nuovo)

Ho riscontrato lo stesso problema durante l'installazione di un pacchetto python da un virtualenv. La causa principale nel mio caso era diversa. Dall'interno di virtualenv, stavo (per abitudine su Ubuntu), facendo:

sudo easy_install -Z <package>

Ciò ha fatto sì che bin / pip shebang venisse ignorato e ha utilizzato il python non virtualenv di root per installarlo nei pacchetti globali del sito. Dato che abbiamo un ambiente virtuale, dovremmo installare il pacchetto senza "sudo"

Mi sono imbattuto nello stesso problema eseguendo Manjaro. Ho creato l'ambiente virtuale usando python3 -m ven venve poi attivato usando source venv/bin/actiave. which pythoned which pipentrambi indicavano i binari corretti in virtualenv, tuttavia non sono stato in grado di installarli in virtualenv, anche quando si utilizzava il percorso completo dei binari. Si è scoperto che quando ho disinstallato il pacchetto python-pip con sudo pacman -R python-pip python-reportlab(dovevo includere reportlab per soddisfare le dipendenze) tutto ha iniziato a funzionare come previsto. Non sono sicuro del perché, ma probabilmente ciò è dovuto a una doppia installazione in cui il pacchetto di sistema ha la precedenza.

Ho avuto un problema simile dopo l'aggiornamento a pip==8.0.0. Ho dovuto ricorrere al debug di pip per tracciare il percorso errato.

A quanto pare, la directory del mio profilo aveva un file di configurazione distutils con alcuni valori di percorso vuoti. Ciò causava l'installazione di tutti i pacchetti nella stessa directory principale anziché nell'ambiente virtuale appropriato (nel mio caso /lib/site-packages).

Non sono sicuro di come sia arrivato il file di configurazione o di come avesse valori vuoti, ma è iniziato dopo l'aggiornamento di pip.

Nel caso in cui qualcun altro si imbattesse in questo stesso problema, la semplice eliminazione del file ~/.pydistutils.cfg(o la rimozione del percorso di configurazione vuoto) ha risolto il problema nel mio ambiente perché pip è tornato alla configurazione distribuita predefinita.

Vai alla directory bin nel tuo ambiente virtuale e scrivi in ​​questo modo:

./pip3 install <package-name>

Ho avuto lo stesso problema su macos con python 2 e 3 installati.

Inoltre, avevo alias che puntassero a python3 e pip3 nel mio file .bash_profile.

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

La rimozione degli alias e la ricreazione di un ambiente virtuale utilizzando hanno python3 -m venv venvrisolto il problema.

Oggi mi sono imbattuto nello stesso problema. Ho semplicemente reinstallato pip a livello globale con sudo easy_install pip(OSX / Max), quindi ho creato di nuovo il mio virtualenv con sudo virtualenv nameOfVEnv. Quindi, dopo aver attivato il nuovo virtualenv, il pipcomando ha funzionato come previsto.

Non penso di aver usato sudola prima creazione di virtualenv e questo potrebbe essere stato il motivo per cui non ho avuto accesso pipdall'interno di virtualenv, sono stato in grado di accedere a pip2prima di questa correzione, il che era strano.

Ecco alcune pratiche che potrebbero evitare mal di testa durante l'utilizzo di ambienti virtuali:

• Crea una cartella per i tuoi progetti.
• Crea i tuoi progetti Virtualenv all'interno di questa cartella.
• Dopo aver attivato l'ambiente del progetto, non utilizzare mai " sudo pip install package ".
• Dopo aver terminato il tuo lavoro, " disattiva " sempre il tuo ambiente.
• Evita di rinominare la cartella del progetto.

Per una migliore rappresentazione di queste pratiche, ecco una simulazione:

creare una cartella per i tuoi progetti / ambienti

$ mkdir venv

creare ambiente

$ cd venv/ 

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

ambiente di attivazione

$ source google_drive/bin/activate

installazione di pacchetti

(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...

pacchetto disponibile all'interno dell'ambiente

(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()
>>>

disattivare l'ambiente

(google_drive) $ deactivate 

$ 

pacchetto NON DISPONIBILE fuori dall'ambiente

(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
>>> 

Appunti:

Perché non sudo?

Virtualenv crea un ambiente completamente nuovo per te, definendo $ PATH e alcune altre variabili e impostazioni. Quando si utilizza sudo pip install package , si esegue Virtualenv come root , si esegue l' escape dell'intero ambiente che è stato creato e quindi si installa il pacchetto su pacchetti del sito globali e non all'interno della cartella del progetto in cui si dispone di un ambiente virtuale, sebbene hanno attivato l'ambiente.

Se rinomini la cartella del tuo progetto (come menzionato nella risposta accettata) ...

... dovrai modificare alcune variabili da alcuni file all'interno della directory bin del tuo progetto.

Per esempio:

bin / pip, linea 1 (She Bang)

bin / attivare, riga 42 (VIRTUAL_ENV)

Ho avuto questo problema. Si è scoperto che c'era uno spazio in uno dei nomi delle mie cartelle che ha causato il problema. Ho rimosso lo spazio, eliminato e ripristinato utilizzando venv, e tutto è andato bene.

Questo problema si verifica quando si crea un'istanza virtualenv e quindi si modifica il nome della cartella principale.

Nessuna delle soluzioni di cui sopra ha funzionato per me.

Il mio Venv era attivo. pip -Ve which pipmi ha fornito il percorso virtualenv corretto, ma quando ho modificato i pip installpacchetti con venv attivato, il mio è pip freezerimasto vuoto.

Anche tutte le variabili d'ambiente erano corrette.

Infine, ho appena cambiato pip e rimosso virtualenv:

easy_install pip==7.0.2

pip install pip==10

sudo pip uninstall virtualenv

Reinstallare venv:

sudo pip install virtualenv

Crea venv:

python -m virtualenv venv_name_here

E tutti i pacchetti sono stati installati di nuovo correttamente nel mio venv.

Dopo aver creato l'ambiente virtuale, prova a usare pip che si trova in yourVirtualEnvName \ Scripts

Dovrebbe installare un pacchetto all'interno di Lib \ site-packages nel tuo ambiente virtuale

Anch'io ho avuto questo problema. La chiamata ha sudo pip installcausato l'installazione dei pacchetti Python nella directory globale dei pacchetti del sito e la chiamata ha pip installfunzionato bene. Quindi non usare sudo in virtualenv.

Lo stesso problema. Python3.5 e pip 8.0.2 installati da Linux rpm.

Non ho trovato una causa primaria e non posso dare una risposta adeguata. Sembra che le cause possibili siano molteplici.

Tuttavia, spero di poter aiutare a condividere la mia osservazione e una soluzione alternativa.

1. pyvenv con --system-site-packages

   • ./binnon contiene pip, pipè disponibile dai pacchetti del sito di sistema
   • i pacchetti sono installati globalmente ( BUG? )

2. pyvenv senza --system-site-packages

   • pipviene installato ./bin, ma è una versione diversa (da ensurepip)
   • i pacchetti vengono installati nell'ambiente virtuale ( OK )

Soluzione ovvia per pyvenvcon --system-site-packages:

• crearlo senza l' --system-site-packagesopzione
• cambia include-system-site-packages = falsein truenel pyvenv.cfgfile

Vale anche la pena controllare di non aver modificato in qualche modo il percorso del tuo virtualenv.

In tal caso la prima riga in bin/pip(e il resto degli eseguibili) avrebbe un percorso errato.

Puoi modificare questi file e correggere il percorso o rimuovere e installare di nuovo virtualenv.

Per Python 3ers

Prova ad aggiornare. Ho avuto lo stesso identico problema e ho provato la risposta di Chases, ma senza successo. Il modo più rapido per effettuare il refactoring è aggiornare la versione Python Minor / Patch, se possibile. Ho notato che stavo eseguendo 3.5.1 e aggiornato a 3.5.2. Pyvenv funziona ancora una volta.

Questo è successo a me quando ho creato il virtualenv nella posizione sbagliata. Allora ho pensato che avrei potuto spostare la directory in un'altra posizione senza che importasse. Importava.

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

Oh merda, ho dimenticato di entrare in cd projectsprima di creare il virtualenv e clonare il rappresentante. Oh beh, sono troppo pigro per distruggere e ricreare. Mi limiterò a spostare la directory senza problemi.

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

No, vuole più permessi, cosa? Ho pensato che fosse strano ma SUDO AWAY! Quindi ha installato i pacchetti in una posizione globale.

La lezione che ho imparato è stata semplicemente eliminare la directory virtualenv. Non spostarlo.

Ho avuto questo problema dopo aver installato Divio: aveva cambiato il mio PERCORSO o l'ambiente in qualche modo, poiché avviava un terminale.

La soluzione in questo caso era solo quella di fare ciò source ~/.bash_profileche dovrebbe essere già configurato per riportarti allo stato originale pyenv / pyenv-virtualenv.

Mi è successo quando ho installato virtualenv con --python=python3.6flag ma in seguito ho provato a usare pip2 install.
La creazione di virtualenv con il flag della versione che utilizzerai risolve i problemi di autorizzazione. Per controllare, prova which pipo which pip2o which pip3(dipende dalla tua scelta). Se uno di quelli pipche usi mostra il percorso non venvqui è il tuo problema.

In qualche modo un file setup.cfg con un prefisso = "" nella cartella del progetto

l'esecuzione di pip install su virtualenv fuori dalla cartella del progetto ha funzionato così dall'interno diceva a pip di usare un prefisso vuoto che di default è "/"

la rimozione del file lo ha risolto

Ho avuto questo problema e dopo aver provato tutta la soluzione di cui sopra ho rimosso tutto e ricominciato da capo.

Nel mio caso ho usato sudo per creare una delle cartelle in cui esisteva l'ambiente virtuale e sudo ha dato i privilegi di root

Ero molto incazzato! Ma ha funzionato!

Per qualche motivo devo usare "sudo" per installare i pacchetti tramite pip sul mio sistema Ubuntu. Ciò causa l'installazione dei pacchetti nei pacchetti del sito globale. Mettendolo qui per chiunque possa affrontare questo problema in futuro.

Avevo esattamente il problema dal titolo e l'ho risolto. Pip ha iniziato ad installarsi nei pacchetti del sito venv dopo che ho ripulito il mio PATH: all'inizio aveva un percorso per la mia directory ~ / bin locale.

Quindi, il mio consiglio: controlla attentamente le tue variabili d'ambiente per "spazzatura" o cose non standard. Sfortunatamente, virtualenv può essere sensibile a quelli.

In bocca al lupo!

La risposta breve è eseguire Command virtualenv con il parametro "—no-site-packages".

Risposta lunga con spiegazione: -

Quindi, dopo aver corso qua e là, e aver attraversato molti thread, ho trovato il problema da solo. Le risposte di cui sopra hanno dato l'idea ma vorrei ripassare tutto però.

• Il problema è che anche se stai attivando l'ambiente, si riferisce all'ambiente di sistema a causa del modo in cui abbiamo creato virtualenv.

• quando eseguiamo il comando virtualenv env -p python3 installerà virtualenv ma non creerà no-global — site-packages.txt.

• Per questo motivo quando attivi l'ambiente tramite il comando di attivazione della sorgente, questo file chiamato site.py (il nome può essere diverso, l'ho appena dimenticato) che viene eseguito e controlla se questo file non è presente non aggiungerà il tuo percorso env a sys.path e usa i sistemi python.

• per risolvere questo problema basta eseguire virtualenv con un parametro extra —no-site-packages creerà quel file e quando si attiva l'ambiente aggiungerà il percorso dell'ambiente personalizzato nella variabile PATH rendendolo accessibile.

Molte buone discussioni sopra, ma sono stati usati esempi di virtualenv. Poiché "conda" è ora lo strumento consigliato per gestire virtualenv, ho riassunto i passaggi per eseguire pip in conda env come segue.

Userò py36r come nome di env e / opt / conda / envs è il prefisso di envs):

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

Nota che il pip eseguito dovrebbe essere in /opt/conda/envs/py36r/bin/pip(not /opt/conda/bin/pip).

In alternativa, puoi semplicemente eseguire quanto segue senza l'attivazione di conda

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

Inoltre, se installi usando conda, puoi installare senza attivare:

$ conda install -n py36r pkg_abc ...

FINESTRE

Per me la soluzione non era usare mkvirtualenv, ma:

python -m venv path/to/your/virtualenv

workon funziona correttamente.

mentre in virtualenv: pip -Vmostra il percorso di virtualenv per pip