ri_gilfanov
@ri_gilfanov
Web- and desktop-developer

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

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, поделитесь опытом ;-)
  • Вопрос задан
  • 191 просмотр
Решения вопроса 2
  • ri_gilfanov
    @ri_gilfanov
    Web- and desktop-developer
    Сергей Горностаев предложил использовать 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 пакетов -- есть статьи и даже видео на русском языке. Например:
    Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы