Не понимаю, зачем мне селери (как дополнительная отдельная зависимость, что тянет за собой еще 2+ доп зависимости), которую надо постоянно мониторить, поддерживать и обновлять ради того чтоб раз в день запускать один простой скрипт?

rqworker, apscheduler - что угодно лучше чем crontab

Пришёл в проект, в котором все считали также и поздно опомнились - 49 крон тасков пришлось переносить

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

Началось ведь с 1-го:D

Смотри мой пример про магазин и космолет

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

Не нужно оверинжинирить сразу

Кронтаб железно работает и прост как пробка

Любой из данных мной примеров даётся за 5-6 минут, разницы никакой, в чем проблема?) в паре десятков мб на лишнюю библиотечку?)

"библиотечку" - это ты смешно пошутил. Селери - огромный проект (включает в себя три пакета celery+kombu+billiard), для работы которого нужна работающая очередь (rabbitmq или redis), нужен полноценный мониторинг и мейнтенанс. У меня на паре больших проектов селери течет по памяти. Где-то я не могу обновить селери, потому что он конфликтует с каким-то другим пакетом или версией чего-то. Там сейчас открыто 327 issues на гитхабе, из которых я штук на 5 как минимум подписан и жду когда мейнтейнеры что-то с этим придумают

Здесь согласен, неправ, сам тоже упёрся в такие же проблемы и сейчас только собственный форк и pr спасают. Но что же с apscheduler, rq scheduler? Достаточно простые пакеты

Ура, смотри, мы куда-то движемся. Теперь ты понял что звездолет для магазина может быть немного слишком и предлагаешь самолеты

В целом, поработав некоторое время в software engineering начинаешь понимать, что лучший код - это когда кода нет :)

crontab это довольно простая приблуда, которая не требует никакой поддержки в общем и целом (в сравнении с другими вещами). Я всегда предпочту ее каким-то очередям и прочему пока она будет решать мою простую задачу

Согласен, но я ещё предпочитаю меньше кода и в будущем, поэтому считаю что задачи уровня приложения не должны решаться на уровне ос:D

По мне так rq scheduler - пакет уровня «велосипед» - подключал когда celery был слишком жирным

Для скедулера нужен еще редис как минимум. Это может быть лишним и еще одна точка отказа

Человек сказал, что он изучает еще django, не нужно сходу бросать его в глубоководную реку. Крон прекрасно справится с поставленной задачей, все будет работать. Когда человек упрется в лимиты, можно будет улучшить.

Контейнер с дампом в volume и мониторинг встроенный в Django admin - хотя бы сразу видно будет что, как и когда сломалось:)

Примерно так же мне оправдались бывшие разработчики проекта, которые потом 5 лет поддерживали и расширяли список этих задачек, не думая о последствиях, а один из них теперь в booking:D