Pip: El uso de --target con --editable da como resultado un error "interno"

También experimenta este error con pip install -t dir -e git+git://github.com/shazow/urllib3.git@f088037#egg=urllib3 .

También encontré este error en este momento.
Esto parece suceder en cualquier paquete si --target y --editable se combinan:
pip llama setup.py develop --home ... , pero --home solo es aplicable con setup.py install .

Entonces, al final descubrí que usar la opción --src con paquetes editables en lugar de --target hace lo que quiero.

Quizás --target debería tener el mismo efecto que --src cuando se especifica --editable o podría presentar al usuario un mensaje de error y tal vez apuntar al usuario a --src .

Quizás --target debería tener el mismo efecto que --src cuando se especifica --editable

En mi opinión, el comportamiento esperado crearía / actualizaría easy_install.pth en el directorio target .

Acabo de experimentar el mismo problema. Como lo sugiere @jezdez , puede

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

Yo mismo veo un problema similar aquí:

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'

La línea 290 en pip / commands / install.py es:

     lib_dir = home_lib(temp_target_dir)

Por lo que puedo rastrear, pip ya ha limpiado esta ruta en pip / req.py línea 1194 donde elimina la fuente temporal.

     requirement.remove_temporary_source()

Puedo ver dejar esa limpieza allí como está, pero envolverla con un bloque de existe o prueba para que la instalación pueda continuar. ¿Alguien ve eso como un problema?

@tima Tuve el mismo problema con el directorio lib. Pip HEAD supuestamente solucionó esto, pero al menos en CentOS el problema persiste. En este caso particular, hay un directorio lib64 en lugar de uno lib.

Tengo el mismo problema al usar --target (pero no --editable ).

Aquí está mi rastreo

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,

 Descargando PyYAML-3.10.tar.gz (241kB): 241kB descargado
 Ejecutando setup.py egg_info para el paquete pyyaml
 omitiendo la extensión de Cython 'ext / _yaml.c' (actualizada)
 Instalación de paquetes recopilados: krcore, sympy, pyparsing, pyyaml
 Ejecutando setup.py desarrollar para krcore
 uso: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
 o: -c --help [cmd1 cmd2 ...]
 o: -c - comandos-de-ayuda
 o: -c cmd --help
 error: opción - hogar no reconocido
 Salida completa del 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 ')) "desarrollar --no-deps --home = / tmp / tmpvKaRYp:
 uso: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
 o: -c --help [cmd1 cmd2 ...]
 o: -c - comandos-de-ayuda
 o: -c cmd --help
 error: opción - hogar no reconocido
 ----------------------------------------
 Limpiar...
 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 ')) "desarrollo --no-deps --home = / tmp / tmpvKaRYp falló con el código de error 1 en / tmp / krapp / src / krcore

Recibo el 'error: option --home not Recognized' cuando uso --target con -r (--requirements)

: +1:

La siguiente solución alternativa de @YorickPeterse y @jezdez causó:
error: debe proporcionar home o prefix / exec-prefix, no ambos

Las opciones --editable y --target no funcionan juntas

He tenido el mismo problema ...
Estoy tratando de usar pip para instalar paquetes de Python en una ubicación personalizada (no un virtualenv) y necesito que uno de ellos (en el que estoy trabajando) sea editable.

Esto probablemente esté relacionado con https://github.com/pypa/setuptools/issues/392

Y dado que un comando pip puede activar tanto setup.py develop (para paquetes editables) como setup.py install (dependencias), la única solución alternativa (muy fea) en la que puedo pensar es emitir 2 comandos:

• uno por paquete con --no-deps
• uno solo para dependencias (no hay una forma simple aquí ...)

Sería mucho más limpio si no hubiera necesidad de cambiar otras opciones de línea de comando de pip, ya sea que se pase --editable o no.
Así que supongo que hay dos formas de hacer que esto funcione:

• haciendo que las herramientas de configuración sean compatibles con --home ie. arreglando https://github.com/pypa/setuptools/issues/392. probablemente complicado, ¿leer los detalles de ese problema?
• tener detalles de las herramientas de configuración abstractas de pip e implementar el comportamiento de --target diferente dependiendo de si llama a setup.py develop o setup.py install . tal vez más simple?

tener detalles de las herramientas de configuración abstractas de pip e implementar el comportamiento de --target diferente dependiendo de si llama a setup.py develop o setup.py install . tal vez más simple?

La mayor dificultad con esta opción es que pip está trabajando para abstraer los detalles del sistema de compilación (herramientas de configuración), por lo que las soluciones alternativas para casos especiales para problemas de herramientas de configuración funcionan en contra de ese objetivo.

Al final logré hacer lo que quería, usando --prefix , y sin usar ningún --install-option , así que finalmente puedo usar las mismas opciones ya sea que pase --editable o no .

Sin embargo, tuve que adaptar de alguna manera mi diseño existente (debian) para que coincida con pip predeterminado (paquetes de sitio), ya que no hay una opción de pip para especificar el diseño ...

¿Quizás una característica para considerar agregar?

@xavfernandez

Esto necesita --target option etiqueta.

¿Podría alguien compartir cuál es la mejor solución para utilizar las opciones -e y -t? ¿Sugiere utilizar distutils ya que admite la opción '--home'?

¿hay noticias?

Todavía estoy usando --editable con --prefix (en lugar de --target ) que hace el trabajo por mí. Pero estoy atascado en pip <9.0.0 debido a la diferencia entre --prefix y --target . más detalles en https://github.com/pypa/pip/issues/4243

si desea usar la opción --prefix en lugar de --target, debe tener el PYTHONPATH (apuntando al directorio de paquetes del sitio a crear) configurado correctamente antes de poder llamar a pip -t . --prefix myprefix . ¿Existe una forma elegante de evitar esto?

Cerrando para mover un montón de temas relacionados a un solo tema: # 4390.

Agregaría que este es un problema para los desarrolladores de Google Appengine que necesitan instalar sus dependencias en un directorio en la raíz de la aplicación, pero también necesitan implementar una dependencia editable en un pago local como parte de un proceso de control de calidad. Tal como está, el editable debería tener un enlace simbólico manual, lo cual es engorroso.

Este hilo se ha bloqueado automáticamente ya que no ha habido ninguna actividad reciente después de que se cerró. Abra un nuevo problema para errores relacionados.