web-dev-qa-db-fra.com

ImportError: impossible d'importer des wraps de noms

J'utilise python 2.7.6 sur Ubuntu 14.04.2 LTS. J'utilise mock pour me moquer de certains désagréments et je remarque que lorsque je l'importe, il échoue lors de l'importation des enveloppements.

Vous ne savez pas s'il existe une version différente de Mock ou six que je devrais utiliser pour que son import fonctionne? Impossible de trouver des réponses pertinentes et je n'utilise pas d'environnements virtuels.

le module dit qu'il est compatible avec python 2.7.x: https://pypi.python.org/pypi/mock

maquette == 1.1.3 six == 1.9.0

Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from mock import Mock
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/mock/__init__.py", line 2, in <module>
    import mock.mock as _mock
  File "/usr/local/lib/python2.7/dist-packages/mock/mock.py", line 68, in <module>
    from six import wraps
ImportError: cannot import name wraps

également essayé avec Sudo sans succès.

$ Sudo python -c 'from six import wraps'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: cannot import name wraps
pythonmockingpython-unittest
23
Michael

Installé maquette == 1.0.1 et cela a fonctionné pour une raison quelconque. (hausse les épaules)

edit: La vraie solution pour moi a été de mettre à jour setuptools mis à jour et cela m’a permis de mettre à jour maquettes et six au plus tard. J'étais sur setuptools 3.3. Dans mon cas, j'ai également dû retirer ces modules à la main car ils appartenaient à OS dans '/usr/local/lib/python2.7/dist-packages/'

vérifier les versions de tout

pip freeze | grep -e six -e mock
easy_install --version

Tout mettre à jour

wget https://bootstrap.pypa.io/ez_setup.py -O - | Sudo python
pip install mock --upgrade
pip install six --upgrade

Merci @lifeless

30
Michael

J'ai rencontré le même problème sur mon mac, que j'ai pu résoudre en réalisant que le sys.path de mon python contenait à la fois 

/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/

et

/Library/Python/2.7/site-packages/

avec le premier plus tôt que le dernier.

Vous pouvez vérifier si cela vous arrive en exécutant ce qui suit dans la console python.

import six
six.__version__

mon python chargeait un fichier six.py obsolète à partir de l’ancien répertoire (qui n’avait pas de wrapper), même si pip avait installé une version six plus récente dans le deuxième répertoire. (Il semble que le framework mac propose une version de six par défaut.)

J'ai pu résoudre ce problème en déplaçant six.py et six.pyc du premier répertoire (nécessite un accès Sudo), afin que python trouve la version la plus récente de six dans le deuxième répertoire. Je suis sûr que vous pouvez également modifier l'ordre des chemins dans sys.path.

Pour rechercher l’ancienne version de six à supprimer, exécutez-la à partir de la console du terminal.

find /System/Library/Frameworks/Python.framework/Versions -name six.py*
19
galv

ainsi, la maquette 1.1.1 et supérieure définit une exigence de version sur six 1.7 ou supérieure:

https://github.com/testing-cabal/mock/blob/master/requirements.txt#L6

Cela est reflété dans les métadonnées de setuptools par pbr, pour lequel il existe une dépendance versionnée par setup_requires sur:

https://github.com/testing-cabal/mock/blob/master/setup.py#L17

Il y a donc plusieurs possibilités: 1) six 1.7 n’est pas assez nouveau 2) il existe un paquetage de la distribution six prétendant être 1.9.0 qui n’a pas de wraps pour une raison quelconque 3) le setuptools en cours d'utilisation n'a pas été correctement intégré à pbr et les dépôts sont manquants 4) les métadonnées de la roue ne sont pas interrogées correctement par votre combinaison pip/setuptools.

Nous avons une exigence stricte pour setuptools 17.1, et cela n’a été explicitement signalé que récemment par setup.py. J'adorerais si vous pouviez déterminer lequel de ces cas était le cas et mettre à jour https://github.com/testing-cabal/mock/issues/298 afin que nous puissions réparer les interactions qui mènent à ce silence échec de setup.py/wheel.

4
lifeless

Sur Mac OSX, la version précédemment installée de six bloquait l’utilisation de ma version mise à niveau. J'ai vérifié cela, comme suggéré précédemment, en exécutant ce qui suit dans mon interpréteur:

import six
six.__version__

Pour résoudre ce problème, j'ai déplacé le fichier: 

mv/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/six.py 
/tmp/old_six.py

Ceci est déjà indiqué dans une autre réponse sur ce site, mais je voulais fournir une réponse plus simple.

3
Control Complex

À l’origine, j’avais un problème avec les anciennes versions de «pip/setuptools» appartenant à l’OS. Après avoir installé pip manuellement, comme ceci:

wget https://bootstrap.pypa.io/get-pip.py
Sudo python get-pip.py
Sudo ln -s /usr/local/bin/pip /usr/bin/pip

Puis, en installant la dernière version de pip, mock et six, le problème que vous avez décrit ci-dessus demeurait. Il s'avère que j'en avais six installés deux fois dans:

/usr/lib/python2.7/dist-packages/

et en 

/usr/local/lib/python2.7/dist-packages/

Après avoir enlevé les six de/usr/lib/cela a bien fonctionné: rm /usr/lib/python2.7/dist-packages/*six*

2
VitalyB

J'ai fait une installation pip de six == 1.9.0 et il a fallu la nouvelle version. Il semble que mock == 1.3.0 ne définisse pas correctement la version de six dont il a besoin pour prendre en charge les enveloppes.

1
Jordan

Une autre solution consiste à configurer votre variable d’environnement PYTHONPATH pour qu’elle pointe vers les packages installés.

Paramétrer ma variable d’environnement dans ma configuration bash pour que:

PYTHONPATH=/Library/Python/2.7/site-packages

M'a permis d'exécuter des tests dans le terminal (sans supprimer/renommer les bibliothèques, etc.). 

Cependant, lors de l’utilisation de PyCharm, cette variable d’environnement n’était pas importée correctement. Même si PyCharm indiquait que les variables parentes étaient incluses (avec celles répertoriées dans celles importées), il semble que cette importation ne fonctionnait pas correctement.

La définition manuelle de la variable d'environnement sur celle indiquée ci-dessus dans la configuration d'exécution de PyCharm résout ce problème.

Je ne sais pas si PyCharm écrase la variable PYTHONPATH après l'avoir importée à partir de variables d'environnement système ou d'une autre supercherie, mais cela a résolu l'erreur pour moi.

1
enderland

J'ai trouvé des choses intéressantes! Il y a un fichier nommé "functools.py" dans le chemin racine de mon projet, et pendant que j'exécute mon projet, pycharm va générer ImportError . Je renomme donc mon fichier et corrige ce problème ~~

0
user9980897

Bien que vous n'utilisiez pas un environnement virtuel tel que virtualenv, c'est certainement un excellent cas d'utilisation. En mettant en sandbox votre installation Python et toutes les dépendances de votre projet, vous évitez de pirater l'installation Python global/par défaut, d'où provient en grande partie la complexité/difficulté. 

C’est ce que j’ai utilisé lors de l’erreur wraps - Requirements.txt contient mock==2.0.0 et six==1.10.0:

cd <my_project>
virtualenv venv
source venv/bin/activate
Sudo pip install -r requirements.txt

À mon avis, cette solution est non seulement plus simple à utiliser, mais elle est également plus simple à documenter pour les personnes souhaitant exécuter votre code.

0
killthrush