Подтвердить что ты не робот

Как включить предварительные приложения в INSTALLED_APPS

У меня есть приложение Django, которое я создаю, назовем foo.

Из-за того, как Foo построен, для него требуется несколько сторонних приложений django. Например, для запуска foo приложения для установки могут выглядеть так:

INSTALLED_APPS = ('prereq1',prereq2','foo')

Фактически, для foo для того, чтобы быть функциональным, 'prereq1', prereq2' необходимо установить в django. Теперь я могу добавить требования к requirements.txt или setup.py, чтобы убедиться, что библиотеки установлены, когда кто-то идет на установку foo, но я не могу понять, есть ли способ установить их в самом Django.

Причиной этого является то, что если кто-то хочет использовать Foo, я не хочу включать такие инструкции, как:

В INSTALLED_APPS добавить foo, а также добавить scary_looking_library_name и thing_you_dont_understand.

Итак, возможно ли приложение в INSTALLED_APPS каким-то образом потребовать или добавить дополнительные приложения в этот список?

4b9b3361

Ответ 1

Я согласен с ответом Даниэля Розмана о системе проверки фреймворка, который является оптимальным местом для этих проверок. Была введена система проверки фреймов Django 1.7.

Однако, если у вас есть документация, вы также можете документировать эти предварительные условия, такие как Django REST Framework в своих инструкциях по установке.

Затем вы можете сделать что-то вроде кода ниже (django-mptt, используемого в качестве примера):

try:
    from mptt.fields import TreeForeignKey
    from mptt.models import MPTTModel
except ImportError:
    raise ImportError(
        'You are using the `foo` app which requires the `django-mptt` module.'
        'Be sure to add `mptt` to your INSTALLED_APPS for `foo` to work properly.'
)

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

Возможно, это нежелательное/ненужное мнение, но инъекция зависимостей в INSTALLED_APPS не является чем-то, что я чувствую, что вы должны обращаться с вашим приложением.

Обычно я стараюсь следовать Zen of Python при разработке приложений:

  • "Явный лучше, чем неявный".
    • Попросите разработчика вручную ввести зависимости в INSTALLED_APPS
  • "Если внедрение сложно объяснить, это плохая идея".
    • Попытка выяснить способ инъекции зависимостей в INSTALLED_APPS трудно объяснить. Если взаимозависимости третьей стороны сложны, пусть разработчик решает.
  • "Простой лучше, чем сложный".
    • Легче документировать зависимости и требовать от разработчика добавить их в INSTALLED_APPS.
  • "Должен быть один - и желательно только один - простой способ сделать это".
    • Общая практика заключается в том, чтобы разработчик добавлял сторонние приложения к INSTALLED_APPS - вот почему нет очевидного способа делать то, что вы хотите (инъекция).

Если разработчик хочет активировать приложение, они будут. Как вы так красноречиво указали в своем примере, scary_looking_library_name и thing_you_dont_understand несут ответственность разработчика за понимание. Выбор для установки для разработчика создает ненужный риск для безопасности. Пусть разработчик решит использовать ваше приложение и инициализировать его зависимости.

Ответ 2

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

Ответ 3

Я предпочитаю выполнять проверку зависимостей, однако, я думаю, вы требуете, чтобы приведенный ниже код вводил нужные вам приложения на сайт django.

вы должны поместить его куда-нибудь, чтобы выполнить, и выполнить проверку, чтобы не выполнять повторное выполнение при загрузке зависимостей. также, если вы его используете, 'someapp' in settings.INSTALLED_APPS будет работать неправильно. возможно, вам также нужно изменить его.

from django.apps import apps
installed_apps = [app.__name__ for app in apps.get_apps()]
new_installed_app = installed_app + ['your desired app1', 'your desired app2', ...]
apps.set_installed_apps(new_installed_apps)