[Python] Chutils — библиотека для быстрой настройки конфигов, логов и секретов

@Chu4hel · Регистрация: 18.04.2023

Студворк — интернет-сервис помощи студентам

Всем привет!

Если вы, как и я, часто пишете на Python ботов, парсеры или небольшие сервисы, то вам знакома эта рутина: в каждом новом проекте приходится с нуля настраивать конфиги, прикручивать адекватную запись событий (логирование) и думать, как безопасно хранить API-ключи.

Я занимаюсь разработкой довольно давно, и в какой-то момент мне надоело копипастить этот стартовый код из проекта в проект. Поэтому я собрал все свои наработки в простой и удобный пакет chutils. Это мой первый опыт публикации пакета на PyPI, и я хочу поделиться им с вами.

Что делает chutils? Забирает на себя скучную работу:

Умные конфиги: Автоматически находит ваш config.yml или ⁡config.ini⁡. Вы просто вызываете ⁡get_config_value('секция', 'ключ') ⁡ и получаете данные. Умеет сохранять изменения обратно в файл.
Журналирование "из коробки": Одна строка ⁡setup_logger() ⁡ — и у вас настроена запись всех действий программы. Вывод в консоль и параллельная запись в файл с ротацией по дням. Идеально для отладки и чтобы понимать, что происходит в скрипте в любой момент.
Безопасное хранилище для паролей/токенов: Простая обёртка над keyring, чтобы хранить ключи в системном хранилище (Windows Credential Manager, macOS Keychain и т.д.), а не светить их в коде или конфигах.

Как это выглядит в коде? Максимально просто:

Установка:

Code
1
pip install chutils

Пример:

Кликните здесь для просмотра всего текста

(Важно: в коде используется стандартное для Python имя logger, не путайте. Он нужен для записи событий работы программ

Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
from chutils import get_config_value, get_config_int, setup_logger, SecretManager
 
# Настроили логи одной строкой
logger = setup_logger()
 
# Получили данные из config.yml/ini
admin_id = get_config_int('telegram', 'admin_id') # Сразу в нужный тип
 
# Безопасно получили ключ API
# (Предполагается, что он был сохранен ранее в отдельном скрипте)
# secrets.save_secret('api_key', '12345-abcdef')
secrets = SecretManager('my_awesome_bot')
api_key = secrets.get_secret('api_key')
 
logger.info("Бот готов к запуску!")

Как видите, никакой рутины, можно сразу писать основную логику.

Поскольку это мой первый публичный пакет, я буду очень благодарен за любой фидбэк: что можно улучшить, чего не хватает, может, нашли какие-то баги. Ну и, конечно, если либа окажется полезной, звезды на Гитхабе — лучшая поддержка.

Ссылка на GitHub (там документация и больше примеров): https://github.com/Chu4hel/chutils
Полная документация: https://chu4hel.github.io/chutils/api/
Ссылка на PyPI: https://pypi.org/project/chutils/

Спасибо за внимание и удачного кодинга!

@Welemir1 · 22.10.2025, 08:15

Chu4hel, хороший проект, есть тесты, есть дока, ридми.

Теперь по критике:
1) .idea не добавляют в гит, у меня же могут быть другие настройки ИДЕ или вообще вскод

2) ф-строки не используют обычно в логировании, они же не ленивые, значит будут создаваться даже там, где логер не будет вызван

3) многовато зависимостей для простой библиотеки, но тут дело вкуса

4) для простого проекта наверное реально подойдет, но например как мне называть логеры по разному? Ведь в db и в events я хочу видеть логи с четким названием, а у тебя получается всегда app_logger

5) get_config_int мне не нравится тем, что не предупредит, если в конфиге я скажем ошибся и там не инт, а строка. Хотя бы ворнинг не помешал. В твоей логике мне просто вернет 0 и придется потом дебажить откуда он

6) используешь Path(это верно) и тут же os.path.exists, а чего не сделал Path.exists() они же взаимозаменяемые. Везде используй только PAth он все умеет

7) открываешь файл и только потом начинаешь проверять его расширения (ямл, ини), а зачем? если расширение не верное то и файл открывать не нужно

8)

Python
1
if config is None: config = get_config()

сэкономил 1 строку? перенеси

9) есть очень большие функции, раздели по функционалу, одна за ямл, другая за ини

10) для чего нужны DEVDEBUG и MEDIUMDEBUG, когда я должен их использовать, почему встроенных средств мне не хватит?

11) log_level_str: str = '' -а сам в доке пишешь что если нигде не найдем то будет ИНФО, так почему сразу и не написать тут ИНФО? Почему енам тут не использовать, чтобы люди не думали заглавными писать или еще как?

12) не понравилось что в гет_конфиг_валью fallback по умолчанию строка, лучше бы Нан, строку я тут вообще могу не ожидать

13) я не знаю работает ли кейринг на убунте и макос, но почему старый добрый .env просто не использовать?

@Chu4hel · 22.10.2025, 14:32 **[ТС]**

1. Абсолютно верное замечание.
2. Согласен.

3. Основные зависимости сейчас — это PyYAML (для .yml конфигов) и keyring (для секретов). Остальные зависимости, которые могут быть видны, используются исключительно для разработки и тестирования (dev-dependencies).

4.Пример (05_different_log_levels.py), это и демонстрирует.
Я обновлю README.md и документацию, чтобы явно и на видном месте показать, как создавать именованные логгеры.

5. Согласен на 100%.
6. Справедливое замечание.
7. Логично. Я исправлю логику в config.py, чтобы сначала проверялось расширение (.ini или .yml), и только потом файл открывался для чтения.
8. Это вопрос стиля, но я согласен, что многострочный вариант читается лучше.
9. Да, функция get_config стала слишком громоздкой. Планирую разделить её на несколько маленьких: одна будет главной (оркестратор), а другие будут отвечать за загрузку ini и yml по отдельности.

10. Отсутствие объяснения — моё упущение.
Я добавлю в docstring к ChutilsLogger и в основную документацию чёткое объяснение их предназначения.
DEBUG: Обычная отладочная информация.
MEDIUMDEBUG: Уровень логирования 15. Предназначен для вывода более подробной информации о ходе выполнения программы, которая находится между обычной отладочной информацией (DEBUG) и общими информационными сообщениями (INFO). Полезен для отслеживания ключевых этапов работы модуля без излишней детализации.
DEVDEBUG: Максимально подробный вывод, вплоть до дампов переменных, для самой глубокой отладки.

11. Отличные предложения.
12. Согласен. Я изменю fallback по умолчанию на None.

13. Да, планирую добавить поддержку .env файлов в secret_manager. Изначально я не рассматривал .env как основной способ хранения секретов, так как они не предназначены для программного редактирования во время выполнения, в отличие от INI или YAML. Можно сделать так, чтобы по умолчанию secret_manager сначала искал секрет в keyring, а если не находил — искал бы в .env файле в корне проекта.

Планирую еще добавить возможность разделения лог-файлов по именам в отдельные.

@Welemir1 · 22.10.2025, 15:52

если именование логов есть (я не все примеры смотрел), а .env добавишь, то будет совсем хорошо. Особенно для простого проекта, прототипа, в общем мне твой проект понравился. Не очередной криптобот, а вполне прикладная и полезная штука.

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

@Usaga · 23.10.2025, 02:12

Сообщение от Chu4hel

и думать, как безопасно хранить API-ключи.

И что? Ты об одной и той же проблеме в каждом проекте заново думал?

Сообщение от Chu4hel

чтобы хранить ключи в системном хранилище (Windows Credential Manager, macOS Keychain и т.д.), а не светить их в коде или конфигах.

А почему не хранить их конфигурационном файле путь к которому через переменную окружения передать, как часто делают? Или конфиги в сами переменные окружения засунуть? И не нужны никакие обёртки от сторонних людей или keyring'и.

@voral · 23.10.2025, 07:29

Я не питонист, ради интереса сравнил ситуацию с php/composer (где есть файл .gitattributes для исключения файлов из установки в проекты). Если я правильно понял в питон проектах для этого используется параметр exclude в pyproject.toml. И Может есть смысл исключить каталогов тестов, примеров, github ... и прочих файлов и каталогов которые не нужны когда утилита загружается в другой проект

Добавлено через 2 минуты
Умночат подскал вот такой пример

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[tool.poetry]
....
readme = "README.md"
exclude = [
    "**/__pycache__",
    "**/*.pyc",
    "*.log",
    "tests/",
    "test_*.py",
    "docs/",
    "examples/",
    "*.egg-info/",
    ".github/",
    ".vscode/",
    ".idea/",
    "coverage.xml",
    ".coverage"
]
....

(но про idea и svcode согласен с мнением выше, что им не место в репе

@Chu4hel · 23.10.2025, 13:37 **[ТС]**

Usaga

Сообщение от Usaga

И что? Ты об одной и той же проблеме в каждом проекте заново думал?

Дык вот именно чтоб не думать каждый раз, и запилил secret_manager. Чтоб один раз настроил и забыл.
Так что тут ты сам себе противоречишь, чувак. Моя обертка как раз для этого и нужна.

Сообщение от Usaga

А почему не хранить их конфигурационном файле путь к которому через переменную окружения передать, как часто делают? Или конфиги в сами переменные окружения засунуть? И не нужны никакие обёртки от сторонних людей или keyring'и.

Смотри, keyring это не просто так. Он для локальной разработки и когда у тебя один юзер на машине.

Секреты тогда в системном хранилище лежат, а не в файлах, которые можно случайно в гит залить или кто-то подсмотрит. Это безопаснее.
А вот переменные окружения, про которые ты говоришь, это тема для серверов, докеров, CI/CD. Там keyring и правда не всегда в тему. И да, я уже сам до этого дошел и планирую добавить поддержку `.env` файлов в secret_manager. Так что можно будет выбирать, что удобнее.
Конфиги в открытом виде для секретов - ну такое себе, если честно. Если только там не тестовые ключи.

Так что критика принята, но не вся. И да, проект развивается, так что скоро будет еще лучше.

Добавлено через 10 минут

Сообщение от voral

Может есть смысл исключить каталогов тестов, примеров, github ... и прочих файлов и каталогов которые не нужны когда утилита загружается в другой проект

Спасибо за наводку! Закинул это в дорожную карту проекта, причем с самым высоким приоритетом, чтоб пакет был максимально чистым и без лишнего мусора.

@Usaga · 23.10.2025, 15:11

Сообщение от Chu4hel

Дык вот именно чтоб не думать каждый раз, и запилил secret_manager. Чтоб один раз настроил и забыл.
Так что тут ты сам себе противоречишь, чувак. Моя обертка как раз для этого и нужна.

Так проблема уже имеет несколько решений. Я об этом. Можно было посмотреть на чужой опыт сначала)

Сообщение от Chu4hel

Секреты тогда в системном хранилище лежат, а не в файлах, которые можно случайно в гит залить или кто-то подсмотрит. Это безопаснее.

Ну... Безопаснее, но условно. Файлы конфигов не обязаны лежать там же, рядом с кодом, откуда их можно в репозиторий пушнуть. Ты же говоришь о "локальной разработке"? Значит это уже не регулярный пользователь, а нечто косящее под разработчика. Он может задать переменную окружения с путём к конфигу, который будет лежать вне репозитория.

У нас ещё немного другой подход используется. Конфиг имеет определённое имя, но содержит нечувствительную информацию. Но его параметры могут переопределяться другим конфигом, который лежит тут же, но добавлен в .gitignore. Весьма удобно. И не надо сторонних решений.

Хотя допускаю, что в питоне может такое чем-то сторонним и решается.

Вообще, кейринг и подобное это больше для пользовательского ПО, а не для ботов/сервисов)

@Chu4hel · 23.10.2025, 20:33 **[ТС]**

Сообщение от Usaga

Так проблема уже имеет несколько решений.

Да есть os.getenv, configparser, PyYAML - проверенные временем инструменты. chutils не пытается их заменить, он пытается избавить от рутины, которая возникает вокруг них.
Вместо того чтобы в каждом новом проекте писать код для поиска конфига, парсинга, настройки логгера и безопасной работы с ключами, ты получаешь это одной строкой. Это экономия времени и избавление от рутины на старте.

Сообщение от Usaga

Он может задать переменную окружения с путём к конфигу, который будет лежать вне репозитория.

Может. Это рабочий подход. Но это опять же ручная работа. Тебе надо:
Создать этот файл где-то в ~/.config/my_app/.
Настроить переменную окружения.
Не забыть сделать то же самое на продакшене.
Написать инструкцию для нового разраба в команде, чтобы он сделал то же самое.

chutils убирает все эти шаги. Он сам находит корень проекта и подхватывает config.yml. Это не про "правильно/неправильно", а про "автоматически vs вручную". Я выбираю автоматизацию.

Сообщение от Usaga

Конфиг имеет определённое имя, но содержит нечувствительную информацию. Но его параметры могут переопределяться другим конфигом, который лежит тут же, но добавлен в .gitignore.

Годный подход, многие так делают. И chutils вполне может такое поддерживать в будущем. Но для хранения секретов в любом случае спорно. Файл в .gitignore защищает только от случайного коммита. Он по-прежнему лежит на диске в открытом текстовом виде. Может файл случайно попасть в архив. Или любой процесс с правами на чтение увидит файл.
SecretManager использует системное хранилище ключей (macOS Keychain, Windows Credential Manager), где секреты зашифрованы на уровне ОС. Это просто фундаментально другой, более высокий уровень безопасности для хранения чувствительных данных, вроде паролей от БД и API-ключей.

Сообщение от Usaga

Вообще, кейринг и подобное это больше для пользовательского ПО, а не для ботов/сервисов)

Согласен.
Для серверов, Docker-контейнеров и CI, где keyring не всегда удобен, как раз и планируется фолбэк на .env файлы. Либа стремится быть гибкой: использовать максимум безопасности там, где это легко, и предоставлять надежный стандартный вариант там, где это необходимо.

Новые блоги и статьи Все статьи Все блоги /
Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .
Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025	Расскажи мне о Мире, бродяга kumehtar 12.11.2025 — Расскажи мне о Мире, бродяга, Ты же видел моря и метели. Как сменялись короны и стяги, Как эпохи стрелою летели. - Этот мир — это крылья и горы, Снег и пламя, любовь и тревоги, И бескрайние. . .	PowerShell Snippets iNNOKENTIY21 11.11.2025 Модуль PowerShell 5. 1+ : Snippets. psm1 У меня модуль расположен в пользовательской папке модулей, по умолчанию: \Documents\WindowsPowerShell\Modules\Snippets\ А в самом низу файла-профиля. . .

@Chu4hel 2 / 4 / 1 Регистрация: 18.04.2023 Сообщений: 7
	22.10.2025, 14:32 [ТС]
	1. Абсолютно верное замечание. 2. Согласен. 3. Основные зависимости сейчас — это PyYAML (для .yml конфигов) и keyring (для секретов). Остальные зависимости, которые могут быть видны, используются исключительно для разработки и тестирования (dev-dependencies). 4.Пример (05_different_log_levels.py), это и демонстрирует. Я обновлю README.md и документацию, чтобы явно и на видном месте показать, как создавать именованные логгеры. 5. Согласен на 100%. 6. Справедливое замечание. 7. Логично. Я исправлю логику в config.py, чтобы сначала проверялось расширение (.ini или .yml), и только потом файл открывался для чтения. 8. Это вопрос стиля, но я согласен, что многострочный вариант читается лучше. 9. Да, функция get_config стала слишком громоздкой. Планирую разделить её на несколько маленьких: одна будет главной (оркестратор), а другие будут отвечать за загрузку ini и yml по отдельности. 10. Отсутствие объяснения — моё упущение. Я добавлю в docstring к ChutilsLogger и в основную документацию чёткое объяснение их предназначения. DEBUG: Обычная отладочная информация. MEDIUMDEBUG: Уровень логирования 15. Предназначен для вывода более подробной информации о ходе выполнения программы, которая находится между обычной отладочной информацией (DEBUG) и общими информационными сообщениями (INFO). Полезен для отслеживания ключевых этапов работы модуля без излишней детализации. DEVDEBUG: Максимально подробный вывод, вплоть до дампов переменных, для самой глубокой отладки. 11. Отличные предложения. 12. Согласен. Я изменю fallback по умолчанию на None. 13. Да, планирую добавить поддержку .env файлов в secret_manager. Изначально я не рассматривал .env как основной способ хранения секретов, так как они не предназначены для программного редактирования во время выполнения, в отличие от INI или YAML. Можно сделать так, чтобы по умолчанию secret_manager сначала искал секрет в keyring, а если не находил — искал бы в .env файле в корне проекта. Планирую еще добавить возможность разделения лог-файлов по именам в отдельные. 1

@Welemir1 Автоматизируй это! 7390 / 4817 / 1246 Регистрация: 30.03.2015 Сообщений: 13,663 Записей в блоге: 29
	22.10.2025, 15:52
	если именование логов есть (я не все примеры смотрел), а .env добавишь, то будет совсем хорошо. Особенно для простого проекта, прототипа, в общем мне твой проект понравился. Не очередной криптобот, а вполне прикладная и полезная штука. Подумай еще написать на английском ридми, англоязычных пользователей больше. Но если в ту сторону решишь двигаться, то и доку в функциях придется всю перевести, впрочем это сейчас просто делается. 1