Как стать автором
Обновить

Комментарии 22

Немного странно, в какой ситуации можно забыть скопировать из .env в .env.example?
Обычно бывает обратная проблема, когда в env.example были внесены изменения, о которых не подозреваешь, и которые надо бы перенести в .env

Сколько сталкивался, в 90% случаев все забивают на файл .env.example, в 9% случаев копируют в него содержимое .env с адресами, явками и паролями и лишь в 1% всё делают по уму.


.env файл — это настройки локального окружения. В том случае, когда файл .env.example содержит в себе пресет каких-то ключей, в конфиге у них явно указано дефолтное значение в случае отсутствия определения. Таким образом, если разраб не перенес себе их в .env — это никак не мешает работе. А когда столкнётся, увидит каких именно ключей не хватает.


Именно поэтому автоматом копировать из .env.example в .env — плохая идея. А вот в обратную сторону — хорошая.

В Symfony, например, .env.example давно не используется, переменные либо подставляются через реальные переменные окружения, либо используются зашифрованные секреты. Вы .env файл с секретами прямо в репозиторий пушите?

Внимательность к статье 80 lvl

Чем мой комментарий нерелевантен на ваш взгляд?

Через "реальные" переменные окружения давно в любом проекте можно подставлять данные. На то это переменные окружения и есть.


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


Лично я никогда не хранил логины и пароли в репозитории, и также лично видел как многие их туда суют со словами "ну а чо, в телеге, что ли, передавать?" И на замечание что у каждого разработчика должно быть настроено своё личное окружение и эти настройки позволяют это безболезненно сделать, выпучивают глаза так, как если б доисторические люди увидели НЛО.


Конкретное пакетное решение позволяет обновить файл .env.example ключами из .env стерев все приватные данные, о чём написано в теле статьи.

Так а зачем нужно иметь два файла .env и .env.example?

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


Спойлер.

Дефолтные настройки хранятся в .env (коммитится в репозиторий), который собственно используется приложением. Локально переменные можно переопределить в .env.local (никогда не коммитится).

Что такое пресет со списком ключей, сохраняемых в репозиторий?

.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. И это глупо, на мой взгляд, изменять это поведение в одном проекте, заставляя этот файл пихать в репу.

Ага, вот разница между Symfony & Laravel.

А как пройдут тесты в удаленном CI, если нет дефолтных значений и переменные явно не применили?

Для тестов в Ларе создаётся файл .env.testing и в phpunit.xml указывается <env name="APP_ENV" value="testing"/>
Окружение само подтянет файл .env.testing с настройками окружения. Либо можно в самом CI их задать.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.