14.09.2025 09:51
markolofsen 0 3700 Источник

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

Эти ритуалы жрут месяцы жизни компаний, и об этом мало кто говорит.
Я расскажу историю. Она звучит как анекдот, но на самом деле это кейс.

История Васи и Пети

В компании «Рога и Продакшн» решили запустить новый сервис.
Назначили двух разработчиков:

  • Вася — senior Django-разработчик.

  • Петя — middle, но с django-cfg.

Вася: путь традиции

  • Первые три дня он копировал старый settings.py.

  • Потом неделю правил INSTALLED_APPS.

  • Потом два дня воевал с ALLOWED_HOSTS.

  • Потом переписывал DATABASES под дев, тест и прод.

  • Потом поймал баг, потому что написал DEBUG="yes".

  • Потом завёл .env и сказал, что «всё по best practices».

К концу месяца Вася гордо показал: «проект готов к написанию бизнес-логики».

Петя: путь революции

  • Написал конфиг в 10 строк через django-cfg.

  • Запустил сервис на следующий день.

  • На третий день уже писал бизнес-логику.

  • Через неделю показал работающий релиз.

Счёт компании

Ставка разработчика — $4000/мес.

  • Вася потратил 1,5 месяца на конфиги → $6000.

  • Петя сделал то же за 1 день → $200.

Разница: $5800 в мусорное ведро только из-за того, что Вася верил в магию settings.py.

В чём суть django-cfg?

  • Типизированные конфиги на Pydantic (никаких «строка вместо bool»).

  • Готовые пресеты для DRF, Spectacular и прочего.

  • Зоны API: public, admin, internal — настраиваются декларативно.

  • Автогенерация Python + TypeScript клиентов с авторизацией и токенами.

  • Ноль копипаста: один файл → всё готово.

А теперь вопрос для работодателей

Когда вы видите строку в бюджете «1,5 месяца на подготовку окружения»,
вы думаете, что это реальная работа?

Нет. Это Вася-джанго-разработчик обосновывает своё существование.

А Петя уже сделал продукт.

Потому что django-cfg убирает то, на чём они десятилетиями строили иллюзию «сложной инженерной работы».
Ритуалы исчезают. Остаётся продукт.
А продукт видно директору.

Заключение

Каждая компания выбирает:

  • Либо оплачивать шаманство с settings.py.

  • Либо делать проекты быстро и прозрачно.

django-cfg на PyPI

Комментарии (0)


  1. whoisking
    14.09.2025 10:07
    #28834470

    Успей скачать, только сегодня!

    P.S. , чёто у вас гитхаб 404 и странные пакеты на pypi, напр. "pydantic2"


    1. markolofsen Автор
      14.09.2025 10:07
      #28834474

      как-то сам себе противоречишь))) если бы "успей скачать сегодня", то гитхаб был бы открыт. Это скорее пост к размышлению


  1. andreymal
    14.09.2025 10:07
    #28834476

    Первые три дня он копировал старый 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 для меня у вас не получилось


    1. markolofsen Автор
      14.09.2025 10:07
      #28834506

      ну так не было такой задачи)


      1. kez
        14.09.2025 10:07
        #28834566

        Любопытно узнать, в чём же была задача статьи


        1. ktori
          14.09.2025 10:07
          #28834610

          Реклама.


          1. markolofsen Автор
            14.09.2025 10:07
            #28834706

            Где?


        1. markolofsen Автор
          14.09.2025 10:07
          #28834708

          Создать дискуссию


    1. markolofsen Автор
      14.09.2025 10:07
      #28834776

      Да, да, конечно, копипастить из local_settings.py — это инновация уровня Илона Маска)))))


  1. ktori
    14.09.2025 10:07
    #28834548

    Абсурдная рекламная статья про ии-сгенерированную библиотеку с миллионом зависимостей и непонятным набором функций, с ии-сгенерированной КДПВ. Как связан текст статьи про settings.py с библиотекой которая интегрируется с телеграмом, ллмками, получением курса валют из ЦБ РФ и ЕЦБ и всеми остальными идеями возникшими в агонии безымянной видеокарты из кластера где-то в душном датацентре?


    1. markolofsen Автор
      14.09.2025 10:07
      #28834704

      Вопрос то в чем?


    1. markolofsen Автор
      14.09.2025 10:07
      #28834778

      То есть твой settings.py с копипастой из десятка туториалов - это зрелость, а библиотека с готовыми интеграциями это "миллион зависимостей" ?

      Красиво оправдывать болото умеешь!)


  1. soymiguel
    14.09.2025 10:07
    #28834754

    А если написать, что Вася потратил полтора гугильона пупильонов денег и 3 тыщи лет на INSTALLED_APPS, то станет еще драматичнее.

    Правда, убедительно это звучало бы от лица Саши Пряникова, евпочя.


    1. markolofsen Автор
      14.09.2025 10:07
      #28834756

      Оставлю без комментария


      1. dopusteam
        14.09.2025 10:07
        #28835072

        Вы буквально оставили комментарий


  1. mrAsh4r
    14.09.2025 10:07
    #28835980

    Увидя название статьи, подумал будет статья о безопасности, о грамотной настройке 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) с минимальными зависимостями и прозрачной историей.


    1. mrAsh4r
      14.09.2025 10:07
      #28835998

      И это ведь я ещё не изучил сам исходный код проекта и каждого импорта (кой их 30+ загружается вместе с django-cfg).

      На мой взгляд это выглядит как попытка supply-chain атаки. Особенно если учесть названия проектов, которые созвучны с полноценными, известными проектами. (pydantic2 чего стоит, или аналогия ТС на django-configurations)


    1. markolofsen Автор
      14.09.2025 10:07
      #28836664

      После твоего коммента ясно, кто тут настоящий Вася. Паника про "190+ файлов", "subprocess" и "supply-chain атаки" без единого взгляда на код - это уровень джуниора, который видит Django впервые.

      Репо недоступно? Да скачай PyPI пакет и посмотри реальный код, а не придумывай страшилки по README. Весь функционал это набор опциональных модулей и CLI-инструментов, которые не выполняются сами по себе в продакшене. Никаких "эксфильтраций", никаких "рисков цепочки поставки" - это твои страхи, а не факты.

      Выдавать "не использовать в проде" на основании домыслов? - чистый middle-tier уровень. Senior сначала смотрит код, потом делает выводы, а не пугает всех страшными словами.

      Короче, прежде чем раздавать советы про безопасность и архитектуру - сначала открой пакет, пойми, что делает каждая строчка, и только потом делай выводы. Всё остальное - трёп, чтобы казаться экспертом.


      1. mrAsh4r
        14.09.2025 10:07
        #28837192

        Слушай, я может и не шарю, но твоя статья же по сути про то, что "зачем платить сеньору, если можно мидла с cfg взять".

        Ты мне сам пишешь, что я — мидл, потому что "не использовать в проде".

        Тогда выходит, что твой тул для мидлов, а мидлы его и не берут.

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


        1. markolofsen Автор
          14.09.2025 10:07
          #28838470

          По фактам:

          проект открыт, код доступен, всё можно проверить руками. Если твоя уверенность держится только на предположениях - это не экспертиза, это воображение.

          А вот в реальном продакшене решают не страшные слова, а рабочие инструменты. И тут всё просто - кто умеет, тот проверяет и использует. Кто не умеет - тот пишет, что "мидлы не возьмут".

          Замкнутый круг, да :)


          1. danilovmy
            14.09.2025 10:07
            #28839880

            Нет никакого замкнутого круга. Кто может - идет на 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.


            1. andreymal
              14.09.2025 10:07
              #28840282

              Справедливости ради с того же pypi.org можно скачать tar.gz, в котором «всего» пара сотен файлов


              1. danilovmy
                14.09.2025 10:07
                #28840348

                Спасибо. Вот такой вариант сработал:

                pip download django-cfg --no-deps --no-binary django-cfg


          1. kez
            14.09.2025 10:07
            #28844738

            проект открыт, код доступен, всё можно проверить руками.

            кажется это не совсем так, зато можно пораздоваться что проект открыт к изменениям со стороны сообщества

            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':

            бывает, мне тоже иногда лень читать что там чатгпт нагенерил


  1. danilovmy
    14.09.2025 10:07
    #28836188

    Читаю и думаю, где-то я это уже видел. И точно! Это тот же автор, что обещал революцию в Django, но что-то пошло не так и революции не случилось.

    Вот и тут. Опустим стиль изложения, и ответы автора на комментарии и погрузимся в работу пакета. Непонятно, почему репозиторий закрыт, потому работаем с версией, что получена с PyPy. И это настолько плохо, что даже хорошо плохо. Абсолютно согласен с @mrAsh4r - пакет не стоит ставить ни в каком случае. Даже автору ( @markolofsen) я бы порекомендовал это не ставить:

    1. Задача управлять файлом, который не требует тестов, потому, что там нет кода, а только объявление констант - провалена. Написано столько кода, что чисто статиcтически (по хальстеду) получаем 100% наличие ошибок.

    2. Задача управлять файлом без зависимостей от других библиотек, которая решается посредством дополнительной установки 91! библиотеки (я душнила, я посчитал) - это проваленная задача.

    3. Задача понять как работают классы LazySettings, SettingsReference и UserSettingsHolder провалена, поскольку автор изобрел свои классы, дублирующие существующий функционал, только которые делают это хуже, чем оригинал.

    4. Задача управлять одним файлом размером на 13kb при помощи библиотеки в 399 файлов в 109 папках с весом 3mgb, это даже не провал. Это просто п*3*eц какой-то.

    Я не буду вдаваться в код который я нашел внутри django-cfg, потому, как вежливость призывает меня не использовать только бранные слова в описании увиденного.

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


    1. markolofsen Автор
      14.09.2025 10:07
      #28836666

      Слушай, похоже, ты пока не совсем понимаешь, что за пакет. Паника про "399 файлов" и "3MB" без взгляда на реальный код выглядит как догадки, а не анализ ;-)

      Лучше скачай пакет, посмотри, как всё устроено, и только потом делай выводы - иначе это просто домыслы.


      1. danilovmy
        14.09.2025 10:07
        #28837670

        Я посмотрел код еще до того как написать свой комментарий. Тебе надо пример? Смотрел там, где интересно решить мои задачи. Не всю шнягу, что прилетела из PYPY.

        Апп support с Ticket/Message.

        1. используете uuid. Зачем created_at если uuid содержит дату создания.

        2. Зачем сортировка по created_at, если она и так уже по uuid сортирована.

        3. Некешированное Поле 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
        pass

        django_revolution в dependency. Ставится автоматически. С какой целью тут стоит эта проверка?

        То, что я написал, это два места в 400 файлов. Могу больше, но зачем?


        1. markolofsen Автор
          14.09.2025 10:07
          #28838448

          Слушай, у тебя прямо страсть искать изъяны в каждой строчке
          Но по сути: uuid и created_at - разные сущности, их дублирование встречается в массе production-проектов, это норма. Но откуда тебе об этом знать?
          А N+1 в админке да, бывает, решается элементарно и явно не тянет на "ой, все пропало".
          Про try/except для django revolution - да это классический fallback, тут вообще придраться сложно. Но у тебя получилось, удивительно.

          То есть ты описал не баги уровня "не ставить ни в коем случае" а обычные рабочие моменты, которые в любом реальном проекте решаются за час правками =) Странные у тебя выводы короче бро. Ну просто не твой продукт, пользуйся ванилой)


          1. kez
            14.09.2025 10:07
            #28844746

            сейчас никому не нужны сгенеренные нейронкой пакеты, и в этом основная претензия людей — статья с очень громким заголовком, в теле которой есть ссылка на созданный автором пакет, и смысл которой был в "создании дискуссии"

            нет предмета дискуссии, банально нечего обсуждать


  1. KonstantinTokar
    14.09.2025 10:07
    #28836714

    Всё-таки почему на гитхабе 404? Нк предположим, Вы сделали шедевр. Стандартная практика - код на гитхабе, issue, pull request, и т.д. - а сейчас что то не работает, Вы не отвечаете, все делают патчи в своих копиях?


    1. markolofsen Автор
      14.09.2025 10:07
      #28836728

      Просто подготавливаемся, заметили что неправильно документация организована была. Поэтому сделали для удобства django-cfg create-project "My Awesome Project"
      Скоро откроем на гитхабе, документацию готовим подробную.


      1. kez
        14.09.2025 10:07
        #28844742

        Раз уж это случайность, что репозиторий закрыт, стоит ли ожидать остальные проекты в открытом доступе? pydantic2, pydantic3 и другие