Обновить

Комментарии 7

Стандартный модуль logging в Python требует целого ритуала: создать логгер, настроить хендлер, определить форматтер, добавить фильтры... Loguru позволяет начать писать логи сразу, при этом делая их информативными и красивыми.

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

Хотите цветные логи - попробуйте colorlog, это просто отдельный форматтер для стандартного logging.

Что же касается ротации - посмотрите лучше в сторону программ сбора логов. Например, journald, если вы запускаете приложение через systemd, да и докер сам тоже собирает. Это применемо не для всех типов приложений, но всё же. Если же у вас один процесс, то и logging прекрасно всё ротирует.

Я сейчас немного похвастаюсь, но у меня есть собственная опен-сорс библиотека. Называется colordebug (github.com/garantiatsverga/colordebug), довольно легко настраивать, делает выводы в консоль с цветными приписками и логирует в отдельный файл с датой и временем. Легко настраивать, но для продакшена еще надо довести до ума. Но для хакатонов и пет-проектов самое то

Рекомендую присмотреться к тому как устроен стандартный logging

  1. Иерархия логгеров это очень полезно для настройки и фильтрации. При чем не всегда это хочется привязывать к иерархии файлов (это просто самый удобный дефолт)

  2. Хэндлеры отдельно - это очень ползено для настройки вывода без изменения остальной части кода. Можно выводить в консоль, можно выводить в файл, можно кидать в другой тред и в фоне разгребать.

  3. Форматтеры отдельно от хэндлеров тоже полезно - можно делать лог цветным, можно выводить в json, можно в csv, при этом не важно в файл, в консоль или через доп тред

В большинстве случаев вместо изучения сторонних библиотек логирования лучше потратить время на изучение логгинга - он очень гибкий.

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

Какую боль решает: Случайная публикация секретных данных на GitHub и сложность настройки окружения на разных машинах.

Если вам сложно использовать переменные окружения, зачем вы делаете вид что их используете? Возьмите любой формат конфигов - toml, yaml на худой конец, точно так же добавите ваш config.toml в гитигнор и ничего никуда не утечет. Зато будет нормальный формат файла. У всех инструментов, читающих .env, единого формата нет, различия небольшие, но могут быть неприятны.

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

Я бы оставил python-dotnev для ситуаций когда у вас есть явное требование использовать переменные окружения, но вы почему-то не можете ввести абстракцию чтобы при разработке использовать конфиг файл вместо них, а до старта задать не можете (читай: по другому вообще никак). А в остальных случаях рассмотрел загрузку переменных окружения средствами среды запуска (в окошке IDE, source env.sh или ещё что) или переход на полноценные конфиг файлы.

Ещё одна статья из LLM-ки. Зачем? Для тех, кто не зарегистрирован в чатеГПТ?

В одном проекте использовал tqdm, и использовал loguru. Что бы их корректно подружить - это оказалось совсем нелегко.
По отдельности - это крутые полезные библиотеки, но использовать их вместе - это уже лишняя ненужная борьба с возможными глюками.

Ну кстати, в статье упоминался rich, в нем есть и свой логгинг хэндлер и свои примитивы для прогресс баров

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации