Ответ 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
несут ответственность разработчика за понимание. Выбор для установки для разработчика создает ненужный риск для безопасности. Пусть разработчик решит использовать ваше приложение и инициализировать его зависимости.