Как организовать удобную разработку Django пакета (батарейки)?

Question

[Руслан Гильфанов]

Git-репозиторий многих Django пакетов содержит:

• директорию с пакетом
  
• директорию с примером (example)
  

Пример, представляет из себя простой Django проект, в котором разработчики проверяют функциональность разрабатываемого пакета.

В settings.py примера, пакет просто указан в INSTALLED_APPS.

Получается, что при работе над пакетом -- его необходимо установить в виртуальное окружение. А затем, чтобы пример работал с актуальной версией пакета, очень часто переустанавливать:
python3 setup.py install --force

Какие есть альтернативы?

1. Добавить директорию пакета в пути импорта Python. Недостатки:

• Корректная работа примера ничего не будет говорить о корректности установки пакета через setup.py. Если при этом забыть что-то прописать в MANIFEST.ini, можно пропустить неработающую версию в ветку master.
  
• Не совсем понятно, в каком файле примера лучше модифицировать пути импорта -- в settings.py или в manage.py
  

2. Сделать автоматическую переустановку пакета после каждого изменения. Недостатки:

• Автоматический setup.py install --force при каждой мелкой правке кажется избыточным. Это всё равно что автоматический manage.py collectstatic при каждой мелкой правке -- перезапись массы файлов по поводу и без.
  
• Придётся рыться в исходниках Django в поисках реализации отслеживания изменений файлов и автоперезапуска dev-сервера, а потом видимо monkey patch`ить Django.
  

Собственно, разработчики батареек для Django, поделитесь опытом ;-)

Answer 1

[Руслан Гильфанов]

Сергей Горностаев предложил использовать tox, а в документации этого инструмента я наткнулся на более простое и удобное решение.

В документации setuptools есть раздел Development mode.

Если вместо команды install использовать команду develop
python3 setup.py develop
пакет не будет собран и полноценно установлен в глобальное или виртуальное окружение.

Вместо этого, в глобальном или виртуальном окружении будет создана ссылка на исходники пакета (ссылка представляет собой файл с расширением .egg-link).

После этого, пакет становится доступен для импорта.

Если импортировать такой пакет в Django-проект, сделать manage.py runserver и начать редактировать исходники пакета -- встроенный в Django сервер для разработки как обычно перезапускается при каждом сохранении исходников пакета. Хотя импортированный пакет может лежать где угодно в файловой системе.

Таким образом, работая над батарейкой для Django -- можно тут же видеть изменения в запущенном Django-проекте, без необходимости переустанавливать батарейку после каждой правки её исходников.

Спасибо, проблема решена просто, дёшево и элегантно.

P.S. Предложенная Сергеем библиотека tox больше подходит для автоматизации тестирования Python проекта во множестве разных рабочих окружений. Например, если Вы гарантируете пользователям поддержку разных версий требуемых библиотек, разных версий интерпретатора, разных интерпретаторов и т.д. -- tox может серьёзно облегчить Вам жизнь.

P.P.S. Если кто-то не знает как пользоваться setuptools и создавать установочные файлы для своих Python пакетов -- есть статьи и даже видео на русском языке. Например:

• Игорь Стариков -- Декларативное конфигурирование пакетов Python (видео от января 2017).
  
• IT Screen -- Регистрация пакета на PyPi (статья от декабря 2016)
  

Answer 2

[Сергей Горностаев]

Использовать tox.

Comments

[Руслан Гильфанов]

Сергей Горностаев, благодарю за ссылку. Смотрю, он очень много всего умеет.

Ищу пример для моего случая и как-то теряюсь.

Например, чтобы при изменении исходников батарейки:

• батарейка переустанавливалась в виртуальное окружение
  
• example перезапускался
  

Нашёл в документации tox упоминание команды setup.py develop -- полез в документацию setuptools.

Вроде то, что нужно даёт и setuptools:

To do this, use the setup.py develop command. It works very similarly to setup.py install or the EasyInstall tool, except that it doesn’t actually install anything. Instead, it creates a special .egg-link file in the deployment directory, that links to your project’s source code. And, if your deployment directory is Python’s site-packages directory, it will also update the easy-install.pth file to include your project’s source code, thereby making it available on sys.path for all programs using that Python installation.

Как я понимаю, через setup.py можно не только полноценно устанавливать пакет, но и просто создавать в site-packages ссылку на исходники разрабатываемого пакета, освобождая разработчиков от необходимости постоянно его переустанавливать.

Сегодня-завтра проверю как это работает.

Если и функционал setuptools меня устроит, отмечу ваш ответ решением -- так как Вы подтолкнули меня к ответу. Ну и tox может позднее пригодится.

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

[Сергей Горностаев]

Руслан Гильфанов, не всегда есть время на развёрнутый ответ, работа отвлекает :)