如何在不中断上层导入的情况下从子目录运行 Python 脚本？

Question

I have a very simple scenario like this:

example/
    common.py
    folder1/
        script.py

where script.py file should import common.py module.

If I cd into folder1/ and run the script (ie by calling python3 script.py on the command line), the import breaks with the usual error ModuleNotFoundError: No module named 'common' .

I know I could turn the whole parent folder into a package by adding __init__.py files in each subdirectory, however this solution still prevents me to run the script directly from inside folder1/ .

How can I fix this?

Answer 1

If you need to add a parent directory to the search path, you can always do:

import os
import sys

DIR = os.path.dirname(os.path.dirname(os.path.realpath(__file__))
sys.path.insert(0, DIR)

os.path.realpath(__file__) gets the realpath to the file, and os.path.dirname gets the directory name of this file. Doing it twice gets the example directory here. Now, since this is added to the search path, you can import common .

However, you should really consider having a dedicated scripts or bin directory, rather than try to run scripts from subdirectories. Think about writing a library, and import this library rather than individual files.

Answer 2

如果将两个目录都转换为python包，并且顶层目录在PYTHONPATH中，则可以像这样运行script.py：

python3 -m example.folder1.script

Answer 3

import importlib.util
spec = importlib.util.spec_from_file_location("module.name", "/path/to/file.py")
foo = importlib.util.module_from_spec(spec)
spec.loader.exec_module(foo)
foo.MyClass()

Answer 4

from folder1.script import ....

If it were that simple, we'd probably be doing it, but that's unfortunately not how Python's going to go load the code either.

The way modules are laid out can mean they are imported differently in different versions of Python. Namepsace packages change this behavior as well, where multiple completely different directories can provide modules underneath other modules. A file being run as a script means its sys.path changes. pth files can modify paths even more. If we go start looking for imports up and up and up, we'll eventually start leaving the workspace and scanning through the drive (which has bad implications). One name could end up meaning two things in two different places, which has its own bad implications in our analysis (persistence, for one, along with other things). All of these mean we have to make tradeoffs for what behavior we want/can feasibly do; we could be very, very loose, but then you may go to run the code and it break and you'd wonder why the editor didn't tell you something was wrong beforehand.