Каков надлежащий способ работы с общими модулями в разработке Python?

Ответ 1

Обязательно прочитайте этот материал:

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

если вы его не видели (и следуйте ссылке во втором ответе).

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

myproject-0.1/
    myproject/
        framework/
    packageA/
        sub_package_in_A/
            module.py
    packageB/
        ...

Затем и вы (в пределах ваших других пакетов), и ваши пользователи могут импортировать как:

import myproject
import packageA.sub_package_in_A.module

и т.д.

Это означает, что вы должны думать о комментарии @MattAnderson, но если вы хотите, чтобы он отображался как отдельно распространяемый пакет, он должен быть в верхнем каталоге.

Примечание. Это не мешает вам (или вашим пользователям):

import packageA.sub_package_in_A as sub_package_in_A

но это не позволяет вам разрешить:

import sub_package_in_A

непосредственно.

Ответ 2

Я думаю, что это лучшая ссылка для создания дистрибутивного пакета python:

ссылка удалена, поскольку она приводит к взлому сайта.

также не чувствуйте, что вам нужно вложить все в одну директорию. Вы можете делать такие вещи, как

platform/
    core/
        coremodule
    api/
        apimodule

а затем выполните следующие действия: from platform.core import coremodule и т.д.

Ответ 3

Если у вас есть общий код, который вы хотите разделить между несколькими проектами, возможно, стоит подумать о сохранении этого кода в физически отдельном проекте, который затем импортируется как зависимость в другие ваши проекты. Это легко сделать, если вы размещаете свой общий проект кода в github или bitbucket, где вы можете использовать pip для его установки в любом другом проекте. Этот подход не только помогает вам легко обмениваться общим кодом в нескольких проектах, но также помогает защитить вас от непреднамеренного создания плохих зависимостей (т.е. Тех, которые направлены из вашего общего кода на ваш не общий код).

Приведенная ниже ссылка представляет собой хорошее введение в использование pip и virtualenv для управления зависимостями, определенно стоит прочитать, если вы и ваша команда довольно новичок в работе с python, поскольку это очень распространенная инструментальная цепочка, используемая для такого рода проблем:

http://dabapps.com/blog/introduction-to-pip-and-virtualenv-python/

И приведенная ниже ссылка показывает, как тянуть зависимости от github с помощью pip:

Как использовать программное обеспечение для установки Python Pip, вытягивать пакеты из Github?

Ответ 4

... кажется, что существует предположение, что все ссылочные пакеты находятся ниже папки проекта верхнего уровня, а не залога.

Это главным образом потому, что текущий рабочий каталог является первой записью в sys.path по умолчанию, что очень удобно импортировать модули и пакетов ниже этого каталога.

Если вы удалите его, вы даже не сможете импортировать материал из текущего рабочего каталога...

$ touch foo.py
$ python
>>> import sys
>>> del sys.path[0]
>>> import foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named foo

Мне также показалось, что, возможно, правильный подход разработать общие/базовые модули в отдельном проекте, и один раз тестировать, развертывать их для каждой среды разработчика, установив папка сайтов-пакетов.

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

Однако это также вызывает вопрос о распределении вопросов.

Здесь ситуация может немного усложниться, но только если вы планируете выпускать библиотеки независимо от тех проектов, которые их используют, и/или с несколькими установщиками проектов используют одни и те же библиотеки. В этом случае посмотрите distutils.

Если нет, вы можете просто использовать те же относительные пути, которые используются в разработке, чтобы гарантировать, что проект работает "из коробки".