Re: [PHP-DEV] Proposal: php.ini environment variable fallback value

This is only part of a thread. view whole thread
  111199
July 27, 2020 07:01 michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)
Hi Derek,

pt., 24 lip 2020 o 22:54 Derek Bonner <derek@derekbonner.com> napisał(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 extended > 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 understanding > of the current .ini parser so this may make invalid assumptions. > > * memory_limit = ${PHP_MEMORY_LIMIT:-"default value"} > * memory_limit = ${PHP_MEMORY_LIMIT::"default value"} > * memory_limit = ${PHP_MEMORY_LIMIT:="default value"} > * memory_limit = ${PHP_MEMORY_LIMIT=="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=[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ł Marcin Brzuchalski