virtualenv --no-site-pacchetti e pip continua a trovare pacchetti globali?

Avevo l'impressione che virtualenv --no-site-packagesavrebbe creato un ambiente Python completamente separato e isolato, ma non sembra.

Ad esempio, ho installato python-django a livello globale, ma desidero creare un virtualenv con una diversa versione di Django.

$ virtualenv --no-site-packages foo       
New python executable in foo/bin/python
Installing setuptools............done.
$ pip -E foo install Django
Requirement already satisfied: Django in /usr/share/pyshared
Installing collected packages: Django
Successfully installed Django

Da quello che posso dire, quanto pip -E foo installsopra dovrebbe reinstallare una nuova versione di Django. Inoltre, se dico a pip di congelare l'ambiente, ottengo molti pacchetti. Mi aspetterei che per un ambiente fresco con --no-site-packagesquesto sarebbe vuoto?

$ pip -E foo freeze
4Suite-XML==1.0.2
BeautifulSoup==3.1.0.1
Brlapi==0.5.3
BzrTools==1.17.0
Django==1.1
... and so on ...

Sto fraintendendo come --no-site-packagesdovrebbe funzionare?

Ho avuto un problema del genere, fino a quando non ho capito che (molto prima di aver scoperto virtualenv), ero andato ad aggiungere directory al PYTHONPATH nel mio file .bashrc. Come era stato più di un anno prima, non ci ho pensato subito.

Devi assicurarti di eseguire il pipbinario nell'ambiente virtuale che hai creato, non quello globale.

env/bin/pip freeze

Vedi un test:

Creiamo virtualenv con l' --no-site-packagesopzione:

$ virtualenv --no-site-packages -p /usr/local/bin/python mytest
Running virtualenv with interpreter /usr/local/bin/python
New python executable in mytest/bin/python
Installing setuptools, pip, wheel...done.

Controlliamo l'output del freezenuovo creato pip:

$ mytest/bin/pip freeze
argparse==1.3.0
wheel==0.24.0

Ma se usiamo il globale pip, questo è ciò che otteniamo:

$ pip freeze
...
pyxdg==0.25
...
range==1.0.0
...
virtualenv==13.1.2

Cioè, tutti i pacchetti pipinstallati in tutto il sistema. Controllando which pipotteniamo (almeno nel mio caso) qualcosa del genere /usr/local/bin/pip, nel senso che quando lo facciamo pip freezechiama questo binario invece di mytest/bin/pip.

Alla fine ho scoperto che, per qualsiasi motivo, pip -E non funzionava. Tuttavia, se attivo effettivamente virtualenv e utilizzo easy_install fornito da virtualenv per installare pip, quindi uso pip direttamente dall'interno, sembra funzionare come previsto e mostra solo i pacchetti in virtualenv

So che questa è una domanda molto vecchia ma per chi arriva qui alla ricerca di una soluzione:

Non dimenticare di attivare virtualenv ( source bin/activate) prima di eseguire pip freeze. Altrimenti otterrai un elenco di tutti i pacchetti globali.

Cancella temporaneamente PYTHONPATHcon:

export PYTHONPATH=

Quindi creare e attivare l'ambiente virtuale:

virtualenv foo
. foo/bin/activate

Solo allora:

pip freeze

--no-site-packagesdovrebbe, come suggerisce il nome, rimuovere la directory standard dei pacchetti del sito da sys.path. Qualsiasi altra cosa che vive nel percorso standard di Python rimarrà lì.

Un problema simile può verificarsi su Windows se si chiamano direttamente gli script, script.pyche utilizzano quindi l'apri di default di Windows e aprono Python all'esterno dell'ambiente virtuale. Chiamandolo con python script.pyverrà usato Python con l'ambiente virtuale.

Questo sembra accadere anche quando si sposta la directory virtualenv in un'altra directory (su Linux) o si rinomina una directory padre.

Stavo avendo lo stesso problema. Il problema per me (su Ubuntu) era che il mio nome di percorso era contenuto $. Quando ho creato un virtualenv al di fuori della $ dir, ha funzionato bene.

Strano.

Uno dei possibili motivi per cui virtualenv pip non funzionerà è se una delle cartelle padre aveva spazio nel suo nome /Documents/project name/app rinominandolo per /Documents/projectName/apprisolvere il problema.

Mi sono imbattuto nello stesso problema in cui pip in venv funziona ancora come pip globale.
Dopo aver cercato molte pagine, l'ho capito in questo modo.
1. Crea un nuovo venv con virtualenv con l'opzione "--no-site-pacchetti"

virtualenv --no-site-packages --python=/xx/xx/bin/python my_env_nmae

per favore nota che sebbene l'opzione "--no-site-pacchetti" era vera per impostazione predefinita dall'1.7.0 nel file doc di virtualenv, ma l'ho trovato non funzionante a meno che non lo avessi impostato manualmente. Per ottenere un VENV puro, consiglio vivamente di attivare questa opzione su 2. Attiva il nuovo ambiente che hai creato

source ./my_env_name/bin/activate

3. Controlla la posizione del tuo pip e la posizione di Python e assicurati che questi due comandi siano in ambiente virtuale

pip --version
which python

4. Usa pip in env virtuale per installare pacchetti liberi dall'interruzione globale dei pacchetti

pip install package_name

Desideri che questa risposta ti aiuti!

Ecco l'elenco di tutte le opzioni di installazione pip : non ho trovato alcuna -Eopzione " ", potrebbe essere la versione precedente. Di seguito condivido un semplice uso e funzionamento virtualenvdell'inglese per i prossimi utenti SO.

Tutto sembra a posto, accetta di attivare il virtualenv( foo). Tutto ciò che ci consente è di avere un ambiente Python multiplo (e variabile), ovvero varie versioni di Python, o varie versioni di Django o qualsiasi altro pacchetto Python - nel caso in cui abbiamo una versione precedente in produzione e desideriamo testare l'ultima versione di Django con il nostro applicazione.

In breve, la creazione e l'utilizzo (attivazione) dell'ambiente virtuale ( virtualenv) consente di eseguire o testare la nostra applicazione o semplici script Python con diversi interpreti Python, ad esempio Python 2.7 e 3.3 - può essere una nuova installazione (utilizzando l' --no-site-packagesopzione) o tutti i pacchetti esistenti / ultima configurazione (utilizzando l' --system-site-packagesopzione). Per usarlo dobbiamo attivarlo:

$ pip install djangolo installerà nei pacchetti globali del sito e, allo stesso modo, ottenendo i pip freezenomi dei pacchetti globali del sito.

mentre all'interno di venv dir (foo) l'esecuzione $ source /bin/activateattiverà venv, cioè ora tutto ciò che è installato con pip sarà installato solo nell'env virtuale, e solo ora il blocco pip non fornirà l'elenco dei pacchetti python globali di pacchetti del sito. Una volta attivato:

$ virtualenv --no-site-packages foo       
New python executable in foo/bin/python
Installing setuptools............done.
$ cd foo
$ source bin/activate 
(foo)$ pip install django

(foo)prima che il $segno indichi che stiamo usando un ambiente virtuale Python, vale a dire qualsiasi cosa con pip - installazione, blocco, disinstallazione sarà limitata a questo sistema venv e nessun effetto sull'installazione / pacchetti Python globali / predefiniti.