Python Django中的全局/应用程序库文件夹导入

我有这样一个Django结构（只显示libs）：

有些应用没有lib文件夹

从apps.app1.lib为app1导入特殊的\u

工作正常。但是，当我在已经包含本地lib文件夹的文件夹中时，如何从全局lib文件夹导入

从其中一个应用上的apps views.py文件内部：

---

给我

ImportError:无法导入名称全局\u内容

---

从.lib导入全局_内容

给我

ImportError:无法导入名称全局\u内容

---

给我

导入错误：没有名为lib的模块


给我
ValueError:尝试在顶级包之外进行相对导入


工作，但我真的不想被困在使用项目名称本身的导入


有没有办法解决这个问题，不在导入中使用项目名称，或者改变整个库的想法

或者是否有其他良好的实践来存储代码的主要部分

我真的不想在导入中使用项目名称本身

为什么不呢？这是最好的办法。请注意，“非常不鼓励包内导入的相对导入”-正如。
您不希望将项目名称与导入关联是正确的，因此有一种常见的模式：

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

并将/path/to/project放在virtualenv上的路径中（您使用virtualenv对吗？）

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

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

编辑：当然，只有当您不以开源的形式发布代码时，这才是最佳选择。只有当管理层不断更改项目名称的内部项目：D
时，您才确保每个目录都有一个
\uuuu init\uuuuuuuuuuuuuuuuuuuuuuuupy
？您是否已将“/path/to/project”放在PYTHONPATH中？是的，每个目录都有一个init.py，sys.path中的第一个条目是项目目录。我希望它尽可能可移植，即使在重命名项目时也是如此。这就是为什么我认为在导入中使用项目名称是万不得已的办法。@Xe或者如果您希望应用程序是可移植的，那么您不能依赖于项目的数据。将
global_stuff
移动到应用程序的文件夹中，或制作另一个应用程序并添加
requirements.txt
。创建了一个核心应用程序：）感谢ideaYes、virtualenv和heroku以及您指出的结构。但是我没有称之为目录源，而是将其称为项目名称本身。也许我应该把它重命名。我希望你能读我的编辑！如果你计划在社区发布它，你最好坚持一个项目名称！想象一下，有人将您的项目作为第三方应用程序，并从源代码导入blah执行
。不好：）是的，我读过，而且“幸运的是”我不能把它作为一个开源项目发布。“source”这个名字在我看来有点错误，但是非常有用。如果你能给我起个更好的名字，请告诉我：）我是世界上最不喜欢命名东西的人：）我通常把这个目录称为“src”，因为它可以键入的东西更少。更好的名称应该是描述其用途的名称。例如，如果它是一个RESTful web服务，您可以调用该文件夹
rest
+我的想象力是：D
from ..lib import global_stuff

from ...lib import global_stuff

from project.lib import global_stuff

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

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