Re: [PHP-DEV] Registration on wiki

[[ ]]

Thank you, I will do that.

On Tue, Jul 28, 2020 at 8:46 AM Kalle Sommer Nielsen  wrote:

>
>
> tir. 28. jul. 2020 kl. 08.39 skrev [ ] :
>
>> When I try to register on https://wiki.php.net/?do=register ,
>> 
>> Such error is generated: "That wasn't the answer we were expecting".
>
>
>
> This means you failed the captcha on the registration form, please read
> the page in detail and it should be a walk in the park.
>
> -K
>
>> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>

Re: [PHP-DEV] Registration on wiki

[Kalle Sommer Nielsen]

tir. 28. jul. 2020 kl. 08.39 skrev [ ] :

> When I try to register on https://wiki.php.net/?do=register ,
> 
> Such error is generated: "That wasn't the answer we were expecting".



This means you failed the captcha on the registration form, please read the
page in detail and it should be a walk in the park.

-K

> --
regards,

Kalle Sommer Nielsen
ka...@php.net

[PHP-DEV] Registration on wiki

[[ ]]

When I try to register on https://wiki.php.net/?do=register ,

Such error is generated: "That wasn't the answer we were expecting".

## Credentials:

Username: rela589n
Real name: Eugene Sidelnyk
E-Mail: zsidel...@gmail.com

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

[Derek Bonner]

On July 27, 2020 at 8:27:07 PM, Michael Morris (tendo...@gmail.com) wrote:

You mention Docker - usually I've seen it used alongside Ansible, Chef or
Puppet. Each of these provisioning programs can modify the php.ini file
used on the container at deploy time without necessitating a change to PHP
itself. What advantage does the community gain from moving these decisions
from the provision files to the php.ini file?


My use case is specifically Docker and Kubernetes. Like Michal said,
containers aim to be immutable. When we deploy containers they are built
via CI with a specific base image sets up PHP with the extensions we need
and then creates a layer for our application. That means to change any one
configuration value in the php.ini file would trigger a rebuild of the
container.CI would then rebuild the container and deploy it. That can take
minutes at times. The quick way would be to change an environment variable,
mark all old containers as bad and any new ones pick up the new environment
setting as they fill in for the bad ones. Another use case. We have a
private Kubernetes stack for a specific client. With environment variables
we can turn the php.ini using environment variable but each time a new
config value is used this way we have to make sure that same environment
variable is exposed to the container. The ability to have a fallback value
while not 100% necessary does have the ability to reduce errors around
environment variables in Docker/Kubernetes deployments.

We don’t use Ansible, Chef, or Puppet. Everything is CI and kubectl. I
might understand using these tools if you are running your own Kubernetes
stack but we are not currently doing that.

On July 26, 2020 at 10:18:23 PM, Michał Marcin Brzuchalski (
michal.brzuchal...@gmail.com) wrote:

Personally I like the idea of setting ini directives via environment
variables but not by a complex syntax in ini files but rather by looking up
for a directive by environment variable name and setting it up directly for
instance:

PHP_MEMORY_LIMIT=1G php script.php

Being equivalent of:

php -dmemory_limit=1G script.php

This seems like a reasonable alternative. With this would the php.ini be
the fallback value I’m looking for with the environment variable only being
used if present?

On July 27, 2020 at 12:01:13 AM, Michał Marcin Brzuchalski (
michal.brzuchal...@gmail.com) wrote:

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.

That sounds a little more complex that I was aiming for but does solve the
issue in a different way. I however wouldn’t be able to write that code
currently.

Thank you kindly for the responses. One comment I’ve seen that adding this
proposal would make the php.ini file no longer static. Can you please
clarify how

memory_limit = ${PHP_MEMORY_LIMIT}
is any less static than
memory_limit = ${PHP_MEMORY_LIMIT:-“256M”}

To me the ini setting is both static and deterministic. They may have
different outcomes under the proposed change but that doesn’t make it
dynamic.

Cheers,
Derek

Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters

[tyson andre]

Hi internals,

Continuing on my response in https://externals.io/message/61#92 , and 
considering ways to enhance named arguments without a BC break
(while minimizing the impact on application/library authors that wish for their 
libraries not to be used with named parameters)

I was considering setting up a short straw poll on the wiki for a week with two 
questions, open for a week:

1. Whether voters consider it appropriate to add amendments/enhancements to 
named parameters (in general) in php 8.0 past the feature freeze. 
(Both/Backward Compatible Enhancements Only/No)
   (yes if interested in any of the alternatives proposed in 
https://externals.io/message/61)

   I'd recognize that named parameters are potentially a large change to what 
is considered the public API of a project,
   so I'd think continuing to add enhancements would be worthwhile, but I'd 
like to know where others stand on this.
   (e.g. if any proposals I made should be postponed to 8.1)

   I'd also think that implementing a backwards incompatible change after the 
feature freeze (in terms of impact on code targeting 8.0 alphas at the time of 
the feature freeze)
would be a bad precedent.

2. Interest in adding support for positional-only arguments in 8.0 or 8.1 (3 
options: 8.0, 8.1, or no)

   (e.g. with a symbol such as `/` to indicate that parameters or variadic 
parameters prior to the symbol are positional-only)

   I'd consider positional-only arguments useful in some cases, such as where 
the names would always be confusing,
   (or automatically generated code)

   - `function my_merge(string $firstArg, ...string $otherArgs, /) { }`
 This also provides an easy way for user-defined code to add restrictions 
similar to what `array_merge()` already has.
   - `function my_pow($x, $y, $z = null, /,) {}`
   - `function autoGeneratedCode($arg1, $arg2, /) {}

   Other syntaxes are possible, such as using attributes
   (I would find 5 attributes rather verbose if there were 5 positional-only 
parameters),
   or keywords such as `__END_POSITIONAL_PARAMETERS`.
   Nothing stood out as a good option (e.g. `_`, `...`, `%` seem meaningless, 
`*` would be the opposite of python, `#` can't be used),
   and I've only seen markers for the end of positional-only parameters in 
python after a quick check, so at least some users would find `/` easier to 
learn/remember.



On an unrelated note,

1. A few people had suggested adding a line to a README indicating that named 
parameters aren't supported.
An idea I had was to standardize on a machine-readable file format (e.g. 
".php_analysis_config.json") that IDEs/analyzers may choose to support.
It might have JSON entries such as `"supports_named_parameters": false` to 
indicate that code (e.g. src/main.php) using files in that directory (e.g. 
vendor/a/b/ with vendor/a/b/.php_analysis_config.json)
should not invoke functions/methods in vendor/a/b/ with named parameters,
because there is no guarantee the names will remain the same.
(TOML or ini settings might be more readable, but a complicated format requires 
extra dependencies and ini files won't support arrays if future settings get 
added)

- I can't think of many other settings I'd want there that aren't covered by 
composer.json, editorconfig, or other means.
  Maybe less importantly `"supports_classes_being_extended": bool`
- Alternately, it might be possible to put it in "extra" of composer.json,
  but some projects/libraries don't use composer.json (e.g. a project has both 
vendor/ and third-party/)
- I'm not aware of similar indicators for python for named arguments, so there 
might not be much interest in such a proposal. Then again, I think python had 
named arguments for much longer.

2. Another attribute idea I had was `<>` on a 
class/method,
to make PHP enforce that method overrides other than __construct must
have the same names in the same positions and not lead to errors when valid 
named arguments are passed to subclasses,
but I don't plan to propose that any earlier than 8.1
(e.g. for classes that have calls such as `$this->method(someFlag: true);`)

Thanks,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Michael Morris]

On Mon, Jul 27, 2020 at 12:18 AM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

> Hi Michael,
>
> niedz., 26 lip 2020, 06:22 użytkownik Michael Morris 
> napisał:
>
>> PHP's ini values are already a bit of a mess.  You have a global php.ini
>> file, and then most PHP ini directives can be set per directory using the
>> .htaccess file.  About a third can be set at runtime. This makes tracking
>> down where a setting came from a bit of a headache unless care is taken.
>> This proposal promises to make the situation even more complicated.
>>
>> Also, what would this solve that using .htaccess files to override the
>> default values not solve aside from the rare settings that cannot be set
>> per directory?
>>
>
> Bear in mind that .htaccess has a very narrow use and it's kind oh thing
> Apache2 related and not PHP specific!
>

Most major webserver applications have an equivalent to .htaccess. Indeed,
IIS can bind PHP flags and values to environment values already if I recall
correctly, and has been able to do so for a very long time (though I
haven't played with IIS in over a decade so my memory could be wrong on
this).

You mention Docker - usually I've seen it used alongside Ansible, Chef or
Puppet. Each of these provisioning programs can modify the php.ini file
used on the container at deploy time without necessitating a change to PHP
itself.  What advantage does the community gain from moving these decisions
from the provision files to the php.ini file?


>

Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0

[Sara Golemon]

On Mon, Jul 27, 2020 at 5:25 PM Rowan Tommins 
wrote:

> A couple of months ago I revived my suggestion to make stream wrappers
> advertise HTTP/1.1 by default (full message below), and then Real Life
> intervened and I didn't raise the PR.
>
> The implementation (which is a one-character change) is now here:
> https://github.com/php/php-src/pull/5899
>
> I realise it's now rather last-minute for 8.0, so if anyone thinks it
> should have more careful thought, or an RFC, it will have to wait. If
> there are no objections, though, it would be nice to have it merged
> before the freeze.
>
> Given that it's a very small change, the RFC is probably not necessary, in
which case it's not too late, however I'd like some clarification about
what this actually offers over defaulting to 1.0. Specifically, are there
known servers which will refuse to serve 1.0 clients?  Script authors have
had the option of opting into 1.1 for some significant time now.

Basically, what's the chance of something accidentally not working due to
advertising 1.0 versus something not working due to advertising 1.1?  If
the changes are equal, I'd *personally* err in favor of status quo since
those needing 1.1 have already opted into it, those needing 1.0 may not
have.

-Sara

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

[Andreas Hennings]

Good point about the static typing!

On Mon, 27 Jul 2020 at 20:40, Rowan Tommins  wrote:

> Hi Andreas,
>
>
> On 27/07/2020 00:41, Andreas Hennings wrote:
> > 1. Calls with named arguments can only happen on:
> >- explicitly named functions (e.g. no call_user_func()).
> >- constructor calls with an explicitly named class.
> >- object methods, if the object variable is type-hinted or a type is
> > known at compile time.
> > 2. Named arguments in calls are converted to number-indexed arguments at
> > compile time.
> > 3. Parameter name lookup is done based on the type-hinted class or
> > interface. Parameter names on the actual object are ignored.
>
>
> While this is an interesting concept in general, it introduces a much
> larger change to the semantics of the language than seems justified for
> this particular problem - it would effectively require introducing an
> element of "static typing" into the language.
>
> By "static typing", I mean this:
>
>  > variables have an intrinsic type, and the same value can behave
> differently depending on the type of variable that holds it
>
> Which could be contrasted with "dynamic typing" like this:
>
>  > values have an intrinsic type, and operations will be selected based
> on those values, regardless of which variables hold them
>
> Although we have various type annotations in the language now, they are
> all just restrictions on the types of value a variable can hold; they
> don't change the behaviour of that value. With this proposal, these two
> function would potentially do different things when given the exact same
> argument:
>
> function a(FooInterface $arg) { $arg->doSomething(namedparam: 42); }
> function b(BarInterface $arg) { $arg->doSomething(namedparam: 42); }
>

It would be an edge case, if both of them are valid but with
swapped parameter names.
In the more common cases, one of them would simply be broken.
But your point is still correct.

I would argue that this is still better than the behavior with the current
RFC:
The developer who implements the function a or b only knows the parameter
names as in FooInterface or BarInterface.
They know nothing about the actual class of the object passed in as $arg.
A name lookup based on the known interface is closer to what the developer
wants, and is guaranteed to work for all implementations of the interface.

The main inheritance contract for methods is still based on parameter order:
E.g.

interface I {
  function foo(A $x, B $y);
}

interface J extends I {
  function foo(A $y, B $x);
}

The parameter names can be swapped, but the types have to remain in order.


>
>
> Static typing of that sort is a useful feature of other languages, and
> there are people who'd love to see PHP go that way,


Count me in :)


> but it's not
> something we should bolt on in a hurry just to solve an issue with named
> parameters.
>

You have a point.
It would not be a full-blown static typing, but at least it has the smell
of it.
The parameter name lookup would be based on the variable itself, instead of
the value.

As mentioned, there could be other ways to determine the version of the
method that should be used for parameter name lookup.
The options I can come up with atm would make the code more verbose, and/or
look awkward, and probably already clash with existing language features.
But perhaps there are better ways.

Either in the call itself:

$x->{FooInterface::doSomething}(namedparam: 42);
FooInterface::doSomething::invoke($x, namedparam: 42);

Or through a declaration in the file:

use \Acme\FooInterface::*();

$x->doSomething()



> just to solve an issue with named
> parameters.


I still think the current RFC is deeply flawed and should not have been
accepted in its current form.
It adds uncertainty and fragility to the language.
The Liskov substitution principle was something we could rely on,
guaranteed natively by the language. But with named parameters it is not.
I saw the explanations in the RFC about inheritance, but I don't find them
convincing.

But I am not a voting member and also I did not pay attention when this
discussion was happening.
And I am just one person, I don't want to make more than one person's worth
of drama.

Perhaps we will see people mostly use this for constructor or static calls,
and avoid it for polymorphic method calls.
For these cases it seems like a useful feature.


>
>
> Regards,
>
> --
> Rowan Tommins (né Collins)
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

[PHP-DEV] Re: [PHP-CVS] com php-src: Consolidate Parameter Names For ext/simplexml: ext/simplexml/simplexml.stub.php ext/simplexml/simplexml_arginfo.h

[Derick Rethans]

On 27 July 2020 20:42:33 BST, Benjamin Eberlei  wrote:
>Commit:eaeceb32932026c08a9d9e5be56da8e8111c5caa
>Author:Benjamin Eberlei  Mon, 27 Jul
>2020 19:32:00 +0200
>Parents:   8a6bc6767dbda4861b83fb9dcbba4453e541bbb9
>Branches:  master
>
>Link:  
>http://git.php.net/?p=php-src.git;a=commitdiff;h=eaeceb32932026c08a9d9e5be56da8e8111c5caa
>
>Log:
>Consolidate Parameter Names For ext/simplexml
>
>Co-authored-by: Thomas Weinert 
>
>Changed paths:
>  M  ext/simplexml/simplexml.stub.php
>  M  ext/simplexml/simplexml_arginfo.h
>
>
>Diff:
>diff --git a/ext/simplexml/simplexml.stub.php
>b/ext/simplexml/simplexml.stub.php
>index 2922adce4b..d3e48b0e6a 100644
>--- a/ext/simplexml/simplexml.stub.php
>+++ b/ext/simplexml/simplexml.stub.php
>@@ -2,19 +2,19 @@
> 
> /** @generate-function-entries */
> 
>-function simplexml_load_file(string $filename, ?string $class_name =
>SimpleXMLElement::class, int $options = 0, string $ns = '', bool
>$is_prefix = false): SimpleXMLElement|false {}
>+function simplexml_load_file(string $filename, ?string $class_name =
>SimpleXMLElement::class, int $options = 0, string $namespace_or_prefix
>= '', bool $is_prefix = false): SimpleXMLElement|false {}


I thought we were using studlyCaps, so that should be isPrefix and 
namespaceOrPrefix? 

cheers,
Derick

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0

[Rowan Tommins]

Hi all,

A couple of months ago I revived my suggestion to make stream wrappers 
advertise HTTP/1.1 by default (full message below), and then Real Life 
intervened and I didn't raise the PR.


The implementation (which is a one-character change) is now here: 
https://github.com/php/php-src/pull/5899


I realise it's now rather last-minute for 8.0, so if anyone thinks it 
should have more careful thought, or an RFC, it will have to wait. If 
there are no objections, though, it would be nice to have it merged 
before the freeze.


Thanks,
Rowan



On 21/05/2020 22:53, Rowan Tommins wrote:

Hi all,

A few years ago, I posted a message suggesting that PHP improve 
support for HTTP/1.1 in its stream wrapper functions: 
https://externals.io/message/96192


A quick summary of the current situation:

* HTTP/1.1 was officially standardised in January 1997, and most web 
browsers had already implemented it by then
* PHP has a very simple HTTP client implementation, used by the 
"http:" and "https:" stream wrappers, and also by extensions which 
make HTTP requests, such as ext/soap
* The client implementation defaults to advertising HTTP/1.0 requests, 
unless over-ridden by a stream context option
* Since a lot of servers only actually talk HTTP/1.1, the client 
mostly acts as an HTTP/1.1 client even when advertising HTTP/1.0



In my previous message, I identified four requirements in HTTP/1.1 but 
not HTTP/1.0 that are relevant to a client:


a) Send a "Host" header with every request. (RFC 7230 Section 5.4)
b) Support persistent connections, or send "Connection: Close" with 
each request. (RFC 7230 Section 6.1)
c) Ignore 1xx status lines (notably, "100 Continue") "even if the 
client does not expect one" (RFC 7231 Section 6.2)

d) Support "chunked" transfer encoding (RFC 7230 Section 4.1)


The PHP client now supports all four regardless of protocol version 
configured, i.e. it always sends "Host:" and "Connection: Close" 
headers; and always handles "100 Continue" and "Transfer-Encoding: 
Chunked" if returned by the server.


I would like to propose that the client advertises HTTP/1.1 in its 
requests by default in PHP 8.0.  Users can opt out of this behaviour 
in a fully backwards- and forwards-compatible way if necessary using a 
stream context option, e.g.: 
https://gist.github.com/IMSoP/a685fed6589435530102d57138755511



What are people's opinions? Does this need an RFC, or should I just 
submit a PR if nobody objects?



Regards,



--
Rowan Tommins (né Collins)
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

[Rowan Tommins]

Hi Andreas,


On 27/07/2020 00:41, Andreas Hennings wrote:

1. Calls with named arguments can only happen on:
   - explicitly named functions (e.g. no call_user_func()).
   - constructor calls with an explicitly named class.
   - object methods, if the object variable is type-hinted or a type is
known at compile time.
2. Named arguments in calls are converted to number-indexed arguments at
compile time.
3. Parameter name lookup is done based on the type-hinted class or
interface. Parameter names on the actual object are ignored.



While this is an interesting concept in general, it introduces a much 
larger change to the semantics of the language than seems justified for 
this particular problem - it would effectively require introducing an 
element of "static typing" into the language.


By "static typing", I mean this:

> variables have an intrinsic type, and the same value can behave 
differently depending on the type of variable that holds it


Which could be contrasted with "dynamic typing" like this:

> values have an intrinsic type, and operations will be selected based 
on those values, regardless of which variables hold them


Although we have various type annotations in the language now, they are 
all just restrictions on the types of value a variable can hold; they 
don't change the behaviour of that value. With this proposal, these two 
function would potentially do different things when given the exact same 
argument:


function a(FooInterface $arg) { $arg->doSomething(namedparam: 42); }
function b(BarInterface $arg) { $arg->doSomething(namedparam: 42); }


Static typing of that sort is a useful feature of other languages, and 
there are people who'd love to see PHP go that way, but it's not 
something we should bolt on in a hurry just to solve an issue with named 
parameters.



Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

[Andreas Hennings]

On Mon, 27 Jul 2020 at 03:18, tyson andre  wrote:

> Hi Andreas Hennings,
>
> > 1. Calls with named arguments can only happen on:
> >   - explicitly named functions (e.g. no call_user_func()).
> >   - constructor calls with an explicitly named class.
> >   - object methods, if the object variable is type-hinted or a type is
> known at compile time.
>
> This proposal would seem to depend on moving opcache into core, among
> other things.
> Depending on how it's implemented, the condition of "a type is known at
> compile time" may also depend on whatever opcache optimization passes were
> enabled,
> which would make the behavior of whether this throws an Error at runtime
> unintuitive to users.
>

Obviously there would need to be a consistent definition about how the type
of a variable should be determined.
And there would need to be a way to determine this at runtime, in case that
opcache is not enabled.
This could be the same system that is responsible for runtime type checks.

Perhaps we should drop the "is known at compile time" and only support
explicit type hints.
Anything we do here should be dumb static analysis, not smart static
analysis.

E.g.

function foo(I $obj) {
  $obj->setColor(color: 'blue');  // Good, based on I::setColor().
  $obj2 = $obj;
  $obj2->setColor(color: 'blue');  // Error, because simple static analysis
cannot determine the type of $obj2.
}


> (e.g. `$a = SOME_OPTIMIZABLE_CONDITION ? new A() : new B();
> $a->someMethod(namedArg: value);`)
>

Any "optimizable condition" would have to be treated like a regular
variable with unknown value.
So in the above case, named arguments would not be allowed.


>
> - `SOME_OPTIMIZABLE_CONDITION` may depend on the php version or
> environment (e.g. `PHP_OS_FAMILY == 'Windows'`)
>
> A recent secondary poll on a rejected RFC I proposed did indicate broad
> interest in moving opcache to php's core,
> but I doubt that'd be done in 8.0 due to the feature freeze, and I also
> doubt optimizations would always be enabled because of the overhead of
> optimization for small short-lived scripts
> ( https://wiki.php.net/rfc/opcache.no_cache#if_you_voted_no_why )
>
> Also, the times when a type is known (with 100% certainty) at compile time
> are known by opcache but unintuitive to users,
> due to the highly dynamic nature of PHP
> (`$$var = 'value'`, references, calls to require()/extract() modifying the
> scope, globals being effectively modifiable at any time, etc.)
> Even for typed properties, the existence of magic methods such as
> `__get()` (e.g. in subclasses) means that the type of $this->prop at
> runtime is uncertain.


> - `__get()` is called if it exists when a declared fetched property (typed
> or otherwise) was unset.
>

Good point.
One thing to note, it seems __get() is only called when the property is
accessed from _outside_.
https://3v4l.org/sY96q (just a snapshot, play around with this as you feel)
I personally don't really care that much about public properties, I could
happily live in a world where named parameters are not available for
objects in public properties.
Or alternatively, we could say that it is the responsibility of the __get()
method to return an object that is compatible with the type hint on the
public property, IF named parameters are used.


Even if all of this does not work, I think the idea still has merit:
Evaluate the parameter names based on a known interface, instead of an
unknown implementation which may come from a 3rd party.
Perhaps a type hint is not the best way to determine this interface..

Greetings
Andreas



>
> Regards,
> - Tyson

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

[Michał Marcin Brzuchalski]

Hi Derek,

pt., 24 lip 2020 o 22:54 Derek Bonner  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