Классы настроек должны наследоваться от ArFiSettings и иметь возможность наследоваться друг от друга (обычное наследование)
Сами же внутренние, собственные, настройки, такие как env_nested_delimiter, conf_file, env_file, case_sensitive и т.д должны задаваться в одном месте - в главном классе настроек - в родителе.
Из родительского главного класса настроек эти внутренние, собственные, настройки должны автоматически передаваться детям, то есть во все вложенные поля (атрибуты), которые наследуются от ArFiSettings.
У ребенка должно быть право выбора - принимать ли настройки от родителя или переопределять их своими собственными.
Структура файлов конфигурации должна иметь чёткую иерархию пути:
<директория настроек>/<директория родителя>/<директория ребёнка>/<директория внука>/<директория правнука> ... и так далее.
По умолчанию директория родителя не задана и по сути можно рассматривать её равной директории настроек. Но при желании и её можно изменить указав mode_dir="my_app". Остальные поддиректории, если не заданы явно параметром mode_dir, устанавливаются автоматически по имени аттрибута у класса-родителя.
Иерархия этого пути должна строиться автоматически, но с возможностью переопределения вручную.
В файлах должна быть возможность для правнука задавать настройки как в директории родителя, так и в директориях ребёнка и внука.
Но приоритетные настройки из директории правнука всегда должны переопределять все предыдущие. При этом не обязательно физически создавать все директории. Директорию правнука нужно создавать только, чтоб исключить возможность переопределения настроек из директории родителя, ребёнка или внука.
Должна быть возможность моментального переключения настроек при смене режима MODE для конкретного класса или для всего приложения в целом. Названия режимов задаются пользователем произвольно, например, dev, test, prod, docker.
Файлы с настройками должны располагаться именно в директориях, чтоб визуально можно было определить какие настройки к какому режиму относятся и чтоб можно было их добавить в .gitignore. Например в директории ребёнка могут лежать файлы config.toml, dev.toml, test.toml, prod.toml и так далее. Название каждого файла должно соответствовать конкретному режиму, например, если режим называется production, то и файл должен называться так же.
Настройки приложения могут лежать сразу в нескольких директориях, структура директорий должна сохраняться.
Например conf_dir = ["config", "~/.config/my_app/", "/opt/my_app/config", "/etc/my_app/config"]. В данном примере приоритетные настройки расположены в директории /etc/my_app/config.
В любой директории главный файл с настройками по умолчанию называется config. Из этого файла библиотека читает настройки, если не указан определённый режим MODE.
Расширение по умолчанию может быть любым из toml, yaml, yml, json в порядке приоритета. То есть, сначала arfi-settings ищет файл config.toml, если не находит, то ищет config.yaml, если не находит, то ищет config.yml, и так далее.
Название файла по умолчанию можно переопределить conf_file = "arfi-settings". Расширение так же можно указать конкретное, например, conf_file = "arfi-settings.json". Тогда, даже если в директории есть файл arfi-settings.toml, но будет отсутствовать конкретный файл arfi-settings.json, то библиотека будет считать что файла с настройками не существует.
Библиотека должна уметь читать файлы с любым расширением и файлы БЕЗ расширения. Для этого должна быть возможность задать собственный читатель и обработчик.
Должна быть возможность читать файлы настроек не только из заданных директорий, но и из файлов по конкретному пути.
Например conf_file = ["config", "/home/user/.config/common-config-for-all-project/config.toml"]. При этом настройки из последнего файла в списке всегда будут иметь приоритет над предыдущими, лежащими в любой директории, указанной через переменную conf_dir.
При разрешении регистронезависимых имён приоритет всегда должен отдаваться точному совпадению. Например, если параметр называется My_Project и он указан, до даже если рядом указаны параметры MY_PROJECT и my_project, то приоритет при case_sensitive=False будет всегда выставлен на My_Project.
Должна быть возможность указывать отдельно параметры case_sensitive и encoding для файлов настроек и для файлов переменных окружение (.env)
Должна быть возможность отключения чтения настроек из любого источника.
Должна быть лёгкая возможность смены приоритетов чтения настроек для любого класса или инстанса, например просто указав ordered_settings=["cli", "env", "secrets"].
Максимально расширить возможности библиотеки, чтоб был лёгкий доступ к богатым настройкам pydantic, например, таким как дискриминатор.
Переменные окружения, а точнее их имена, должны задаваться не только для конкретного класса, но и для класса родителя для удобочитаемости и для гибкости настройки.
Например, имя переменной DB__DATABASE общее для всех настроек и определяется для класса-родителя, но вот имена переменных POSTGRES_DATABASE или MYSQL_DATABASE конкретное для своего класса и переопределяет значение переменной для класса-родителя при использовании дискриминатора. Это удобно если у вас 2 одинаковы БД postgres, но расположенные на разных хостах (искусственный пример). В родительском классе настроек у вас будут 2 переменные db:PostgreSQL и pgprod:PostreSQL, тогда в переменных окружения можно задать 2 параметра DB__HOST - для основной базы данных и PGPROD_HOST для второй базы данных.
Секретная директория как и чтение параметров из командной строки (CLI) должны указываться (включаться) по умолчанию только для конкретного класса, так как это более специфические настройки и нет необходимости постоянно читать их в каждом классе настроек.
Возможность указания настроек по умолчанию для всех классов в файле pyproject.toml, чтоб любой разработчик мог сразу увидеть в репозитории ваши настройки не заглядывая в сам код.
Должна быть возможность чтения настроек из файлов без создания модели, но с возможностью использовать MODE, как для основного класса настроек.
Библиотека должна иметь возможность читать настройки из URL, а так же зашифрованные настройки, при наличии ключа.
Режим отладки обязательно должен быть, так как не всегда понятно откуда конкретно пришло значение для конкретной переменной и где ошибка.