Comments 44
Успей скачать, только сегодня!
P.S. , чёто у вас гитхаб 404 и странные пакеты на pypi, напр. "pydantic2"
Первые три дня он копировал старый
settings.py.
Все базовые параметры лежат готовые в репозитории/шаблоне, а для локального окружения он скопировал local_settings.example.py в local_settings.py
Потом неделю правил
INSTALLED_APPS.
Он лежит готовый в репозитории/шаблоне
Потом два дня воевал с
ALLOWED_HOSTS.
В вышеупомянутом local_settings.example.py уже прописано всё готовое для локалхоста
Потом переписывал
DATABASESпод дев, тест и прод.
Тест лежит готовый в репозитории/шаблоне, прод лежит готовый у админов (и простой разработчик не должен иметь доступ к проду), дев лежит готовый в local_settings.example.py, разве что пароль свой вписать если он есть
Потом поймал баг, потому что написал
DEBUG="yes".
Не поймал, потому что django-stubs сразу подсветил ошибку
Потом завёл
.envи сказал, что «всё по best practices».
Не завёл, потому что с local_settings.py тоже живётся хорошо
Подробнее: Как сделать несколько конфигураций (settings.py) для проекта Django?
Итого:
если мы дорабатываем существующий проект: минута на git clone, минута на создание
local_settings.py, ну может ещё пара минут на apt install mysql — $1.25 на всё про всёесли мы делаем новый проект: просто скопировать всё вышеупомянутое из любого существующего проекта или сгенерировать из заранее подготовленного шаблона — пусть условно ещё $1.25
Продать django-cfg для меня у вас не получилось
ну так не было такой задачи)
Да, да, конечно, копипастить из local_settings.py — это инновация уровня Илона Маска)))))
Абсурдная рекламная статья про ии-сгенерированную библиотеку с миллионом зависимостей и непонятным набором функций, с ии-сгенерированной КДПВ. Как связан текст статьи про settings.py с библиотекой которая интегрируется с телеграмом, ллмками, получением курса валют из ЦБ РФ и ЕЦБ и всеми остальными идеями возникшими в агонии безымянной видеокарты из кластера где-то в душном датацентре?
Вопрос то в чем?
То есть твой settings.py с копипастой из десятка туториалов - это зрелость, а библиотека с готовыми интеграциями это "миллион зависимостей" ?
Красиво оправдывать болото умеешь!)
А если написать, что Вася потратил полтора гугильона пупильонов денег и 3 тыщи лет на INSTALLED_APPS, то станет еще драматичнее.
Правда, убедительно это звучало бы от лица Саши Пряникова, евпочя.
Увидя название статьи, подумал будет статья о безопасности, о грамотной настройке settings.py и защите данных.
Но не тут то было, статья о вообще другом, о рекламе своего продукта, который по большей части сделан нейронками, и обещает сэкономить миллионы на продакшене, на энтепрайзе (раз у нас сравнение сеньора и мидла). Немного пораскинув мозгами, выходит так что скупой платит дважды, и если мы сэкономим на нормальной настройке, то вот что нас ждёт:
(Раз проект делала нейронка и скорее всего статью тоже, то грех не воспользоваться ею для беглого анализа проекта)
Этот пакет нельзя использовать в продакшене, потому что:
Это не «конфиг-хелпер», а громоздкий комбайн: внутри 190+ файлов, десятки модулей (accounts, api/commands, middleware, leads, telegram, currency, llm и пр.), что резко увеличивает поверхность атаки и риски цепочки поставки.
Устанавливает консольный скрипт django-cfg с широкими полномочиями (entry_points), что добавляет необязательные точки выполнения кода во всей системе.
В исходниках есть прямые вызовы subprocess из веб- и management-контекста, что при конфигурационных ошибках может привести к удалённому выполнению команд.
Много сетевых вызовов (requests/telebot) в core, middleware и модулях — потенциальные каналы эксфиляции и зависимость от внешних сервисов без прозрачного аудита.
Публичный репозиторий и документация нестабильны/недоступны (часто 404), что делает аудит и доверие к обновлениям невозможными.
Обещания «магии» в виде автоконфигов противоречат лучшим практикам Django: минимальная магия, явные настройки через окружение/конфиги и ограниченные зависимости.
Рекомендация: отказаться от пакета; использовать стандартные настройки Django или зрелую альтернативу django-configurations (Jazzband) с минимальными зависимостями и прозрачной историей.
И это ведь я ещё не изучил сам исходный код проекта и каждого импорта (кой их 30+ загружается вместе с django-cfg).
На мой взгляд это выглядит как попытка supply-chain атаки. Особенно если учесть названия проектов, которые созвучны с полноценными, известными проектами. (pydantic2 чего стоит, или аналогия ТС на django-configurations)
После твоего коммента ясно, кто тут настоящий Вася. Паника про "190+ файлов", "subprocess" и "supply-chain атаки" без единого взгляда на код - это уровень джуниора, который видит Django впервые.
Репо недоступно? Да скачай PyPI пакет и посмотри реальный код, а не придумывай страшилки по README. Весь функционал это набор опциональных модулей и CLI-инструментов, которые не выполняются сами по себе в продакшене. Никаких "эксфильтраций", никаких "рисков цепочки поставки" - это твои страхи, а не факты.
Выдавать "не использовать в проде" на основании домыслов? - чистый middle-tier уровень. Senior сначала смотрит код, потом делает выводы, а не пугает всех страшными словами.
Короче, прежде чем раздавать советы про безопасность и архитектуру - сначала открой пакет, пойми, что делает каждая строчка, и только потом делай выводы. Всё остальное - трёп, чтобы казаться экспертом.
Слушай, я может и не шарю, но твоя статья же по сути про то, что "зачем платить сеньору, если можно мидла с cfg взять".
Ты мне сам пишешь, что я — мидл, потому что "не использовать в проде".
Тогда выходит, что твой тул для мидлов, а мидлы его и не берут.
Это как-то грустный замкнутый круг получается: софт для тех, кто им пользоваться не станет.
По фактам:
проект открыт, код доступен, всё можно проверить руками. Если твоя уверенность держится только на предположениях - это не экспертиза, это воображение.
А вот в реальном продакшене решают не страшные слова, а рабочие инструменты. И тут всё просто - кто умеет, тот проверяет и использует. Кто не умеет - тот пишет, что "мидлы не возьмут".
Замкнутый круг, да :)
Нет никакого замкнутого круга. Кто может - идет на djangoproject, кто может - гуглит. Я не буду против, если усилиями хабра еще и в общедоступных LLM-ках останется пометка, что пакеты, где засветился unrealos.com, не надо устанавливать.
проект открыт, код доступен, всё можно проверить руками.
https://github.com/markolofsen/django-cfg - 15.09.2025 20:28 выдает 404. Проект не открыт, код проекта не доступен.
https://pypi.org/project/django-cfg/ - пакет доступен для установки. После установки в >100 mgb возможно исследовать код установленного пакета.
Моя уверенность держится на понимании, как работает open-source: на 15.09.2025 django-cfg - НЕ osp.
проект открыт, код доступен, всё можно проверить руками.
кажется это не совсем так, зато можно пораздоваться что проект открыт к изменениям со стороны сообщества
We welcome contributions! Here's how to get started:
git clone https://github.com/markolofsen/django-cfg.git
упс
~/tmp $ git clone https://github.com/markolofsen/django-cfg.git
Cloning into 'django-cfg'...
Username for 'https://github.com':
бывает, мне тоже иногда лень читать что там чатгпт нагенерил
Выгрузили https://github.com/markolofsen/django-cfg
Документация тут (пока сыроватая еще):
https://docs.djangocfg.com/
И офиц. сайт:
https://djangocfg.com/
Просто чтобы зафиксировать это здесь
В репозитории 8 коммитов и нет тегов, в pypi (на глаз) около 100 релизов. Соотнести какой релиз к какой версии кода относится невозможно. Я скачал версию 1.3.7 с pypi, и мастер с гитхаба. На гитхабе версия оказалась 1.3.5, отличие между 1.3.7 лишь в номере версии (1.3.5 -> 1.3.7, да, 1.3.6 не существует в гит репозитории) и:
diff --git a/src/django_cfg/apps/urls.py b/src/django_cfg/apps/urls.py
index 8946293..7e5ed36 100644
--- a/src/django_cfg/apps/urls.py
+++ b/src/django_cfg/apps/urls.py
@@ -52,8 +52,7 @@ def get_django_cfg_urlpatterns() -> List[URLPattern]:
# if base_module.is_maintenance_enabled():
# patterns.append(path('admin/django_cfg_maintenance/', include('django_cfg.apps.maintenance.urls_admin')))
- # if base_module.is_payments_enabled():
- if True:
+ if base_module.is_payments_enabled():
patterns.append(path('admin/django_cfg_payments/admin/', include('django_cfg.apps.payments.urls_admin
')))
except Exception:
Также зачем-то где-то между 1.3.5 и 1.3.7 прямо в пакет добавлен зип архив src/django_cfg/template_archive/django_sample.zip на 1.7 Mb. Исходники пакета целиком занимают 7.5 Mb (без examples, с ними почти в 2 раза больше).
Стоит отметить, что так как история гита не совпадает с релизами на pypi:
невозможно без дополнительного тулинга и автоматизации узнать что менялось между релизами на pypi
нет коммит меседжей до версии 1.2.23, и кажется коммитов для конкретных версий просто нет, -- значит невозможно узнать мотивацию автора при внесении изменений
Проект дампнут вторым коммитом (75d20ef29) "как есть", на 107 тысяч строк. И кажется там нет каких-то огромных файлов чтобы это как-то объяснить, просто сотни файлов по 50 - 400 строк каждый. Внутри проекта есть под-проекты, которые выглядят как не имеющие никакого отношения к django-cfg, например "Universal Payment System v2.0".
Всё выглядит сгенерированным нейросетями.
Короткий вывод: в свете недавних новостей про supply chain атаки, скачивать данный проект на сотню тысяч строк и кучу зависимостей я бы не рекомендовал.
Автору:
Нет ничего плохого в создании пакетов для упрощения кикстарта и конфигурации, такие проекты есть и довольно успешные. Если бы мне понадобилась библиотека, сгенерированная нейросетями, я бы её просто сгенерировал сам, с меньшим числом зависимостей, коротким readme, и заточенную конкретно под мой юзкейс.
Ну друган))) you made my day! Ты мне напомнил людей, которые до сих пор ностальгируют по совку: "вот раньше и код руками писали, и файлов было мало". Слушай, ты правда код руками пишешь? Прямо сам, без ИИ? Тогда о чём нам вообще спорить? Это как обсуждать с человеком, который принципиально ездит на лошади, преимущества электромобиля. "Много файлов = плохо"? Так играй в тетрис, там всего 7 фигур. CLI "с широкими полномочиями"? Ну да, как и django-admin. Это базовая практика. subprocess? Есть у Django, Celery и половины пакетов на PyPI. requests? Любой API-клиент его использует. Ты функционал называешь уязвимостью. Про репозиторий: Код давно открыт - пакет на PyPI, GitHub доступен, доки на djangocfg.com. Ты реально смог найти 404 и на этом построить всё обвинение? Это как прийти в магазин, застать его закрытым на обед и написать обзор: "этот супермаркет не существует, опасайтесь мошенников". Ни одного реального бага ты не назвал. Только страшилки и домыслы, под соусом "supply chain атаки". Django-Cfg специально открыт в open-source, чтобы каждый мог посмотреть и предложить PR. И главное: это не про "минимализм settings.py". Мы сознательно пошли против догмы Django, потому что для продукта подобного рода это оправданное решение.
Читаю и думаю, где-то я это уже видел. И точно! Это тот же автор, что обещал революцию в Django, но что-то пошло не так и революции не случилось.
Вот и тут. Опустим стиль изложения, и ответы автора на комментарии и погрузимся в работу пакета. Непонятно, почему репозиторий закрыт, потому работаем с версией, что получена с PyPy. И это настолько плохо, что даже хорошо плохо. Абсолютно согласен с @mrAsh4r - пакет не стоит ставить ни в каком случае. Даже автору ( @markolofsen) я бы порекомендовал это не ставить:
Задача управлять файлом, который не требует тестов, потому, что там нет кода, а только объявление констант - провалена. Написано столько кода, что чисто статиcтически (по хальстеду) получаем 100% наличие ошибок.
Задача управлять файлом без зависимостей от других библиотек, которая решается посредством дополнительной установки 91! библиотеки (я душнила, я посчитал) - это проваленная задача.
Задача понять как работают классы LazySettings, SettingsReference и UserSettingsHolder провалена, поскольку автор изобрел свои классы, дублирующие существующий функционал, только которые делают это хуже, чем оригинал.
Задача управлять одним файлом размером на 13kb при помощи библиотеки в 399 файлов в 109 папках с весом 3mgb, это даже не провал. Это просто п*3*eц какой-то.
Я не буду вдаваться в код который я нашел внутри django-cfg, потому, как вежливость призывает меня не использовать только бранные слова в описании увиденного.
Серьезно, если это реально авторский код, написанный человеком... то так это не решается. Ну или я чего-то глобально не понимаю.
Слушай, похоже, ты пока не совсем понимаешь, что за пакет. Паника про "399 файлов" и "3MB" без взгляда на реальный код выглядит как догадки, а не анализ ;-)
Лучше скачай пакет, посмотри, как всё устроено, и только потом делай выводы - иначе это просто домыслы.
Я посмотрел код еще до того как написать свой комментарий. Тебе надо пример? Смотрел там, где интересно решить мои задачи. Не всю шнягу, что прилетела из PYPY.
Апп support с Ticket/Message.
используете uuid. Зачем created_at если uuid содержит дату создания.
Зачем сортировка по created_at, если она и так уже по uuid сортирована.
Некешированное Поле last_message модели ticket выполняет запрос к базе. В админке вы используете значение поля дважды на list view. При 100 тикетах в admin-list это автоматически 1 + 200 запросов.
Некоторые места вообще непонятны, простой пример:
try:
from django_revolution import add_revolution_urls
...
except ImportError:
# Django Revolution not available - skip
passdjango_revolution в dependency. Ставится автоматически. С какой целью тут стоит эта проверка?
То, что я написал, это два места в 400 файлов. Могу больше, но зачем?
Слушай, у тебя прямо страсть искать изъяны в каждой строчке
Но по сути: uuid и created_at - разные сущности, их дублирование встречается в массе production-проектов, это норма. Но откуда тебе об этом знать?
А N+1 в админке да, бывает, решается элементарно и явно не тянет на "ой, все пропало".
Про try/except для django revolution - да это классический fallback, тут вообще придраться сложно. Но у тебя получилось, удивительно.
То есть ты описал не баги уровня "не ставить ни в коем случае" а обычные рабочие моменты, которые в любом реальном проекте решаются за час правками =) Странные у тебя выводы короче бро. Ну просто не твой продукт, пользуйся ванилой)
Всё-таки почему на гитхабе 404? Нк предположим, Вы сделали шедевр. Стандартная практика - код на гитхабе, issue, pull request, и т.д. - а сейчас что то не работает, Вы не отвечаете, все делают патчи в своих копиях?
Просто подготавливаемся, заметили что неправильно документация организована была. Поэтому сделали для удобства django-cfg create-project "My Awesome Project"
Скоро откроем на гитхабе, документацию готовим подробную.
Раз уж это случайность, что репозиторий закрыт, стоит ли ожидать остальные проекты в открытом доступе? pydantic2, pydantic3 и другие
Это не случайность, я сказал ранее, что документация готовится. А в чем собственно вопрос?
Стоит ли ожидать ваши проекты (в том числе django-cfg, pydantic2, pydantic3) в открытом доступе?
Надеяться всегда стоит определенно, можешь ожидать еще pydantic 4, 5, 6, 7... =)
https://github.com/markolofsen/django-cfg
Пример оторван от реальности. Обычно на написание settings.py закладывают месячный бюджет команды из 3-х senior-разработчиков и проджект-менеджера
Django: почему один settings.py может стоить вашей компании миллионы