Yii environment. Наследования и переопределение конфигов

[@affka]

А по сколько строк в каждом из небазовых (типа Web.php) конфигов? Мы обычно сводим такие настройки в один файл production.php, т.е. на каждый env — свой дополнительный файл, который мержится с base и web/cli.
А вообще в данном аспекте «пули» быть не может, конфигурация сильно зависит от масштабов проекта. Но в одном всегда одинакого — должен быть файл config.php, который лежит в корне и которого нет в гите (на каждой машине — свой). И там идут переопределения настроек индивидуально для машины + пароли для БД/токены/… от продакшена, т.к. хранить пароли в гите — зло :)
Недавно для своего фреймворка делал основу для конфигурация, вот такие примеры получились — github.com/jiisoft/jii-workers/tree/master/examples

[@getId]

Что у вас за странная каша со статическими методами?

Устанавливаете вроде как в экземпляр

Environment::instance()->set(Environment::DEVELOPMENT);

а на самом деле в статику:

private function setEnvironment($level)
    {
        switch($level)
        {
            case 'PRODUCTION':
                self::$current = self::PRODUCTION;
                break;

И все последующие вызовы у вас через статические методы. Зачем private static $currentObj; ?

А по делу, есть немного другой подход через конфигурацию из окружения: github.com/vlucas/phpdotenv.
По ссылке объясняют, что в таком подходе хорошего.

[@alexsoft]

Поддерживаю phpdotenv.
Очень нравится вариант конфигов в Laravel. Всё, что меняется в зависимости от окружения, выносится в .env файл. Очень удобно!

[@SamDark]

Только не вздумайте в продакшне из файлов читать. getenv() / setenv() работают в рамках процесса, а не в рамках реквеста.

[@alexsoft]

bool putenv ( string $setting )

Adds setting to the server environment. The environment variable will only exist for the duration of the current request. At the end of the request the environment is restored to its original state.

Dotenv именно этой функцией устанавливает переменные. И всё работает отлично.

[@SamDark]

Нет.

[@alexsoft]

У меня просто везде nginx+php-fpm.

[@symbix]

Если даже предположить такую редкость, как тредовый SAPI — при нормально организованном деплое приложение разворачивается каждый раз в новый каталог, так что никаких побочных эффектов вызвать не должно. А на каком-нибудь шареде с mpd_php + threaded mpm (а такое бывает?) — ну там и с setlocale аналогичные проблемы.

[@SamDark]

Вообще mpm не так уж и редок, если всё работает на апаче.

[@SamDark]

Проблема не в каталогах, а в том, что это shared-данные, которые пишут-читают-ресетят без лока сразу неколько «клиентов».

[@symbix]

dotenv сначала пробует $_ENV и $_SERVER, а уже потом getenv, так что проблемы быть не должно даже в таком редком случае — конечно, если пользоваться $loader-> getEnvironmentVariable(), а не напрямую getenv().

[@SamDark]

Если задавать переменные в окружении — не должно быть. Если читать из файлов — будут обязательно.

[@symbix]

А какая разница?

[@SamDark]

github.com/vlucas/phpdotenv/issues/76

[@symbix]

А, в смысле задавать во внешнем окружении, до запуска реквеста? Так понятнее, а то непонятно — какая разница откуда читать.

Но все равно же, по идее, проблем не будет, если пользоваться $loader-> getEnvironmentVariable(). Там просто не дойдет до нереентерабельного getenv и прочитается из $_ENV (равно как и запишется в него же). В environment будет бардак, но а какая разница, если в $_ENV все на месте?

[@SamDark]

Если именно из $_ENV читать, проблемы нет. Разве что если на сервере более одного проекта, бардак начинается ещё и с именованием этих самых переменных. Но тут была речь про чтение именно из .env-файликов в продакшне, что, при определённых условиях, будет как раз проблемой.

[@bohdan-shulha]

Мы пользуем концепцию *local файлов. Пишем конфиг, который повторяется у всех, а потом мерджим в него main-local.php, который уникален для каждого разработчика и сервера. Не dotenv, конечно же, но явно проще, чем нагородил автор.