Pip: L'utilisation de --target avec --editable entraîne une erreur "interne"

Vous rencontrez également cette erreur avec pip install -t dir -e git+git://github.com/shazow/urllib3.git@f088037#egg=urllib3 .

J'ai également rencontré cette erreur en ce moment.
Cela semble se produire sur n'importe quel package si --target et --editable sont combinés:
pip appelle setup.py develop --home ... , mais --home n'est applicable qu'avec setup.py install .

Donc, à la fin, j'ai découvert que l'utilisation de l'option --src avec des packages modifiables au lieu de --target fait ce que je veux.

Peut-être que --target devrait avoir le même effet que --src quand --editable est spécifié ou il pourrait présenter à l'utilisateur un message d'erreur et peut-être pointer l'utilisateur vers --src .

Peut-être que --target devrait avoir le même effet que --src lorsque --editable est spécifié

OMI, le comportement attendu créerait / mettrait à jour le fichier easy_install.pth dans le répertoire target .

Je viens de rencontrer le même problème. Comme suggéré par @jezdez, vous pouvez contourner ce

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

Je vois un problème similaire ici moi-même:

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 ligne 290 dans pip / commands / install.py est:

     lib_dir = home_lib(temp_target_dir)

D'après ce que je peux tracer, pip a déjà nettoyé ce chemin dans la ligne 1194 pip / req.py où il supprime la source temporaire.

     requirement.remove_temporary_source()

Je peux voir laisser ce nettoyage là-dedans tel quel, mais l'envelopper avec un bloc existe ou essayez pour que l'installation puisse continuer. Quelqu'un voit-il cela comme un problème?

@tima J'ai eu le même problème avec le répertoire lib. Pip HEAD aurait corrigé cela, mais au moins sur CentOS, le problème persiste. Dans ce cas particulier, il existe un répertoire lib64 au lieu d'un répertoire lib.

J'ai le même problème avec --target (mais pas --editable ).

Voici ma trace -

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,

 Téléchargement de PyYAML-3.10.tar.gz (241kB): 241kB téléchargés
 Exécution de setup.py egg_info pour le package pyyaml
 ignorer l'extension Cython 'ext / _yaml.c' (à jour)
 Installation des paquets collectés: krcore, sympy, pyparsing, pyyaml
 Exécution de setup.py develop pour krcore
 utilisation: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
 ou: -c --help [cmd1 cmd2 ...]
 ou: -c --help-commands
 ou: -c cmd --help
 erreur: option --home non reconnu
 Sortie complète de la commande / usr / bin / python -c "import setuptools; __file __ = '/ tmp / krapp / src / krcore / setup.py'; exec (compile (open (__ file __). Read (). Replace ('\ r \ n ',' \ n '), __file__,' exec ')) "develop --no-deps --home = / tmp / tmpvKaRYp:
 utilisation: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
 ou: -c --help [cmd1 cmd2 ...]
 ou: -c --help-commands
 ou: -c cmd --help
 erreur: option --home non reconnu
 ----------------------------------------
 Nettoyer...
 Commande / usr / bin / python -c "import setuptools; __file __ = '/ tmp / krapp / src / krcore / setup.py'; exec (compile (ouvre (__ fichier __). Read (). Replace ('\ r \ n ',' \ n '), __file__,' exec ')) "develop --no-deps --home = / tmp / tmpvKaRYp a échoué avec le code d'erreur 1 dans / tmp / krapp / src / krcore

J'obtiens le 'erreur: option --home non reconnu' lors de l'utilisation de --target avec -r (--requirements)

: +1:

Suite à la solution de contournement @YorickPeterse et @jezdez a causé:
erreur: doit fournir soit home, soit prefix / exec-prefix - pas les deux

Les options --editable et --target ne fonctionnent pas ensemble

J'ai rencontré le même problème ...
J'essaie d'utiliser pip pour installer des packages python dans un emplacement personnalisé (pas un virtualenv) et j'ai besoin que l'un d'entre eux (celui sur lequel je travaille) soit modifiable.

Ceci est probablement lié à https://github.com/pypa/setuptools/issues/392

Et comme une commande pip peut déclencher à la fois setup.py develop (pour pkg modifiable) et setup.py install (dépendances), la seule solution de contournement (très moche) à laquelle je puisse penser est d'émettre 2 commandes:

• un pour pkg avec --no-deps
• un pour les dépendances uniquement (pas de moyen simple ici ...)

Ce serait beaucoup plus propre s'il n'était pas nécessaire de modifier les autres options de la ligne de commande pip, que --editable soit passé ou non.
Donc je suppose qu'il y a deux façons de faire fonctionner cela:

• rendre setuptools supporte --home ie. correction de https://github.com/pypa/setuptools/issues/392. probablement difficile, lire les détails de ce problème?
• avoir les détails de pip abstract setuptools et implémenter le comportement de --target différemment selon qu'il appelle setup.py develop ou setup.py install . peut-être plus simple?

avoir les détails de pip abstract setuptools et implémenter le comportement de --target différemment selon qu'il appelle setup.py develop ou setup.py install . peut-être plus simple?

La plus grande difficulté avec cette option est que pip s'efforce d'abstraire les détails du système de construction (setuptools), donc des solutions de contournement spéciales pour les problèmes de setuptools vont à l'encontre de cet objectif.

Au final, j'ai réussi à faire ce que je voulais, en utilisant --prefix , et sans utiliser de --install-option , donc je peux enfin utiliser les mêmes options que je passe --editable ou non .

Cependant, j'ai dû en quelque sorte adapter ma mise en page existante (Debian) pour qu'elle corresponde à pip default (site-packages), car il n'y a pas d'option pip pour spécifier la mise en page ...

Peut-être une fonctionnalité à ajouter?

@xavfernandez

Cela nécessite --target option étiquette

Quelqu'un pourrait-il partager la meilleure solution de contournement pour utiliser les options -e et -t? Proposez-vous d'utiliser distutils car il prend en charge l'option '--home'?

des nouvelles?

J'utilise toujours --editable avec --prefix (au lieu de --target ) qui fait le travail pour moi. Mais je suis bloqué sur pip <9.0.0 à cause de la différence entre --prefix et --target . plus de détails sur https://github.com/pypa/pip/issues/4243

si vous souhaitez utiliser l'option --prefix au lieu de --target, vous devez avoir le PYTHONPATH (pointant vers le répertoire des packages de site à créer) correctement défini avant de pouvoir appeler pip -t . --prefix myprefix . Existe-t-il un moyen élégant de contourner cela?

Clôture pour déplacer un tas de problèmes connexes vers un seul numéro: # 4390.

J'ajouterais qu'il s'agit d'un problème pour les développeurs Google Appengine qui doivent installer leurs dépendances dans un répertoire à la racine de l'application, mais doivent également déployer une dépendance modifiable dans une caisse locale dans le cadre d'un processus d'assurance qualité. Comme il se trouve, le modifiable devrait être lié manuellement, ce qui est fastidieux.

Ce thread a été automatiquement verrouillé car il n'y a eu aucune activité récente après sa fermeture. Veuillez ouvrir un nouveau numéro pour les bogues associés.