RB
дело не в названиях разбитых файлов, мне сказали, что должен быть только один settings)
я спросил, но мне не дали ответа)
я спросил, но мне не дали ответа)
Size: a a a
2019 May 06
AK
Может что-то подобное ожидают
MA
Делить settings нормально, многие так делают. Но в первую очередь надо придерживаться стандартов, принятых в команде/проекте. Если это аутсорс, который временно привлекает специалистов со стороны, то стандарты должны быть задокументированы. Телепатов нет, понятие best practices очень размытое. Можно даже целый Django прект зафигачить в одном файле и будет удобно.
RB
в тестовом задании ничего не было сказано об этом) поэтому и делал как всегда!
RB
Мне многое в оценке не понравилось, но я после settings понял, что не подойду им)
AT
Всем привет!
нужно общее мнение) я делал тестовое на одну кантору и меня обматерили за разделение settings (base.py, local.py, production.py, test.py) и requirements (base.txt, local.txt, production.txt)! Я на всех своих проектах так делаю, чем может быть обосновано не разделение этих файлов или может я не правильно делаю разделяя их!
нужно общее мнение) я делал тестовое на одну кантору и меня обматерили за разделение settings (base.py, local.py, production.py, test.py) и requirements (base.txt, local.txt, production.txt)! Я на всех своих проектах так делаю, чем может быть обосновано не разделение этих файлов или может я не правильно делаю разделяя их!
Смотря как ты их разделял - одно дело повыносить некоторые специфические настройки из settings в *_settings, другое если полностью дублировать файл settings под другим именем и там править настройки.
AT
requirements имхо должен быть один, потом просто отдельно доставляешь gunicorn и psycopg2 и всё
EM
и под тесты, и под staging и под prod и под локальную?)
EM
RB
я написал, что в base все, что должно быть во всех вариантах, для local свои настройки и некоторые библиотеки, а в production только для прод. Для чего мне на прод тянуть django-debug-toolbar, django-extensions и т.д.
AT
Тебе их не обязательно писать в requirements
PB
Нормальный вариант
PB
Тебе их не обязательно писать в requirements
Офигенно
А если специфические версии? Помнить наизусть?
А если специфические версии? Помнить наизусть?
RB
если другой разработчик локально в себя тоже хочет поднять? я ему должен объяснять что я еще доставлял, чтобы оно локально было так как у меня?
AT
Спец версии чего, тестовых либ? Пошутил норм
EM
каждый уважающий себя разработчик должен помнить все версии либы наизусь, ага
TM
Спец версии чего, тестовых либ? Пошутил норм
Ну бывает такое, что определенные конфигурации работают в определенных случаях
TM
Ещё могли быть вопросы, если файлы друг в друга не иклудились, хотя могли