Комментарии 22
Обычно бывает обратная проблема, когда в env.example были внесены изменения, о которых не подозреваешь, и которые надо бы перенести в .env
Сколько сталкивался, в 90% случаев все забивают на файл .env.example, в 9% случаев копируют в него содержимое .env с адресами, явками и паролями и лишь в 1% всё делают по уму.
.env файл — это настройки локального окружения. В том случае, когда файл .env.example содержит в себе пресет каких-то ключей, в конфиге у них явно указано дефолтное значение в случае отсутствия определения. Таким образом, если разраб не перенес себе их в .env — это никак не мешает работе. А когда столкнётся, увидит каких именно ключей не хватает.
Именно поэтому автоматом копировать из .env.example в .env — плохая идея. А вот в обратную сторону — хорошая.
Внимательность к статье 80 lvl
Чем мой комментарий нерелевантен на ваш взгляд?
Через "реальные" переменные окружения давно в любом проекте можно подставлять данные. На то это переменные окружения и есть.
Симфа юзает шифрованный вариант. Это хорошо. Но лично я не работал с ней напрямую, поэтому не могу сказать кто, что и как там хранит. А, точнее, кто где и как косячит. Вы и без меня знаете, что таких людей много.
Лично я никогда не хранил логины и пароли в репозитории, и также лично видел как многие их туда суют со словами "ну а чо, в телеге, что ли, передавать?" И на замечание что у каждого разработчика должно быть настроено своё личное окружение и эти настройки позволяют это безболезненно сделать, выпучивают глаза так, как если б доисторические люди увидели НЛО.
Конкретное пакетное решение позволяет обновить файл .env.example ключами из .env стерев все приватные данные, о чём написано в теле статьи.
Так а зачем нужно иметь два файла .env и .env.example?
Угадай в каком файле разработчики хранят настройки своего личного локального окружения, и в каком находится пресет со списком ключей, сохраняемых в репозиторий.
Что такое пресет со списком ключей, сохраняемых в репозиторий?
.env никогда ни при каких обстоятельствах не должен комититься в репозиторий. За коммит с ним руки отрубают по самые пятки.
В зависимости от используемых методов, приложение подтягивает настройки окружения из файла. Например, Laravel юзает пакет vlucas/phpdotenv, читающий как раз .env.
Именно поэтому пресет настроек хранится именно в файле .env.example, который не должен содержать логины, пароли и другие приватные либо специфические данные.
Пресет (preset) — это готовый набор чего-либо, который "берёшь и используешь". В случае с .env.example — копипастишь содержимое его в файл .env и получаешь нужные ключи, которые останется только заполнить на основании настроек личного окружения.
В Symfony — не так: https://symfony.com/doc/current/configuration.html#overriding-environment-values-via-env-local
Описание изменений https://symfony.com/doc/current/configuration/dot-env-changes.html
Из плюсов:
Не надо переназначать все переменные, а только те, которые отличаются.
Если добавились новые параметры они автоматом подтянутся.
Понял разницу.
В симфе основной файл — .env. Он содержит все настройки окружения. Включён в репозиторий. Для локальной разработки нужно скопипастить содержимое файла .env в файл .env.local и заполнить значение ключей.
В Ларе основной файл — .env. Он содержит все настройки окружения. НЕ включён в репозиторий. Для локальной разработки нужно скопипастить содержимое файла .env.example в файл .env и заполнить значение ключей.
При этом, в конфиге Лары может быть обращение вида env('DB_HOST', '127.0.0.1'). То есть, если явно не указывать значение в файле .env, то будет взято значение по-умолчанию. Это обычная работа окружения (env).
Для локальной разработки нужно скопипастить содержимое файла .env в файл .env.local и заполнить значение ключей.
Идея как раз в том, что копировать содержимое не нужно, а только тех переменных, которые отличаются. К примеру, APP_NAME, порты БД, Redis etc дублировать нет смысла
Ещё раз:… если явно не указывать значение в файле .env, то будет взято значение по-умолчанию. Это обычная работа окружения (env).
Это не Laravel и не Symfony, не Yii и не какой-нибудь Zend — вообще по-барабану что. Это система работы самих настроек окружения. И она так работает. А вот в каких файлах это хранится — каждый проект выбирает под себя.
Еще раз… Для Symfony ваш пакет бесполезен, т.к. .env загружается всегда, а .env.local не содержит всех параметров.
Даже если представить, что разработчик добавил новый параметр в .env.local и забыл его указать в .env, ваша утилита генерирует неверный код:
.env (aka .env.example)
FOO=foo
BAR=bar
BAZ=baz.env.local (aka .env)
# перезаписанный параметр
FOO=my-foo
# новый параметр
NEW=new У вас генерируется:
FOO=null
NEW=nullМы говорим об одном и том же, но кое что я приметил.
Подскажите, в симфони через env('FOO') обращение идёт или пыхным методом getenv()? Или какой пакет используется под капотом?
Эти переменные используются в описании сервисов и конфигов, т.е. напрямую в коде обращения к ним нет. Загрузка идет через Dotenv компонент. Если вдруг понадобится, то можно обратится к ним стандартным способом, но это не рекомендуется и может привести к ошибкам компиляции контейнера.
Если речь про дефолтные значения, то их можно задать в конфиге:
parameters:
env(FOO): barно не думаю, что так кто-то делает, если они все равно загружаются из .env. Иначе это добавляет еще одно место, где нужно синхронизировать дефолтные значения.
Правильно понимаю, что вам нужно синхронизировать дефолтные значения не только в .env.example, но и везде, где эти переменные используются (к примеру, везде где есть вызов env('FOO', 'bar'))?
.env активно используется другими тулами, которые не умеют в те же механизмы, что сделали в симфони. Например .env автоматически подхватывается docker-compose и коммитить локальные изменения для докер-композа (например мы тюним работу с xdebug под личные предпочтения и настройки окружения) — это как-то фу.
Слава богу это сугубо опциональный механизм и его можно имплементировать как хочется, в т.ч. старым способом
Фабиен тот же человек и склонен ошибаться как и любой другой. И случается так, что кто-то предлагает крутую, по их мнению, фишку, а на деле оказывается…
Верно, весь софт, который работает с настройками окружения, обращается именно к файлу .env. И это глупо, на мой взгляд, изменять это поведение в одном проекте, заставляя этот файл пихать в репу.
А как пройдут тесты в удаленном CI, если нет дефолтных значений и переменные явно не применили?
Environment Synchronization