Совместное использование модулей python между приложениями с дополнительными модулями git или svn: externals

В нашей компании мы используем подрывную деятельность. У нас есть разные модули python (собственные и сторонние) в разных используемых версиях. Различные приложения, которые мы разрабатываем, имеют разные зависимости от версии разделяемых модулей.

Одна из возможностей – использовать virtualenv установки модулей с локального сервера pypi. Поэтому при каждой первоначальной проверке нам нужно создать виртуальную машину, активировать ее и установить зависимые модули из требования .txt.

Недостатки:

  • Относительно сложная операция для простой задачи, такой как проверка и запуск
  • У вас есть возможность пропустить создание virtualenv и работу с модулями, установленными в сайтах-пакетах
  • Необходимость для локального сервера pypi (хорошо, иначе вы можете использовать URL-адреса, указывающие на ваш vcs)

Итак, мы пришли к другому решению, и я прошу вашего мнения. На пути к приложению мы используем svn: externals (aka git subodules) для «ссылки» на указанный модуль (из его пути выпуска и с указанным номером ревизии, чтобы сохранить это только чтение), поэтому модуль будет размещен локально на пути к приложению. «Импорт mylib» будет работать так, как он был установлен на сайтах python или в virtualenv. Это может быть расширено, чтобы даже выпустить выпуск wx, numpy и других часто используемых библиотек в наш репозиторий и связать их локально.

Преимущества:

  • После первоначальной проверки ваш готовый к запуску (действительно важный момент для меня)
  • версии зависимы (например, требования.txt)

Фактический вопрос: Существуют ли проекты на github / sorceforge, используя эту схему? Почему все используют virtualenv вместо этой (по-видимому) более простой схемы? Я никогда не видел такого решения, так что, возможно, мы пропустили точку?

PS: Я разместил это уже в списке рассылки pypa-dev, но, похоже, это неправильное место для такого вопроса. Пожалуйста, извините эту перекрестную почту.

На пути к приложению мы используем svn: externals (aka git subodules) для «ссылки» на указанный модуль (из его пути выпуска и с указанным номером ревизии, чтобы сохранить его только для чтения), поэтому модуль будет помещен локально в путь приложения.

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

После первоначальной проверки вы готовы к запуску

… это не совсем так. Если одна из ваших зависимостей – это библиотека Python, написанная на C, ее нужно сначала скомпилировать.


Мы попробовали его с функциональными возможностями субмодуля git, но невозможно получить подпуть репозитория (например, /source/lib )

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

Например, с макетом, как …

 myproject |- bin | |- myprogram.py | |- lib | |- mymodule.py | |- mypackage | | |- __init__.py | | | |- foopackage -> ../submodules/libfoo/lib/foopackage | |- barmodule | |- __init__.py -> ../../submodules/libbar/lib/barmodule.py | |- submodules |- libfoo | |- bin | |- lib | |- foopackage | |- __init__.py | |- libbar |- bin |- lib | barmodule.py 

… вам нужен только my_project/lib в PYTHONPATH , и все должно импортироваться правильно.


Существуют ли проекты на github / sourceforge, используя эту схему?

Информация о подмодулях просто хранится в файле с именем .gitmodules , а быстрый Google для «site: github.com .gitmodules» возвращает немало результатов.


Почему все используют virtualenv вместо этой (по-видимому) более простой схемы?

Для пакетов, опубликованных в PyPI , и установленных с помощью pip , это, возможно, проще с точки зрения управления зависимостями.

Если ваше программное обеспечение имеет относительно простой граф зависимостей, например …

 myproject |- libfoo |- libbar 

… это неважно, но когда это становится больше …

 myproject |- libfoo | |- libsubfoo | |- libsubsubfoo | |- libsubsubsubfoo | |- libsubsubsubsubfoo |- libbar |- libsubbar1 |- libsubbar2 |- libsubbar3 |- libsubbar4 

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


В вашем конкретном случае решение о том, будет ли ваше решение правильным, будет зависеть от ответов на вопросы:

  1. Все внешние модули, которые вам нужно использовать, действительно доступны из репозиториев svn ?
  2. Правильно ли эти репозитории используют svn:externals чтобы включить совместимые версии любых зависимостей, которые им требуются, или если нет, готовы ли вы взять на себя ответственность за управление этими зависимостями самостоятельно?

Если ответ на оба вопроса «да», то ваше решение, вероятно, подходит для вашего дела.