Как обрабатывать config/env vars в библиотечном проекте

Как обрабатывать config/env vars в библиотечном проекте
Как обрабатывать config/env vars в библиотечном проекте - davidclode @ Unsplash

Я создаю новый проект библиотеки Python, который будет использоваться несколькими моими проектами приложений. Существующий код использует переменные среды для различных параметров конфигурации. Должен ли мой библиотечный проект читать конфигурацию из переменных среды? Я всегда знал, что библиотеки не должны делать предположений о среде, в которой они работают. Каков наилучший способ обеспечить конфигурацию проектов библиотек из приложений/сред, которые их используют?

Не существует единственного лучшего способа, поскольку он зависит от архитектуры библиотеки. Чтение переменных среды непосредственно в коде библиотеки также проблематично для написания модульных тестов, что является еще одной причиной избегать этого, если это возможно. Это не полный список, но это хорошее начало:

  1. Создайте класс «config», который могут использовать другие классы или функции в вашей библиотеке. Пользователи вашей библиотеки могут инициализировать этот объект конфигурации по своему усмотрению.

    Льготы:

    • У потребителей есть строго типизированный объект с правильно названными свойствами.
    • Для использования этого объекта вашей библиотеке требуется внедрение зависимостей, что также упрощает тестирование.

    Недостатки:

    • Если ваша библиотека не предназначена для внедрения зависимостей, возможно, вам предстоит незначительная работа по рефакторингу, которая может потребовать критических изменений в API.
  2. Создайте функцию «config», которая принимает все настройки в качестве аргументов. Затем эта функция конфигурации может устанавливать переменные или свойства, которые являются внутренними для вашей библиотеки.

    Льготы:

    • У потребителей есть единая точка для настройки библиотеки.
    • Может потребоваться только незначительный рефакторинг, если ваша библиотека изначально не была предназначена для внедрения зависимостей.

    Недостатки:

    • Модульное тестирование вашей библиотеки может стать немного сложнее.
    • Многие настройки будут «статическими», а не «экземплярными» переменными, что сделает невозможным для потребителей возможность иметь два набора конфигураций.
      • Хотя это тоже недостаток для чтения конфигов из env vars.
  3. Добавьте дополнительные параметры в функции для этих настроек.

    Льготы:

    • Вам больше не нужны переменные окружения.
    • Легче протестировать код библиотеки с помощью модульных тестов.

    Недостатки:

    • Функции становятся более сложными для вызова из-за дополнительных аргументов.
    • Потенциально много критических изменений для потребителей.
  4. Объедините варианты 1 и 2. Это может быть промежуточным шагом, если вы хотите предоставить клиентам понятный интерфейс для настройки вашей библиотеки во время рефакторинга кода для поддержки внедрения зависимостей. Потребители инициализируют объект конфигурации, а затем передают его функции конфигурации. Функция config может задавать внутренние переменные или свойства и может подвергаться постоянному рефакторингу по мере того, как ваша библиотека начинает поддерживать внедрение зависимостей.

    Льготы:

    • Дает вам преимущества обоих вариантов 1 и 2.
    • Позволяет постепенно рефакторить код вашей библиотеки для поддержки внедрения зависимостей, если это желательно.

    Недостатки:

    • Те же недостатки, что и у варианта 2.

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


LetsCodeIt, 28 декабря 2022 г., 00:17