Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111199
MIME-Version: 1.0
References: <CAB2bceYYB6GpuPU=zdMZi-Xo7=jO9DdhGFEBnWwyqsQ5wagwrQ@mail.gmail.com>
In-Reply-To: <CAB2bceYYB6GpuPU=zdMZi-Xo7=jO9DdhGFEBnWwyqsQ5wagwrQ@mail.gmail.com>
Date: Mon, 27 Jul 2020 09:01:00 +0200
Message-ID: <CABdc3Wp=H6p6RK99cuq2muu2UMs3-MLWaJv_o26jFDD4chDqRA@mail.gmail.com>
To: Derek Bonner <derek@derekbonner.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000051103f05ab66e389"
Subject: Re: [PHP-DEV] Proposal: php.ini environment variable fallback value
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--00000000000051103f05ab66e389
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Derek,

pt., 24 lip 2020 o 22:54 Derek Bonner <derek@derekbonner.com> napisa=C5=82(=
a):

> Currently an environment variable can be specified in the php.ini file.
> This is useful if you want tune one or two settings in your runtime
> environment. Where this runs into issues is if you want to do something
> similar to Juan Terminio[1][2].
>

I do agree that this is hard to apply INI setting on Docker environment.


> I'm proposing a change the php.ini parser that would allow for an extende=
d
> syntax for environment variables in the php.ini. In this syntax when
> checking for an environment variable if it is empty the fallback value
> would be used instead. The original environment variable syntax would
> remain valid as well.
>

I disagree here. IMO INI setting should remain static.


> Possible syntax options. I currently do not have a very deep understandin=
g
> of the current .ini parser so this may make invalid assumptions.
>
> * memory_limit =3D ${PHP_MEMORY_LIMIT:-"default value"}
> * memory_limit =3D ${PHP_MEMORY_LIMIT::"default value"}
> * memory_limit =3D ${PHP_MEMORY_LIMIT:=3D"default value"}
> * memory_limit =3D ${PHP_MEMORY_LIMIT=3D=3D"default value"}
>

I do like the idea of applying INI settings with environment variables but
I believe
we should not change anything by providing complex INI parsing rules.

Your proposal inspired me to think of it more and think of potential RFC
for changing the configuration mechanism we use in PHP so it can be
slightly refactored and extracted from zend_ini into zend_config with
additional
configuration providers for "argv" values, environment variables,
INI settings and extension provider.

I believe and hope it has a potential and allows us to make things more
clear when talking
about INI settings.
We always talk about INI settings while INI is just a file format and we
apply internally
INI settings from different sources like `-d` options from the command line
or provided
by extension like mentioned in the thread .htaccess.

In summary, potential RFC proposal would be:
1. extract zend_config from zend_ini, INI directives will in a future be
considered a configuration settings/directives whatever;
2. implement different prioritized configuration providers for CLI argv,
INI files, ext, environment variables - allowing to resolve
configuration settings in a specific order

This will in a future open wide range of possibilities, like new formats to
be implemented via file format, specific configuration provider.

Why it cannot be handled by a specialised library?
1. On environments with dl disabled you cannot load additional extension
without adding it to INI files or by `-dextension=3D[ext]` CLI option.
2. If you struggle with memory limit or time limit you cannot change it if
the script calls another script via proc_open or exec without applying INI
file setting, even a CLI option won't help here but an environment variable
could.
3. In modern stacks like k8s or Docker when a container is immutable per
se, you cannot modify for eg. memory_limit, or enable/disable OPcache, tune
OPcache flags, enable/disable Xdebug without changing INI files but you
could do that easily by an environment variable, via docker-compose
environment settings, docker -e options, or by editing a deployment on k8s
by hand to apply different settings for investigation purposes.

I'd like to hear other opinions about it.

Cheers,
Micha=C5=82 Marcin Brzuchalski

--00000000000051103f05ab66e389--