virtualenv --no-site-packages e pip ainda encontra pacotes globais?

Fiquei com a impressão de que virtualenv --no-site-packages criaria um ambiente Python completamente separado e isolado, mas não parece.

Por exemplo, eu tenho o python-django instalado globalmente, mas desejo criar um virtualenv com uma versão diferente do 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

Pelo que sei, o pip -E foo installacima exposto deve reinstalar uma nova versão do Django. Além disso, se eu disser ao pip para congelar o ambiente, recebo muitos pacotes. Eu esperaria que para um ambiente fresco com --no-site-packagesisso ficaria em branco?

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

Estou entendendo mal como --no-site-packagesdeve funcionar?

Eu tive um problema como esse, até perceber que (muito antes de descobrir o virtualenv), adicionei diretórios ao PYTHONPATH no meu arquivo .bashrc. Como já fazia mais de um ano, não pensei nisso imediatamente.

Você precisa ter certeza de que está executando o pipbinário no ambiente virtual que criou, não no global.

env/bin/pip freeze

Veja um teste:

Criamos o virtualenv com a --no-site-packagesopção:

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

Verificamos a saída do freezerecém-criado pip:

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

Mas se usarmos o global pip, é isso que obtemos:

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

Ou seja, todos os pacotes que pipforam instalados em todo o sistema. Ao verificar which pip, obtemos (pelo menos no meu caso) algo como /usr/local/bin/pip, o que significa que, quando o fazemos pip freeze, chama isso de binário em vez de mytest/bin/pip.

Eventualmente, descobri que, por qualquer motivo, pip -E não estava funcionando. No entanto, se eu realmente ativar o virtualenv e usar o easy_install fornecido pelo virtualenv para instalar o pip, use o pip diretamente de dentro, ele parece funcionar conforme o esperado e mostra apenas os pacotes no virtualenv

Sei que essa é uma pergunta muito antiga, mas para quem chega aqui procurando uma solução:

Não se esqueça de ativar o virtualenv ( source bin/activate) antes de executar pip freeze. Caso contrário, você obterá uma lista de todos os pacotes globais.

Limpe temporariamente o PYTHONPATHcom:

export PYTHONPATH=

Em seguida, crie e ative o ambiente virtual:

virtualenv foo
. foo/bin/activate

Apenas então:

pip freeze

--no-site-packagesComo o nome sugere, remova o diretório padrão de pacotes de sites sys.path. Qualquer outra coisa que viva no caminho padrão do Python permanecerá lá.

Um problema semelhante pode ocorrer no Windows, se você chamar scripts diretamente, script.pye usar o abridor padrão do Windows e abrir o Python fora do ambiente virtual. A chamada com python script.pyele usará o Python com o ambiente virtual.

Isso também parece acontecer quando você move o diretório virtualenv para outro diretório (no linux) ou renomeia um diretório pai.

Eu estava tendo o mesmo problema. O problema para mim (no Ubuntu) era que o nome do meu caminho continha $. Quando criei um virtualenv fora do $ dir, ele funcionou bem.

Esquisito.

Um dos possíveis motivos pelos quais o virtualenv pip não funcionará é se alguma das pastas pai tiver espaço em seu nome /Documents/project name/app renomeando-o para /Documents/projectName/appresolver o problema.

Eu vim através do mesmo problema em que o pip in venv ainda funciona como o pip global.
Depois de pesquisar muitas páginas, eu descobri dessa maneira.
1. Crie um novo venv by virtualenv com a opção "--no-site-packages"

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

observe que, embora a opção "--no-site-packages" seja o padrão verdadeiro desde 1.7.0 no arquivo doc do virtualenv, mas achei que ele não funcionava, a menos que você o ativasse manualmente. Para obter um venv puro, sugiro ativar esta opção 2. Ative o novo ambiente que você criou

source ./my_env_name/bin/activate

3. Verifique sua localização de pip e python e verifique se esses dois comandos estão em ambiente virtual

pip --version
which python

4. Use pip sob ambiente virtual para instalar pacotes livres da interupção de pacotes globais

pip install package_name

Gostaria que esta resposta o ajudasse!

Aqui está a lista de todas as opções de instalação do pip - não encontrei nenhuma -Eopção ' ', pode ser a versão mais antiga. Abaixo, estou compartilhando um uso simples do inglês e trabalhando virtualenvpara os futuros usuários de SO.

Tudo parece bem, aceite ativar o virtualenv(foo ). Tudo o que faz é permitir que tenhamos um ambiente python múltiplo (e variável), ou seja, várias versões Python, ou várias versões do Django ou qualquer outro pacote Python - caso tenhamos uma versão anterior em produção e desejemos testar a versão mais recente do Django com nosso inscrição.

Em suma, criar e usar (ativar) o ambiente virtual ( virtualenv) possibilita executar ou testar nosso aplicativo ou scripts python simples com diferentes interpretadores Python, por exemplo, Python 2.7 e 3.3 - pode ser uma instalação nova (usando a --no-site-packagesopção) ou todos os pacotes dos existentes / última configuração (usando a --system-site-packagesopção). Para usá-lo, temos que ativá-lo:

$ pip install djangoirá instalá-lo nos pacotes globais de sites e, da mesma forma, obter os pip freezenomes dos pacotes globais de sites.

enquanto dentro do venv dir (foo) a execução $ source /bin/activateativará o venv, ou seja, agora qualquer coisa instalada com o pip será instalada apenas no ambiente virtual e somente agora o pip freeze não fornecerá a lista dos pacotes python globais de pacotes de sites. Uma vez ativado:

$ 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)antes que o $sinal indique que estamos usando um ambiente virtual em python, ou seja, qualquer coisa com pip-install, freeze, uninstall será limitada a esse venv e não terá efeito na instalação / pacotes globais / padrão do Python.