Какова лучшая структура проекта для приложения Python? [закрытый]

по словам Жан-Поля Кальдерона структура файловой системы проекта Python:

Project/
|-- bin/
|   |-- project
|
|-- project/
|   |-- test/
|   |   |-- __init__.py
|   |   |-- test_main.py
|   |   
|   |-- __init__.py
|   |-- main.py
|
|-- setup.py
|-- README

этой сообщение в блоге Жан-Поля Кальдерона обычно дается как ответ в #python на Freenode.

структура файловой системы проекта Python

Do:

• назовите каталог чем-то, связанным с вашим проектом. Например, если ваш проект называется "Twisted", назовите каталог верхнего уровня для его исходных файлов Twisted. Когда вы делаете выпуски, вы должны включить суффикс номера версии: Twisted-2.5.
• создать каталог Twisted/bin и поместите туда свои исполняемые файлы, если они у вас есть. Не давайте им

проверить откройте источник Проекта Python правильным образом.

позвольте мне извлечь макет проекта часть этой замечательной статьи:

при настройке проекта важно правильно настроить макет (или структуру каталогов). Разумный макет означает, что потенциальным участникам не придется вечно искать фрагмент кода; расположение файлов интуитивно понятно. Поскольку мы имеем дело с существующим проектом, это означает, тебе, наверное, придется кое-что переставить.

давайте начнем сверху. Большинство проектов имеют ряд файлов верхнего уровня (например setup.py читай.md, требования.txt, etc). Затем есть три каталога, которые должен иметь каждый проект:

• каталог документов, содержащий проектную документацию
• каталог с именем проекта, в котором хранится фактический пакет Python
• тестовый каталог в одном из двух мест
  • в каталоге пакета, содержащем тестовый код и ресурсы
  • как автономный каталог верхнего уровня Чтобы лучше понять, как должны быть организованы ваши файлы, вот упрощенный снимок макета для одного из моих проектов, sandman:

$ pwd
~/code/sandman
$ tree
.
|- LICENSE
|- README.md
|- TODO.md
|- docs
|   |-- conf.py
|   |-- generated
|   |-- index.rst
|   |-- installation.rst
|   |-- modules.rst
|   |-- quickstart.rst
|   |-- sandman.rst
|- requirements.txt
|- sandman
|   |-- __init__.py
|   |-- exception.py
|   |-- model.py
|   |-- sandman.py
|   |-- test
|       |-- models.py
|       |-- test_sandman.py
|- setup.py

Как вы можете видеть, есть некоторые файлы верхнего уровня, каталог docs (сгенерированный пустой каталог, где сфинкс поместит сгенерированный документация), каталог sandman и тестовый каталог под sandman.

"Python Packaging Authority" имеет sampleproject:

https://github.com/pypa/sampleproject

Это пример проекта, который существует как помощь в руководстве пользователя Python Packaging по упаковке и распространению проектов.

попробуйте запустить проект с помощью python_boilerplate шаблон. Он в основном следует лучшим практикам (например,здесь), но лучше подходит в случае, если вы обнаружите, что готовы разделить свой проект на более чем одно яйцо в какой-то момент (и поверьте мне, с чем угодно, кроме самых простых проектов, вы будете. Одна распространенная ситуация, когда вы должны использовать локально измененную версию чужого библиотека.)

• куда вы кладете источник?

  • на порядочно крупных проектов имеет смысл разделить источник на несколько яиц. Каждое яйцо будет идти как отдельный setuptools-макет под PROJECT_ROOT/src/<egg_name>.

• где вы положили запуске скриптов?

  • идеальным вариантом является наличие сценария запуска приложения, зарегистрированного в качестве entry_point in одно из яиц.

• куда вы помещаете проект IDE cruft?

  • зависит от IDE. Многие из них хранят свои вещи в PROJECT_ROOT/.<something> в корне проекта, и это нормально.

• где вы кладете блок / приемочные испытания?

  • каждое яйцо имеет отдельный набор тестов, хранящихся в его . Я лично предпочитаю использовать py.test запустить их.

• куда вы помещаете данные, отличные от Python, такие как файлы конфигурации?

  • это зависит. Могут быть разные типы данных, отличных от Python.
    • "ресурсы", т. е. сведения, которые должны быть упакованы в яйцо. Эти данные попадают в соответствующий каталог egg, где-то в пространстве имен пакета. Его можно использовать через pkg_resources пакет.
    • "Config-files", т. е. не-Python файлы, которые должны рассматриваться как внешние по отношению к исходным файлам проекта, но должны быть инициализированы с некоторыми значениями при запуске приложения. Во время разработки я предпочитаю хранить такие файлы в PROJECT_ROOT/config. Для развертывания могут быть различные варианты. В Windows можно использовать %APP_DATA%/<app-name>/config, в Linux /etc/<app-name> или /opt/<app-name>/config.
    • сгенерированные файлы, т. е. файлов, которые могут быть созданы или изменены приложение во время выполнения. Я бы предпочел оставить их в PROJECT_ROOT/var во время разработки, и при /var во время развертывания Linux.
• где вы помещаете источники не-Python, такие как C++ для модулей расширения pyd/so binary?
  • на PROJECT_ROOT/src/<egg_name>/native

документация обычно входит в PROJECT_ROOT/doc или PROJECT_ROOT/src/<egg_name>/doc (это зависит от того, рассматриваете ли вы некоторые из яиц быть отдельными крупными проектами). Некоторые дополнительные настройки будут в таких файлах, как PROJECT_ROOT/buildout.cfg и PROJECT_ROOT/setup.cfg.

по моему опыту, это просто вопрос итерации. Поместите свои данные и код туда, куда вы думаете. Скорее всего, вы все равно ошибетесь. Но как только вы получите лучшее представление о том, как обстоят дела в порядок, вы находитесь в гораздо лучшем положении, чтобы делать такие предположения.

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

с этими словами Я возвращаюсь к своей первоначальной точке: не делайте из этого слишком много. Положите его куда-нибудь, что, кажется, работает для вас. Если вы найдете что-то, что не работает, оно может (и должно) быть изменено.

данные, отличные от python, лучше всего упаковывать в модули Python с помощью package_data поддержка в setuptools. Одна вещь, которую я настоятельно рекомендую использовать пакеты пространств имен для создания общих пространств имен, которые могут использовать несколько проектов - так же, как соглашение Java о размещении пакетов в com.yourcompany.yourproject (и возможность иметь общий com.yourcompany.utils пространство имен).

повторное ветвление и слияние, если вы используете достаточно хорошую систему управления версиями, она будет обрабатывать слияния даже через переименования;базар особенно хорош в этом.

в отличие от некоторых других ответов здесь, я +1 на наличие src каталог верхнего уровня (с doc и test каталоги вместе). Конкретные соглашения для деревьев каталогов документации будут отличаться в зависимости от того, что вы используете;Сфинкс, например, имеет свои собственные соглашения, которые поддерживает его инструмент быстрого запуска.

пожалуйста, пожалуйста, используйте setuptools и pkg_resources; это делает для других проектов намного проще полагаться на определенные версии вашего кода (и для нескольких версий, которые будут одновременно установлены с разными файлами без кода, если вы используете package_data).