V
А каждый разработчик сам лично убирает .sample
Хреновая идея. Настраиваться должно как можно меньше, потому что со временем dev.exs изменится, но у разных разрабов по-разному. Настраиваться должны только переменные окружения.
Size: a a a
2020 June 21
T
V
Хреновая идея. Настраиваться должно как можно меньше, потому что со временем dev.exs изменится, но у разных разрабов по-разному. Настраиваться должны только переменные окружения.
не было ещё таких прецедентов, при которых нельзя было бы сказать в чат: "ребят, добавьте кое-что себе в dev.exs
V
Я лично делаю загитигноренный dev.custom.exs и импортирую его внутри dev.exs только в том случае, если он существует.
Хреновая-идея-2. Это способ получить два разнонастроенных приложения на двух разных локалхостах.
V
Ребят, пытаюсь понять, как мне нормально грузить конфиги из переменных среды в Phoenix. В Ruby on Rails я обычно использую dotenv. На форумах предлагают делать
source .env && mix phx.server, но что-то это как-то error prone. Есть какие-то идеи получше? Цель — иметь возможность каждому разработчику настроить свою среду через переменные среды. В проде, кажется, можно обойтись настройкой через rel/env.sh.eex, используя Mix Releases, так что вопрос в основном про среду разработки.Шелл-скриптом, в котором инициализируются переменные, а потом запускается микс
ŹR
Wat? «Способ получить два разнонастроенных приложение на двух разных хостах» - в этом и задача
V
Wat? «Способ получить два разнонастроенных приложение на двух разных хостах» - в этом и задача
Нет, задача - дать одному приложению разное окружение, а не сделать разные приложения
ŹR
«Разное окружение» это деталь реализации. Задача - «разработчик по разному настраивает своё приложение»
ŹR
А с учётом того, что env, загружаемые в микс конфиг в половине эликсирных зависимостей вкомпилируется внутрь бимов все равно, что бы ты не делал - у разработчиков будут разные приложения В ЛЮБОМ случае
ŹR
А те которые НЕ вкомпилируются в бимы, вкомпилируются в sys.config, который так же не относится к окружению, а относится к релизу
ŹR
В результате попытка сделать одинаковое но настраиваемое где-то там приложение обречена на провал сразу и заранее
V
«Разное окружение» это деталь реализации. Задача - «разработчик по разному настраивает своё приложение»
Предлагаешь настраивать приложение на локалхостах как-то иначе чем через переменные окружения?
ŹR
Возможно есть какой-то смысл в переменных окружения, но в моих обычных проектах достаточно иметь mix config
ŹR
И я ещё ни разу не имел с этим проблем
V
А, это не ты предлагаешь. Ты предлагаешь инклюдить-dev.custom.exs-если-он-есть, а если его нет - молча продолжать работать дальше.
V
И я ещё ни разу не имел с этим проблем
Я имел
V
Сначала ты даёшь возможность иметь кастомный dev.exs, потом у тебя усложняется конфигурация, потом появляется dependency injection, потом одно накладывается на другое, и вот уже ты не знаешь - с какой конфигурацией твой коллега тестировал фичу перед коммитом, и благо если она покажет ошибку у тебя на локалхосте, а не в проде.
MK
V
Шелл-скриптом, в котором инициализируются переменные, а потом запускается микс
Что делать с микс тасками? Например,
mix ecto.migrate. Не писать же для каждой команды враппер с загрузкой переменных среды.MK
V
Сначала ты даёшь возможность иметь кастомный dev.exs, потом у тебя усложняется конфигурация, потом появляется dependency injection, потом одно накладывается на другое, и вот уже ты не знаешь - с какой конфигурацией твой коллега тестировал фичу перед коммитом, и благо если она покажет ошибку у тебя на локалхосте, а не в проде.
Согласен, такое бывает и не редко. Может быть даже банальная ошибка коммуникации в команде.
MK
И ещё что думаете про vapor?
https://github.com/keathley/vapor
Я не пробовал, но как будто он решает эту задачу.
https://github.com/keathley/vapor
Я не пробовал, но как будто он решает эту задачу.
ŹR
V
Сначала ты даёшь возможность иметь кастомный dev.exs, потом у тебя усложняется конфигурация, потом появляется dependency injection, потом одно накладывается на другое, и вот уже ты не знаешь - с какой конфигурацией твой коллега тестировал фичу перед коммитом, и благо если она покажет ошибку у тебя на локалхосте, а не в проде.
То есть с каким env он тестировал фичу ты знаешь?))