Pip: Usar --target com --editable resulta em erro "interno"

Criado em 3 jun. 2012  ·  22Comentários  ·  Fonte: pypa/pip

Parece que --target não é suportado ao usar --editable ao mesmo tempo. Seria bom tê-lo funcionando. Enquanto isso, deve haver algum diagnóstico melhor, como

c:\>pip install -t z:\1 -e git+https://github.com/kennethreitz/requests.git#egg=requests
resulta em

Obtaining requests from git+https://github.com/kennethreitz/requests.git#egg=requests
  Updating c:\python\virtualenv\test\src\requests clone
  Running setup.py egg_info for package requests

Downloading/unpacking certifi>=0.0.7 (from requests)
  Running setup.py egg_info for package certifi

Downloading/unpacking oauthlib>=0.1.0,<0.2.0 (from requests)
  Running setup.py egg_info for package oauthlib

Downloading/unpacking chardet>=1.0.0 (from requests)
  Running setup.py egg_info for package chardet

Downloading/unpacking rsa (from oauthlib>=0.1.0,<0.2.0->requests)
  Running setup.py egg_info for package rsa

    warning: no files found matching 'README'
Downloading/unpacking pyasn1>=0.0.13 (from rsa->oauthlib>=0.1.0,<0.2.0->requests)
  Running setup.py egg_info for package pyasn1

Installing collected packages: requests, certifi, oauthlib, chardet, rsa, pyasn1
  Running setup.py develop for requests
    usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
       or: -c --help [cmd1 cmd2 ...]
       or: -c --help-commands
       or: -c cmd --help

    error: option --home not recognized
    Complete output from command c:\python\virtualenv\test\Scripts\python.exe -c "import setuptools; __file__='c:\\python\\virtualenv\\test\\src\\requests\\setup.py'; exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" develop --no-deps --home=c:\users\piotr\appdata\local\temp\tmp3abskl:
    usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]

   or: -c --help [cmd1 cmd2 ...]

   or: -c --help-commands

   or: -c cmd --help



error: option --home not recognized

----------------------------------------
Command c:\python\virtualenv\test\Scripts\python.exe -c "import setuptools; __file__='c:\\python\\virtualenv\\test\\src\\requests\\setup.py'; exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" develop --no-deps --home=c:\users\piotr\appdata\local\temp\tmp3abskl failed with error code 1 in c:\python\virtualenv\test\src\requests
Storing complete log in C:\Users\Piotr\AppData\Roaming\pip\pip.log
editable target auto-locked bug

Comentários muito úteis

Eu acrescentaria que esse é um problema para os desenvolvedores do Google Appengine que precisam instalar suas dependências em um diretório na raiz do aplicativo, mas também precisam implantar uma dependência editável em uma verificação local como parte de um processo de controle de qualidade. No momento em que está, o editável precisaria ter um link simbólico manualmente, o que é complicado.

Todos 22 comentários

Encontrando este erro com pip install -t dir -e git+git://github.com/shazow/urllib3.git@f088037#egg=urllib3 também.

Eu também encontrei esse erro agora.
Isso parece acontecer em qualquer pacote se --target e --editable forem combinados:
pip chama setup.py develop --home ... , mas --home só é aplicável com setup.py install .

Então, no final eu descobri que usar a opção --src com pacotes editáveis ​​em vez de --target faz o que eu quero.

Talvez --target deva ter o mesmo efeito que --src quando --editable é especificado ou pode apresentar ao usuário uma mensagem de erro e talvez apontar para --src .

Talvez --target deva ter o mesmo efeito que --src quando --editable é especificado

IMO, o comportamento esperado seria criar / atualizar o easy_install.pth no diretório target .

Acabei de experimentar o mesmo problema. Conforme sugerido por @jezdez, você pode contornar isso fazendo o seguinte (sem usar --editable, isto é):

git+ssh://[email protected]/some-user/some-repo.git#egg=Foo

Estou vendo um problema semelhante aqui:

Cleaning up...
Exception:
Traceback (most recent call last):
  File "/efs/dev/bti/pip/1.3.1-build001/install/exec/2.7/lib/python/pip-1.3.1-py2.7.egg/pip/basecommand.py", line 139, in main
  status = self.run(options, args)
  File "/efs/dev/bti/pip/1.3.1-build001/install/exec/2.7/lib/python/pip-1.3.1-py2.7.egg/pip/commands/install.py", line 291, in run
    for item in os.listdir(lib_dir):
OSError: [Errno 2] No such file or directory: '/tmp/tmppjdGHI/lib/python'

a linha 290 em pip / comandos / install.py é:

     lib_dir = home_lib(temp_target_dir)

Pelo que posso rastrear, pip já limpou esse caminho na linha pip / req.py 1194, de onde remove a fonte temporária.

     requirement.remove_temporary_source()

Posso ver deixando a limpeza como está, mas envolvendo-a com um bloco exista ou tente para que a instalação possa continuar. Alguém vê isso como um problema?

@tima Eu tive o mesmo problema com o diretório lib. O Pip HEAD supostamente corrigiu isso, mas pelo menos no CentOS o problema ainda persiste. Neste caso particular, existe um diretório lib64 em vez de um lib.

Tenho o mesmo problema ao usar --target (mas não --editable ).

Aqui está o meu traceback-

Exception:
Traceback (most recent call last):
  File "/Users/beaum/homebrew/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg/pip/basecommand.py", line 139, in main
    status = self.run(options, args)
  File "/Users/beaum/homebrew/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg/pip/commands/install.py", line 294, in run
    for item in os.listdir(lib_dir):
OSError: [Errno 2] No such file or directory: '/var/folders/00/1hyxr000h01000cxqpysvccm0063vq/T/tmpc_E_Bl/lib/python'

+1,

 Baixando PyYAML-3.10.tar.gz (241kB): 241kB baixado
 Executando setup.py egg_info para o pacote pyyaml
 pulando 'ext / _yaml.c' extensão Cython (atualizado)
 Instalando pacotes coletados: krcore, sympy, pyparsing, pyyaml
 Executando setup.py developers para krcore
 uso: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
 ou: -c --help [cmd1 cmd2 ...]
 ou: -c --help-comandos
 ou: -c cmd --help
 erro: opção --home não reconhecida
 Saída completa do comando / usr / bin / python -c "import setuptools; __file __ = '/ tmp / krapp / src / krcore / setup.py'; exec (compile (open (__ file __). Read (). Replace ('\ r \ n ',' \ n '), __file__,' exec ')) "desenvolver --no-deps --home = / tmp / tmpvKaRYp:
 uso: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
 ou: -c --help [cmd1 cmd2 ...]
 ou: -c --help-comandos
 ou: -c cmd --help
 erro: opção --home não reconhecida
 ----------------------------------------
 Limpando...
 Comando / usr / bin / python -c "import setuptools; __file __ = '/ tmp / krapp / src / krcore / setup.py'; exec (compile (open (__ file __). Read (). Replace ('\ r \ n ',' \ n '), __file__,' exec ')) "development --no-deps --home = / tmp / tmpvKaRYp falhou com o código de erro 1 em / tmp / krapp / src / krcore

Recebo o 'erro: opção --home não reconhecida' ao usar --target com -r (--requirements)

: +1:

Após @YorickPeterse e @jezdez Como contornar causado:
erro: deve fornecer home ou prefix / exec-prefix - não ambos

As opções --editable e --target não funcionam juntas

Eu tenho encontrado o mesmo problema ...
Estou tentando usar o pip para instalar pacotes Python em um local personalizado (não um virtualenv) e preciso que um deles (o que estou trabalhando) seja editável.

Isso provavelmente está relacionado a https://github.com/pypa/setuptools/issues/392

E como um comando pip pode acionar setup.py develop (para pacote editável) e setup.py install (dependências), a única (muito feia) solução alternativa que posso pensar é emitir 2 comandos:

  • um por pacote com --no-deps
  • um apenas para dependências (nenhuma maneira simples aqui ...)

Seria muito mais limpo se não houvesse necessidade de alterar outras opções de linha de comando do pip, independentemente de --editable ser aprovado ou não.
Portanto, acho que há duas maneiras de fazer isso funcionar:

  • fazendo setuptools suportar --home ie. corrigindo https://github.com/pypa/setuptools/issues/392. provavelmente complicado, lendo os detalhes desse problema?
  • ter pip abstract setuptools detalhes e implementar --target comportamento de forma diferente dependendo se ele chama setup.py develop ou setup.py install . talvez mais simples?

ter pip abstract setuptools detalhes e implementar --target comportamento de forma diferente dependendo se ele chama setup.py develop ou setup.py install . talvez mais simples?

A maior dificuldade com essa opção é que o pip está trabalhando para abstrair os detalhes do sistema de compilação (ferramentas de instalação), portanto, soluções alternativas para casos especiais de ferramentas de instalação funcionam contra esse objetivo.

No final, consegui fazer o que queria, usando --prefix , e sem usar nenhum --install-option , então posso finalmente usar as mesmas opções se passar --editable ou não .

No entanto, eu tive que adaptar de alguma forma meu layout existente (debian) para combinar com o padrão do pip (site-packages), uma vez que não há opção do pip para especificar o layout ...

Talvez um recurso a ser adicionado?

@xavfernandez

Isso precisa do rótulo --target option .

Alguém poderia compartilhar qual é a melhor solução alternativa para usar as opções -e e -t? Você está sugerindo o uso de distutils, uma vez que suporta a opção '--home'?

alguma novidade?

Ainda estou usando --editable com --prefix (em vez de --target ), que faz o trabalho para mim. Mas estou preso em pip <9.0.0 por causa da diferença entre --prefix e --target . mais detalhes em https://github.com/pypa/pip/issues/4243

se você quiser usar a opção --prefix em vez de --target, você precisa ter PYTHONPATH (apontando para o diretório de pacotes de sites a serem criados) definido corretamente antes de chamar pip -t . --prefix myprefix . Existe uma maneira elegante de contornar isso?

Fechando para mover um monte de questões relacionadas a um único problema: # 4390.

Eu acrescentaria que esse é um problema para os desenvolvedores do Google Appengine que precisam instalar suas dependências em um diretório na raiz do aplicativo, mas também precisam implantar uma dependência editável em uma verificação local como parte de um processo de controle de qualidade. No momento em que está, o editável precisaria ter um link simbólico manualmente, o que é complicado.

Este tópico foi bloqueado automaticamente, pois não houve nenhuma atividade recente depois que foi fechado. Abra uma nova edição para bugs relacionados.

Esta página foi útil?
0 / 5 - 0 avaliações