2012-05-05 54 views
2

我有一个Django的结构是这样的(只显示库):全局/应用程序文件夹的lib导入在Django

project/lib/ # Global libraries that will be used cross apps 
project/lib/global_stuff.py 
project/apps/app1/lib/special_for_app1.py 
project/apps/app2/lib/special_for_app2.py 

一些应用程序没有一个lib文件夹。

from apps.app1.lib import special_for_app1工作正常。但是当我在已经包含本地lib文件夹的文件夹中时,如何从全局lib文件夹导入?

从应用程序内的views.py在应用程序的一个文件:


from lib import global_stuff 

给我ImportError: cannot import name global_stuff


从进口的.lib global_stuff

给我ImportError: cannot import name global_stuff


from ..lib import global_stuff 

给我ImportError: No module named lib


from ...lib import global_stuff 

给我ValueError: Attempted relative import beyond toplevel package


from project.lib import global_stuff 

的作品,但我真的不希望使用项目名称本身被卡住在im港口。


有没有什么办法可以解决这个问题,而不是在导入中使用项目名称,或者改变整个lib的想法。

或者是否有任何其他良好的做法来存储代码的主要部分?

+0

您是否确保每个目录都有一个'__init __。py'?你有没有把“/ path/to/project”放到你的PYTHONPATH中? – rantanplan

+0

是的,每个目录都有一个__init__.py,并且sys.path中的第一个条目是项目目录。 – xeor

回答

4

你是正确的不想要的项目名称与进口相关联,所以有一个共同的模式来此:

project/ 
    |__/source/ 
    |  |__/lib/ 
    |  |__/app/ 
    |__/deployment/ # code for your production deployment maybe 
    | 
    |__/docs/ 
    |__/tests/ 
    |__README 
    |__requirements.txt 

,并把/路径/要/你的路内的项目在您的virtualenv(你使用virtualenv吧?)。

然后你可以在你的代码里做

from source.lib.blah import foo 
from source.app.baz import bar 

编辑:这是唯一的最佳的,如果你不释放你的代码,当然作为开源。只有当您有一个内部项目时,管理层不断更改项目名称:D

+0

是的,virtualenv和heroku和你指出的结构。但不是称为目录源,而是将其称为项目名称本身。也许我应该重新命名它。 – xeor

+0

我希望你读我的编辑!如果你打算在社区发布它,你最好坚持一个项目名称!想象一下,有人把你的项目作为第三方应用程序,并从源代码进行引用。不好:) – rantanplan

+0

是的,我读过它,“幸运地”我不能将它作为一个开源项目发布。然而,“源”作为名称对我来说看起来有点不对劲,但是非常有用。让我知道如果你想出一个更好的名字:) – xeor

3

我真的不希望在进口

为什么不使用项目名称本身被卡住?这是最好的方式。请注意,“内包装进口的相对进口非常令人沮丧”, - said in PEP-8

+0

我希望它尽可能便携,即使在重命名项目时也是如此。这就是为什么我看到在导入中使用项目名称作为最后的手段。 – xeor

+2

@xeor如果你想要一个应用程序是可移植的,你不能依赖项目的数据。将'global_stuff'移动到应用程序的文件夹中,或者制作'global_stuff'另一个应用程序并添加'requirements.txt'。 – DrTyrsa

+0

核心应用程序创建:)感谢您的想法 – xeor

相关问题