Что такое * простой * способ структурирования проекта python?

Question

Итак, у меня есть эта вещь python, которая должна обрабатывать файл.

Сначала это было:

my_project/ 
├── script.py 

И я бы просто запустить его с python script.py file.csv.

Потом он вырос и стал:

my_project/ 
├── script.py 
├── util/ 
│ └── string_util.py 
├── services/ 
│ └── my_service.py 

(Существует в каждом каталоге пустой __init__.py)

Но теперьmy_service.py хотел бы использовать string_util.py и это так черт не просто, как это сделать.

Я хотел бы сделать from ..util import string_util в my_service.py (который импортируется в script.py с from services import my_service), но это не работает с python script.py так my_service «s __name__ тогда только services.my_service (и я получаю Attempted relative import beyond toplevel package)

• я могу сделать cd .. и python -m my_project.script, но это кажется таким неестественным, и было бы очень сложно помещать его в README для получения инструкций по его запуску.

• Прямо сейчас я решаю его с уродливым sys.path.append() взломом.

Какие еще варианты у меня есть?

Answer 1

Это граничит с мнением, но я поделюсь своим мнением об этом.

Вы должны посмотреть на свой проект по-другому. Выберите одну контрольную точку и укажите там свой импорт, чтобы избежать всех нечетных относительных импортов, которые вы пытаетесь обойти. Так, глядя на структуре проекта:

my_project/ 
├── script.py 
├── util/ 
│ └── string_util.py 
├── services/ 
│ └── my_service.py 

Как вы сейчас делаете, выполнить свой код внутри my_project. Таким образом, весь ваш импорт должен быть относительно этой точки. Таким образом, ваши импорта фактически выглядеть следующим образом:

# my_service.py 

from util.string_util import foo 

Другой способ думать об этом, в том, что если вы движетесь ваш проект вокруг, или есть CI, вы должны убедиться, что вы указали, что это корень проекта вы хотите выполнить. Помня об этих вещах и указав единую точку выполнения, в которой должен быть выполнен ваш проект, значительно упростится ваша жизнь, когда дело касается структурирования ваших пакетов и модулей и ссылки на них соответствующим образом, позволяя другим системам правильно использовать ваш проект без необходимости иметь дело с нечетным относительным импортом.

Надеюсь, это поможет.