module python dans virtualenv

Question

J'utilise python dans virtualenv. J'ai le module suivant :

offers/couchdb.py :

from couchdb.client import Server

def get_attributes():
    return [i for i in Server()['offers']]

if __name__ == "__main__":
    print get_attributes()

Quand je l'exécute à partir du fichier, j'obtiens :

$ python offers/couchdb.py
Traceback (most recent call last):
  File "offers/couchdb.py", line 1, in <module>
    from couchdb.client import Server
  File "/Users/bartekkrupa/D/projects/commercial/echatka/backend/echatka/offers/couchdb.py", line 1,     in <module>
    from couchdb.client import Server
ImportError: No module named client

Mais quand je le colle dans l'interpréteur... ça marche :

$ python
Python 2.7.2 (default, Jun 20 2012, 16:23:33) 
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from couchdb.client import Server
>>> 
>>> def get_attributes():
...     return [i for i in Server()['offers']]
... 
>>> if __name__ == "__main__":
...     print get_attributes()
... 

Quelle est la raison pour laquelle python qui exécute ce module à partir d'un fichier ne charge pas le module couchdb, alors que l'exécution dans le REPL le fait ?

Answer 1

Vous êtes tombé sur un défaut de fonctionnement : importations relatives . Quand vous dites from couchdb.client... Python recherche d'abord un module sous le nom de offers. qui s'appelle couchdb . Et il en trouve un : le fichier sur lequel vous travaillez, offers/couchdb.py ¡!

La solution habituelle consiste à désactiver ce comportement, qui a disparu dans Python 3 de toute façon. Mettez ceci comme première ligne de code Python dans votre fichier :

from __future__ import absolute_import

Python supposera alors que vous voulez importer depuis un module de premier niveau nommé couchdb (ce que vous faites), et non pas un frère ou une soeur du module actuel.

Malheureusement, dans ce cas, vous exécutez le fichier directement, et Python ajoutera toujours offers/ à son chemin de recherche. Lorsque vous exécutez un fichier destiné à être un module, vous pouvez le lancer avec -m :

python -m offers.couchdb

Maintenant, ça devrait fonctionner.

(Vous pourriez, bien sûr, ne pas nommer votre fichier couchdb.py . Mais je trouve qu'il est assez utile d'avoir des modules nommés d'après la chose avec laquelle ils interagissent ou qu'ils enveloppent).

Answer 2

Edita: Voir la réponse d'Eevee ci-dessus - je pense qu'elle convient mieux. Néanmoins, cela pourrait être utile pour d'autres personnes ( ?):

Peut-être n'avez-vous pas installé couchdb dans votre virtualenv ? Cela pourrait expliquer pourquoi il fonctionne dans l'interpréteur (si l'interpréteur est no lancé à partir du virtualenv.

Soit l'installer là, soit créer le virutalenv avec --site-packages.