Без контейнера, как показывает практика, в большинстве случае это делают везде, кто где захотел - часто такое можно увидеть прямо внутри __init__
А с контейнером, во-первых, все находится в одном месте - это уже проще найти в коде, также появляется отдельная зона ответственности, которая занимается сборкой объектов. Во-вторых - таскать за собой нужно только маркеры и декоратор типа inject, но я не особо понимаю в чем здесь проблема
В своем фреймворке я сделал автоинъекцию по типу объекта, в этом случае вам бы понадобился только условный декоратор@autoinject
P.S. Вы упомянули проброс конфига с Depends. Если вы инжектите конфиги в хендлеры, на мой взгляд, это уже звоночек, что что-то делается не так, если нет обоснования так делать
Но дело ведь не только в "менять реализации в зависимости от среды или фазы луны". Лично я вижу две главные цели таких фреймворков:
1. Позволить нормально внедрять зависимости вместо повсеместного таскания всяких конфигов, json-ов, yaml-ов, переменных окружения и прочего. Таскать это по всей кодовой базе - значит нарушать зоны ответственности и усложнять код
2. Облегчить тестирование. Тесты становится писать в удовольствие, когда вместо манкипатчинга в каждом тесте можно просто вызвать метод типа override, который подменит объект везде, где использовался связанный провайдер
По поводу абстракций: как и в любой пакет/любую библиотеку появляется некий накладной расход в виде того, что нужно почитать доку, попробовать в использовании и т.д. - без этого никак. Но фреймворков уже немало и у вас есть выбор - в каком-то из них вам будет явно проще освоиться, чем в другом
Пытались в одном из issue с еще одним пользователем это завести - не получилось. но это легко исправить
Не особо понял про слабый контроль жизненного цикла, вроде бы с этим все просто и оно работает. Для меня (как наверное и для большинства) существуют две нужды, то есть два скоупа - request/function (transient скоуп) и синглтоны
В дишке мне не нравится многословность, сходу он кажется куда более громоздким и непонятным в сравнении с dependency-injector, если смотреть на эти пакеты с точки зрения публичного API. Но понимаю, что это уже больше все-таки про вкус и цвет, кому что нравится. Не исключаю, что когда-нибудь мнение изменится и я перейду на дишку, но пока что так)
Здорово, если в дишке нет глобального стейта. Согласен, что это не очень хорошо, но тем не менее с таким контейнером кажется нет никаких проблем, потому в контейнере лежит довольно примитивный и простой код (как, например, в вышеупомянутом injection и https://github.com/modern-python/that-depends)
Рекомендую посмотреть https://github.com/nightblure/injection. Более легкая версия dependency-injector, не перегруженная лишним. Еще есть понятный механизм финализации ресурсов и удобное переопределение зависимостей как в dependency-injector
Также в репозитории uv в ридми авторы пишут следующее: "uv does not yet have a stable API; once uv's API is stable (v1.0.0), the versioning scheme will adhere to Semantic Versioning". Источник: https://github.com/astral-sh/uv.
Инструмент видимо находится в активной и экспериментальной фазе разработки (кажется, поэтому в Hatch предусмотрена возможность отключения uv), но выглядит интересно и многообещающе)
Без контейнера, как показывает практика, в большинстве случае это делают везде, кто где захотел - часто такое можно увидеть прямо внутри
__init__А с контейнером, во-первых, все находится в одном месте - это уже проще найти в коде, также появляется отдельная зона ответственности, которая занимается сборкой объектов. Во-вторых - таскать за собой нужно только маркеры и декоратор типа inject, но я не особо понимаю в чем здесь проблема
В своем фреймворке я сделал автоинъекцию по типу объекта, в этом случае вам бы понадобился только условный декоратор
@autoinject
P.S. Вы упомянули проброс конфига с Depends. Если вы инжектите конфиги в хендлеры, на мой взгляд, это уже звоночек, что что-то делается не так, если нет обоснования так делать
Но дело ведь не только в "менять реализации в зависимости от среды или фазы луны". Лично я вижу две главные цели таких фреймворков:
1. Позволить нормально внедрять зависимости вместо повсеместного таскания всяких конфигов, json-ов, yaml-ов, переменных окружения и прочего. Таскать это по всей кодовой базе - значит нарушать зоны ответственности и усложнять код
2. Облегчить тестирование. Тесты становится писать в удовольствие, когда вместо манкипатчинга в каждом тесте можно просто вызвать метод типа override, который подменит объект везде, где использовался связанный провайдер
По поводу абстракций: как и в любой пакет/любую библиотеку появляется некий накладной расход в виде того, что нужно почитать доку, попробовать в использовании и т.д. - без этого никак. Но фреймворков уже немало и у вас есть выбор - в каком-то из них вам будет явно проще освоиться, чем в другом
Финализация с function-скоупом так кажется в принципе не работает) (это про маркер Closing, см. https://python-dependency-injector.ets-labs.org/providers/resource.html)
Пытались в одном из issue с еще одним пользователем это завести - не получилось. но это легко исправить
Не особо понял про слабый контроль жизненного цикла, вроде бы с этим все просто и оно работает. Для меня (как наверное и для большинства) существуют две нужды, то есть два скоупа - request/function (transient скоуп) и синглтоны
В дишке мне не нравится многословность, сходу он кажется куда более громоздким и непонятным в сравнении с dependency-injector, если смотреть на эти пакеты с точки зрения публичного API. Но понимаю, что это уже больше все-таки про вкус и цвет, кому что нравится. Не исключаю, что когда-нибудь мнение изменится и я перейду на дишку, но пока что так)
Здорово, если в дишке нет глобального стейта. Согласен, что это не очень хорошо, но тем не менее с таким контейнером кажется нет никаких проблем, потому в контейнере лежит довольно примитивный и простой код (как, например, в вышеупомянутом injection и https://github.com/modern-python/that-depends)
Спасибо за статью
Рекомендую посмотреть https://github.com/nightblure/injection. Более легкая версия dependency-injector, не перегруженная лишним. Еще есть понятный механизм финализации ресурсов и удобное переопределение зависимостей как в dependency-injector
нейминги некоторых секций в файле pyproject.toml не соответствуют PEP-621
значительно медленнее uv
не умеет запускать скрипты from-scratch (см. https://docs.astral.sh/uv/guides/scripts/#declaring-script-dependencies)
Спасибо за обзор!
Кажется, что не упомянуты следующие важные вещи: автор Hatch пишет "UV is under active development and may not work for all dependencies". Источник: https://hatch.pypa.io/latest/how-to/environment/select-installer/#enabling-uv
Также в репозитории uv в ридми авторы пишут следующее: "uv does not yet have a stable API; once uv's API is stable (v1.0.0), the versioning scheme will adhere to Semantic Versioning". Источник: https://github.com/astral-sh/uv.
Инструмент видимо находится в активной и экспериментальной фазе разработки (кажется, поэтому в Hatch предусмотрена возможность отключения uv), но выглядит интересно и многообещающе)
Что думаете о Testcontainers для поднятия инфраструктурных сервисов для тестов?