pip instalando em pacotes de sites globais em vez de virtualenv

Usar pip3para instalar um pacote em a virtualenvfaz com que o pacote seja instalado na pasta global site-packages em vez de na pasta virtualenv. Veja como configuro o Python3 e o virtualenv no OS X Mavericks (10.9.1):

Instalei o Python3 usando o Homebrew:

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

Alterou a $PATHvariável em .bash_profile; adicionou a seguinte linha:

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

Execução de which python3retornos /usr/local/bin/python3(após reiniciar o shell).

Nota: which python3ainda retorna / usr/bin/pythonembora.

Instalado virtualenvusando pip3:

pip3 install virtualenv

Em seguida, crie um novo virtualenve ative-o:

virtualenv testpy3 -p python3
cd testpy3
source bin/activate

Observação: se eu não especificar -p python3, pip estará ausente da pasta bin no virtualenv.

Executando which pipe which pip3ambos retornam a pasta virtualenv:

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

Agora, quando tento instalar, por exemplo, Markdown usando pip no virtualenv ativado, o pip irá instalar na pasta global site-packages em vez da pasta site-packages do virtualenv.

pip install markdown

pip listDevoluções em execução :

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

Conteúdo de /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/

Conteúdo de /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/

Como você pode ver, a pasta global site-packages contém Markdown, a pasta virtualenv não.

Observação: eu já tinha Python2 e Python3 instalados antes em uma VM diferente (segui essas instruções) e tive o mesmo problema com Python3; Instalar pacotes em um virtualenv baseado em Python2 funcionou perfeitamente.

Quaisquer dicas, sugestões, ... seriam muito apreciadas.

Engraçado você ter tocado nisso, eu simplesmente tive exatamente o mesmo problema. Eu resolvi isso eventualmente, mas ainda não tenho certeza do que causou isso.

Tente verificar seus scripts bin/pipe bin/activate. Em bin/pip, olhe para o shebang. Está correto? Se não, corrija. Então, na linha ~ 42em seu bin/activate, verifique se o caminho do virtualenv está correto. Será algo assim

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

Se estiver errado, corrija-o, deactivateentão . bin/activate, e se nosso problema mútuo tiver a mesma causa, deve funcionar. Se ainda não o fizer, você está no caminho certo, de qualquer maneira. Passei pela mesma rotina de resolução de problemas que você, which piprepetidamente, seguindo o rastreamento da pilha, etc.

Tenha certeza absoluta de que

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

é o que você quer, e não se referindo a outro projeto de teste com nome semelhante (eu tive esse problema e não tenho ideia de como ele começou. Minha suspeita é executar vários virtualenvs ao mesmo tempo).

Se nada disso funcionar, uma solução temporária pode ser, como disse Joe Holloway,

Basta executar o pip do virtualenv com seu caminho completo (ou seja, não dependa da busca pelo caminho do executável) e você nem precisa ativar o ambiente. Isso fará a coisa certa.

Talvez não seja o ideal, mas deve funcionar em uma pitada.

Link para minha pergunta original:

VirtualEnv / Pip tentando instalar pacotes globalmente

Para mim, isso não era um problema de pip ou virtualenv. Era um problema de python. Eu tinha definido meu $ PYTHONPATH manualmente em ~ / .bash_profile (ou ~ / .bashrc) depois de seguir alguns tutoriais online. Este $ PYTHONPATH definido manualmente estava disponível no virtualenv, pois provavelmente deveria ser permitido.

Além disso, add2virtualenvnão estava adicionando o caminho do meu projeto ao meu $ PYTHONPATH por algum motivo no virtualenv.

Apenas alguns caminhos bifurcados para aqueles que ainda podem estar presos! Felicidades!

Eu tive o mesmo problema, resolvi removendo o diretório venv e recriá-lo!

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

Agora tudo funciona como um encanto.

Eu tive esse problema também. Chamar pip install <package_name>do /bindiretório em meu ambiente virtual Python 3.3 em meu Mavericks Mac fez com que o pacote Python fosse instalado no diretório de pacotes de sites globais Python 2.7. Isso apesar do fato de que meu $ PATH começou com o diretório que contém pip. Esquisito. Isso não acontece no CentOS. Para mim, a solução era ligar em pip3vez de pip. Quando eu tinha instalado pip dentro do ambiente virtual via ez_setup , três executáveis "pip" tinha sido instalado no /bindiretório - pip, pip3e pip3.3. Curiosamente, todos os três arquivos eram exatamente iguais. Chamandopip3 install <package_name>fez com que o pacote Python fosse instalado corretamente no diretório local de pacotes de sites. Chamar pipcom o nome do caminho completo no ambiente virtual também funcionou corretamente. Eu estaria interessado em saber por que meu Mac não está usando $ PATH da maneira que eu esperava.

A primeira coisa a verificar é para qual local o pip está resolvendo:

which pip

se você estiver em um virtualenv, esperaria que isso lhe desse algo como:

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

No entanto, pode ser que ele esteja resolvendo o pip do sistema por algum motivo. Por exemplo, você pode ver isso de dentro do seu virtualenv (isso é ruim):

/ usr / local / bin / pip (ou qualquer coisa que não esteja em seu caminho virtualenv).

Para resolver isso, verifique seu pipconfig em:

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

e certifique-se de que não há nada que esteja coagindo seu caminho Python ou seu caminho pip (isso corrigiu para mim).

Em seguida, tente iniciar um novo terminal e reconstruir seu virtualenv (exclua e crie-o novamente)

Eu tive o mesmo problema ao instalar um pacote python de dentro de um virtualenv. A causa raiz no meu caso era diferente. De dentro do virtualenv, eu estava (por hábito no Ubuntu), fazendo:

sudo easy_install -Z <package>

Isso fez com que o bin / pip shebang fosse ignorado e usou o python não virtualenv do root para instalá-lo nos pacotes de sites globais. Como temos um ambiente virtual, devemos instalar o pacote sem "sudo"

Eu tropecei no mesmo problema ao executar Manjaro. Criei o ambiente virtual usando python3 -m ven venve depois ativei usando source venv/bin/actiave. which pythone which pipambos apontavam para os binários corretos no virtualenv, porém não consegui instalar no virtualenv, mesmo usando o caminho completo dos binários. Descobri que quando desinstalei o pacote python-pip com sudo pacman -R python-pip python-reportlab(tive que incluir o reportlab para satisfazer as dependências) tudo começou a funcionar conforme o esperado. Não sei por que, mas provavelmente isso se deve a uma instalação dupla em que o pacote do sistema está tendo precedência.

Tive um problema semelhante após atualizar para pip==8.0.0. Tive que recorrer a depuração de pip para rastrear o caminho ruim.

Acontece que meu diretório de perfil tinha um arquivo de configuração distutils com alguns valores de caminho vazios. Isso fazia com que todos os pacotes fossem instalados no mesmo diretório raiz em vez do ambiente virtual apropriado (no meu caso /lib/site-packages).

Não tenho certeza de como o arquivo de configuração chegou lá ou como ele tinha valores vazios, mas começou após a atualização do pip.

No caso de alguém se deparar com o mesmo problema, simplesmente excluir o arquivo ~/.pydistutils.cfg(ou remover o caminho de configuração vazio) corrigiu o problema em meu ambiente porque o pip voltou para a configuração padrão distribuída.

Vá para o diretório bin em seu ambiente virtual e escreva assim:

./pip3 install <package-name>

Eu tive o mesmo problema em macos com python 2 e 3 instalado.

Além disso, eu tinha aliases para apontar para python3 e pip3 no meu .bash_profile.

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

Remover aliases e recriar ambientes virtuais python3 -m venv venvcorrigiu o problema.

Encontrei o mesmo problema hoje. Simplesmente reinstalei o pip globalmente com sudo easy_install pip(OSX / Max) e criei meu virtualenv novamente com sudo virtualenv nameOfVEnv. Depois de ativar o novo virtualenv, o pipcomando funcionou conforme o esperado.

Acho que não usei sudona primeira criação do virtualenv e pode ter sido esse o motivo de não ter acesso a pipde dentro do virtualenv, mas consegui acessar pip2antes dessa correção, o que era estranho.

Aqui estão algumas práticas que podem evitar dores de cabeça ao usar ambientes virtuais:

• Crie uma pasta para seus projetos.
• Crie seus projetos Virtualenv dentro desta pasta.
• Depois de ativar o ambiente do seu projeto, nunca use o " pacote de instalação sudo pip ".
• Após terminar seu trabalho, sempre " desative " seu ambiente.
• Evite renomear sua pasta de projeto.

Para uma melhor representação dessas práticas, aqui está uma simulação:

criando uma pasta para seus projetos / ambientes

$ mkdir venv

criando ambiente

$ cd venv/ 

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

ambiente de ativação

$ source google_drive/bin/activate

instalando pacotes

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

pacote disponível dentro do 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()
>>>

desativar ambiente

(google_drive) $ deactivate 

$ 

pacote NÃO DISPONÍVEL fora do 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
>>> 

Notas:

Por que não sudo?

Virtualenv cria um ambiente totalmente novo para você, definindo $ PATH e algumas outras variáveis ​​e configurações. Quando você usa o pacote de instalação sudo pip , você está executando Virtualenv como root , escapando de todo o ambiente que foi criado e, em seguida, instalando o pacote em pacotes de sites globais, e não dentro da pasta do projeto onde você tem um ambiente virtual, embora você ativaram o ambiente.

Se você renomear a pasta do seu projeto (conforme mencionado na resposta aceita) ...

... você terá que ajustar algumas variáveis ​​de alguns arquivos dentro do diretório bin do seu projeto.

Por exemplo:

bin / pip, linha 1 (She Bang)

bin / activate, linha 42 (VIRTUAL_ENV)

Eu tive esse problema. Acontece que havia um espaço em um dos nomes de minha pasta que causou o problema. Eu removi o espaço, apaguei e reinstanciai usando venv, e tudo estava bem.

Esse problema ocorre ao criar uma instância virtualenv e, em seguida, alterar o nome da pasta pai.

Nenhuma das soluções acima funcionou para mim.

Meu venv estava ativo. pip -Ve which pipme deu o caminho virtualenv correto, mas quando fiz pip installpacotes com o venv ativado, meu pip freezepermaneceu vazio.

Todas as variáveis ​​de ambiente também estavam corretas.

Por fim, acabei de alterar o pip e remover o virtualenv:

easy_install pip==7.0.2

pip install pip==10

sudo pip uninstall virtualenv

Reinstale venv:

sudo pip install virtualenv

Criar venv:

python -m virtualenv venv_name_here

E todos os pacotes instalados corretamente no meu venv novamente.

Depois de criar o ambiente virtual, tente usar o pip localizado em yourVirtualEnvName \ Scripts

Deve instalar um pacote dentro de Lib \ site-packages em seu ambiente virtual

Eu tive esse problema também. Chamar sudo pip installfez com que os pacotes Python fossem instalados no diretório global de pacotes de sites e chamar pip installfuncionou bem. Portanto, não use sudo no virtualenv.

O mesmo problema. Python3.5 e pip 8.0.2 instalados a partir do Linux rpm.

Não encontrei uma causa primária e não consigo dar uma resposta adequada. Parece que existem várias causas possíveis.

No entanto, espero poder ajudar compartilhando minha observação e uma solução alternativa.

1. pyvenv com --system-site-packages

   • ./binnão contém pip, pipestá disponível nos pacotes do site do sistema
   • pacotes são instalados globalmente ( BUG? )

2. pyvenv sem --system-site-packages

   • pipé instalado ./bin, mas é uma versão diferente (de ensurepip)
   • os pacotes são instalados no ambiente virtual ( OK )

Solução óbvia para pyvenvcom --system-site-packages:

• crie-o sem a --system-site-packagesopção
• mudar include-system-site-packages = falsepara trueno pyvenv.cfgarquivo

Também vale a pena verificar se você não modificou de alguma forma o caminho para seu virtualenv.

Nesse caso, a primeira linha bin/pip(e o resto dos executáveis) teria um caminho incorreto.

Você pode editar esses arquivos e corrigir o caminho ou remover e instalar novamente o virtualenv.

Para Python 3ers

Tente atualizar. Eu tive exatamente o mesmo problema e tentei a resposta de Chases, porém sem sucesso. A maneira mais rápida de refatorar isso é atualizar sua versão Python Minor / Patch, se possível. Percebi que estava executando o 3.5.1 e atualizei para o 3.5.2. Pyvenv mais uma vez funciona.

Isso aconteceu comigo quando criei o virtualenv no local errado. Então pensei que poderia mover o dir para outro local sem que isso importasse. Isso importava.

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

Que merda, esqueci de fazer o cd projectsantes de criar o virtualenv e clonar o representante. Bem, sou muito preguiçoso para destruir e recriar. Vou apenas mover o dir sem problemas.

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

Não, quer mais permissões, quais são? Achei estranho, mas SUDO LONGE! Em seguida, instalou os pacotes em um local global.

A lição que aprendi foi, apenas excluir o diretório virtualenv. Não se mexa.

Tive este problema depois de instalar o Divio: ele tinha alterado meu PATH ou ambiente de alguma forma, já que inicia um terminal.

A solução neste caso foi apenas fazer o source ~/.bash_profileque já deveria estar configurado para voltar ao estado original pyenv / pyenv-virtualenv.

Aconteceu comigo quando instalei o virtualenv com --python=python3.6flag, mas depois tentei usar pip2 install.
Criar virtualenv com o sinalizador da versão que você usará resolve os problemas de permissão. Para verificar, experimente which pipou which pip2ou which pip3(depende da sua escolha). Se algum que pipvocê usar mostra o caminho não para venvaqui, é o seu problema.

De alguma forma, um arquivo setup.cfg com um prefixo = "" na pasta do projeto

executar pip install no virtualenv fora da pasta do projeto funcionou, então, por dentro, dizia a pip para usar um prefixo vazio cujo padrão é "/"

remover o arquivo corrigiu isso

Tive esse problema e, depois de tentar todas as soluções acima, apenas removi tudo e comecei de novo.

No meu caso usei sudona criação de uma das pastas em que existia o ambiente virtual, e sudo deu privilégios para root

Fiquei muito chateado! Mas funcionou!

Eu tenho que usar 'sudo' para instalar pacotes através do pip no meu sistema ubuntu por algum motivo. Isso está fazendo com que os pacotes sejam instalados em pacotes de sites globais. Colocando aqui para qualquer pessoa que possa enfrentar esse problema no futuro.

Tive exatamente o problema do título e resolvi. Pip começou a instalar no venv site-packages depois que limpei meu PATH: ele tinha um caminho para meu diretório ~ / bin local no início.

Portanto, meu conselho: verifique minuciosamente as variáveis ​​de ambiente para "lixo" ou qualquer coisa fora do padrão. Infelizmente, o virtualenv pode ser sensível a eles.

Boa sorte!

A resposta curta é executar Command virtualenv com o parâmetro “—no-site-packages”.

Resposta longa com explicação: -

Então, depois de correr aqui e ali, e passar por muitos tópicos, descobri o problema. As respostas acima deram a ideia, mas gostaria de repassar tudo.

• O problema é que mesmo se você estiver ativando o ambiente, ele está se referindo ao ambiente do sistema por causa da forma como criamos o virtualenv.

• quando executamos o comando virtualenv env -p python3, ele instala o virtualenv, mas não cria no-global — site-packages.txt.

• Por causa disso, quando você ativa o ambiente pelo comando de ativação da fonte, há este arquivo chamado site.py (o nome pode ser diferente, eu apenas esqueci) que é executado e verifica se este arquivo não está presente, não adicionará seu caminho env a sys.path e usar sistemas python.

• para corrigir esse problema, basta executar o virtualenv com o parâmetro extra —no-site-packages, ele criará esse arquivo e quando você ativar o ambiente, ele adicionará seu caminho de ambiente personalizado em sua variável PATH tornando-o acessível.

Muita discussão boa acima, mas exemplos de virtualenv foram usados. Como 'conda' agora é a ferramenta recomendada para gerenciar o virtualenv, resumi as etapas para executar o pip no conda env a seguir.

Usarei py36r como o nome do env e / opt / conda / envs é o prefixo do 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

Observe que o pip executado deve estar em /opt/conda/envs/py36r/bin/pip(não /opt/conda/bin/pip).

Alternativamente, você pode simplesmente executar o seguinte sem ativar o conda

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

Além disso, se você instalar usando conda, poderá instalar sem ativar:

$ conda install -n py36r pkg_abc ...

JANELAS

Para mim a solução não foi usar mkvirtualenv, mas:

python -m venv path/to/your/virtualenv

workon funciona corretamente.

while in virtualenv: pip -Vmostra o caminho do virtualenv para pip