TLDR

这种方法不需要setuptools、路径hack、额外的命令行参数，也不需要在项目的每个文件中指定包的顶层。

只要在你调用的__main__的父目录中创建一个脚本，并从那里运行所有内容。进一步的解释请继续阅读。

解释

这可以在不使用新路径、额外的命令行参数或向每个程序添加代码来识别其兄弟程序的情况下完成。

这个失败的原因，我相信之前已经提到过，是被调用的程序将它们的__name__设置为__main__。当这种情况发生时，被调用的脚本接受自己位于包的顶层，并拒绝识别同级目录中的脚本。

但是，目录顶层下的所有内容仍然可以识别顶层下的任何其他内容。这意味着要让同级目录中的文件相互识别/利用，惟一需要做的就是从父目录中的脚本调用它们。

概念证明 在具有以下结构的目录中:

.
|__Main.py
|
|__Siblings
   |
   |___sib1
   |   |
   |   |__call.py
   |
   |___sib2
       |
       |__callsib.py

Main.py包含以下代码:

import sib1.call as call


def main():
    call.Call()


if __name__ == '__main__':
    main()

sib1 / call.py包含:

import sib2.callsib as callsib


def Call():
    callsib.CallSib()


if __name__ == '__main__':
    Call()

而sib2/ callsibb .py包含:

def CallSib():
    print("Got Called")

if __name__ == '__main__':
    CallSib()

如果你重现这个例子，你会注意到调用Main.py会导致“Got Called”被打印出来，就像在sib2/ callsibb .py中定义的那样，即使sib2/ callsibb .py是通过sib1/call.py调用的。但是，如果直接调用sib1/call.py(在对导入进行适当更改之后)，则会抛出异常。即使它在其父目录中被脚本调用时可以工作，但如果它认为自己位于包的顶层，它就不能工作。

厌倦了系统。路径黑客吗?

有很多可用的sys.path.append -hacks，但我发现了另一种解决问题的方法。

总结

将代码打包到一个文件夹中(例如packaged_stuff) 创建setup.py脚本，其中使用setuptools.setup()。(参见下面的minimal setup.py) 使用Pip install -e <myproject_folder>将包安装到可编辑状态 从packaged_stuff导入using。Modulename import function_name

---

设置

起点是您提供的文件结构，包装在名为myproject的文件夹中。

.
└── myproject
    ├── api
    │   ├── api_key.py
    │   ├── api.py
    │   └── __init__.py
    ├── examples
    │   ├── example_one.py
    │   ├── example_two.py
    │   └── __init__.py
    ├── LICENCE.md
    ├── README.md
    └── tests
        ├── __init__.py
        └── test_one.py

我会打电话给。在我的例子中，它位于C:\tmp\test_imports\。

api.py

作为测试用例，让我们使用下面的./api/api.py

def function_from_api():
    return 'I am the return value from api.api!'

test_one.py

from api.api import function_from_api

def test_function():
    print(function_from_api())

if __name__ == '__main__':
    test_function()

尝试运行test_one:

PS C:\tmp\test_imports> python .\myproject\tests\test_one.py
Traceback (most recent call last):
  File ".\myproject\tests\test_one.py", line 1, in <module>
    from api.api import function_from_api
ModuleNotFoundError: No module named 'api'

尝试相对导入也不会起作用:

使用from ..api。API导入函数from_api的结果为

PS C:\tmp\test_imports> python .\myproject\tests\test_one.py
Traceback (most recent call last):
  File ".\tests\test_one.py", line 1, in <module>
    from ..api.api import function_from_api
ValueError: attempted relative import beyond top-level package

---

步骤

创建一个setup.py文件到根目录

---

setup.py的内容是*

from setuptools import setup, find_packages

setup(name='myproject', version='1.0', packages=find_packages())

使用虚拟环境

---

如果您熟悉虚拟环境，请激活一个，然后跳转到下一步。使用虚拟环境并不是绝对必需的，但从长远来看，它们确实会帮助你(当你有多个正在进行的项目时)。最基本的步骤是(在根文件夹中运行)

创建虚拟环境 Python -m venv venv 激活虚拟环境 ./venv/bin/activate (Linux, macOS)或./venv/Scripts/activate (Win)

要了解更多信息，请参考谷歌“python virtual env tutorial”或类似内容。除了创建、激活和取消激活之外，您可能永远不需要任何其他命令。

创建并激活虚拟环境后，控制台应该在括号中给出虚拟环境的名称

PS C:\tmp\test_imports> python -m venv venv
PS C:\tmp\test_imports> .\venv\Scripts\activate
(venv) PS C:\tmp\test_imports>

你的文件夹树应该看起来像这样**

.
├── myproject
│   ├── api
│   │   ├── api_key.py
│   │   ├── api.py
│   │   └── __init__.py
│   ├── examples
│   │   ├── example_one.py
│   │   ├── example_two.py
│   │   └── __init__.py
│   ├── LICENCE.md
│   ├── README.md
│   └── tests
│       ├── __init__.py
│       └── test_one.py
├── setup.py
└── venv
    ├── Include
    ├── Lib
    ├── pyvenv.cfg
    └── Scripts [87 entries exceeds filelimit, not opening dir]

PIP在可编辑状态下安装项目

---

使用pip安装你的顶级包myproject。诀窍是在进行安装时使用-e标志。通过这种方式，它被安装在可编辑状态下，对.py文件的所有编辑都将自动包含在已安装的包中。

在根目录下运行

PIP install -e。(注意这个点，它代表“当前目录”)

您还可以看到它是通过使用pip freeze安装的

(venv) PS C:\tmp\test_imports> pip install -e .
Obtaining file:///C:/tmp/test_imports
Installing collected packages: myproject
  Running setup.py develop for myproject
Successfully installed myproject
(venv) PS C:\tmp\test_imports> pip freeze
myproject==1.0

添加。。导入文件中

---

注意，您必须添加myproject。只能输入到其他无法工作的输入中。没有setup.py和pip安装的导入仍然可以正常工作。请参见下面的示例。

---

测试解决方案

现在，让我们使用上面定义的api.py和下面定义的test_one.py测试解决方案。

test_one.py

from myproject.api.api import function_from_api

def test_function():
    print(function_from_api())

if __name__ == '__main__':
    test_function()

运行测试

(venv) PS C:\tmp\test_imports> python .\myproject\tests\test_one.py
I am the return value from api.api!

---

*查看setuptools文档获取更多详细的setup.py示例。

**在现实中，您可以将虚拟环境放在硬盘上的任何地方。

七年之后

由于我把答案写在下面，修改sys.;Path仍然是一种快速而肮脏的技巧，适用于私有脚本，但是已经有了一些改进

安装包(在virtualenv中或不在virtualenv中)会给你想要的，尽管我建议使用pip来完成，而不是直接使用setuptools(并使用setup.cfg存储元数据) 使用-m标志并作为包运行也可以(但是如果您想将工作目录转换为可安装包，则会有点尴尬)。 具体来说，对于测试，pytest能够在这种情况下找到api包，并负责sys. exe。给你的路径技巧

所以这取决于你想做什么。但是，在您的情况下，由于您的目标似乎是在某种程度上制作一个适当的包，因此通过pip -e安装可能是您的最佳选择，即使它还不完美。

旧的答案

正如在其他地方已经说过的，可怕的事实是，你必须做一些丑陋的hack来允许从__main__模块的兄弟模块或父包导入。该问题在PEP 366中有详细说明。PEP 3122试图以更合理的方式处理导入，但Guido拒绝了它

唯一的用例似乎是运行发生的脚本 在一个模块的目录中，我总是把它看作一个 反模式。

(在这里)

不过，我经常使用这种模式

# Ugly hack to allow absolute import from the root folder
# whatever its name is. Please forgive the heresy.
if __name__ == "__main__" and __package__ is None:
    from sys import path
    from os.path import dirname as dir

    path.append(dir(path[0]))
    __package__ = "examples"

import api

这里的路径[0]是运行脚本的父文件夹，目录(路径[0])是顶级文件夹。

虽然我还不能使用相对导入，但它确实允许从顶层(在示例api的父文件夹中)进行绝对导入。

存在的问题:

你只是不能让import mypackage在test.py中工作。你将需要一个可编辑的安装，改变到路径，或改变__name__和路径

demo
├── dev
│   └── test.py
└── src
    └── mypackage
        ├── __init__.py
        └── module_of_mypackage.py

--------------------------------------------------------------
ValueError: attempted relative import beyond top-level package

解决方案:

import sys; sys.path += [sys.path[0][:-3]+"src"]

在尝试在test.py中导入之前，请将上述内容放在上面。这是它。你现在可以导入mypackage了。

这在Windows和Linux上都可以工作。它也不会关心从哪个路径运行脚本。它足够短，可以拍打任何你需要它的地方。

为什么有效:

The sys.path contains the places, in order, where to look for packages when attempting imports if they are not found in installed site packages. When you run test.py the first item in sys.path will be something like /mnt/c/Users/username/Desktop/demo/dev i.e.: where you ran your file. The oneliner will simply add the sibling folder to path and everything works. You will not have to worry about Windows vs Linux file paths since we are only editing the last folder name and nothing else. If you project structure is already set in stone for your repository we can also reasonably just use the magic number 3 to slice away dev and substitute src

在主文件中添加以下内容:

import sys
import os 
sys.path.append(os.path.abspath(os.path.join(__file__,mainScriptDepth)))

mainScriptDepth =主文件从项目根目录的深度。

这是你的案例mainScriptDepth = "../../"。然后，您可以通过指定路径(从api。API import *)从你的项目的根。

首先，您应该避免使用与模块本身同名的文件。它可能会破坏其他导入。

当你导入一个文件时，解释器首先检查当前目录，然后搜索全局目录。

在示例或测试中，您可以调用:

from ..api import api