Hello everybody,
Today we talked about a way to detect --with-curlwrappers at runtime.
It is nowadays not possible easilly.
Then , I remembered I once proposed to add a new function that could return
every ./configure options used to compile the runtime PHP the code is
beeing run on.
We already have "php-config --configure-options", but that needs to exist
and that needs an exec() call.
We also already have phpinfo() which returns that, but not in a very fancy
way (we need to preg_ the output which is ugly and not very simple).
Today, Seldaek proposed what I think is a cool way to solve this problem :
add a new parameter to phpinfo() function, which could return in an array
what it usually directly print throught the SAPI print() function (HTMLing
the output when needed).
The use case would be :
<?php
$output = phpinfo(INFO_GENERAL, true);
var_dump($output);
/* something like
['Debug Build' =>'no', 'Thread Safety'=>'yes', 'Configure
Command'=>['--enable-foo', '--with-config-file-scan-dir'=>'/etc'
]]
As you can see, it is rather simple but would need some work as it is
better for the "Configure Command" to return an array with the options
instead of a big string ; easier to parse.
Thoughts ?
Julien.Pauli
I'm having a hard time seeing production use cases for this.
While it is a very good suggestion, and probably not too hard to implement,
what benefit does it help you in an actual application outside the
development stage?
I'm in favor though, would probably have some uses during the development
stage.
Hello everybody,
Today we talked about a way to detect --with-curlwrappers at runtime.
It is nowadays not possible easilly.Then , I remembered I once proposed to add a new function that could return
every ./configure options used to compile the runtime PHP the code is
beeing run on.We already have "php-config --configure-options", but that needs to exist
and that needs anexec()call.
We also already havephpinfo()which returns that, but not in a very fancy
way (we need to preg_ the output which is ugly and not very simple).Today, Seldaek proposed what I think is a cool way to solve this problem :
add a new parameter tophpinfo()function, which could return in an array
what it usually directly print throught the SAPI print() function (HTMLing
the output when needed).The use case would be :
<?php
$output = phpinfo(INFO_GENERAL, true);var_dump($output);
/* something like
['Debug Build' =>'no', 'Thread Safety'=>'yes', 'Configure
Command'=>['--enable-foo', '--with-config-file-scan-dir'=>'/etc'
]]As you can see, it is rather simple but would need some work as it is
better for the "Configure Command" to return an array with the options
instead of a big string ; easier to parse.Thoughts ?
Julien.Pauli
Then , I remembered I once proposed to add a new function that could
return
every ./configure options used to compile the runtime PHP the code is
beeing run on.
What's the purpose of this? What problems should be solved by that? - We
should have proper "reflection" on all things affecting the behavior,
but mind: Many things which can be done in configure could also be done
by loading shared extensions compiled independently, and things done in
the configure line might only affect extensions which were built shared
but not loaded ...
johannes
I think creating easy processable output from phpinfo() is a good idea in
theory, but as Madara says, I'm also not sure about any other production
uses for this aside from the issue at hand with curlwrappers.
Are there many use cases except for the config options that this would be
useful for?
If not maybe a simpler php_configure_options() would be better, returning
an array as you proposed in your example.
Although I'm not sure about the returned format, in some cases the option
is a key, and in others it's a value.
I think options that do not take a value would be better represented as:
'--enable-foo' => true
Hello everybody,
Today we talked about a way to detect --with-curlwrappers at runtime.
It is nowadays not possible easilly.Then , I remembered I once proposed to add a new function that could return
every ./configure options used to compile the runtime PHP the code is
beeing run on.We already have "php-config --configure-options", but that needs to exist
and that needs anexec()call.
We also already havephpinfo()which returns that, but not in a very fancy
way (we need to preg_ the output which is ugly and not very simple).Today, Seldaek proposed what I think is a cool way to solve this problem :
add a new parameter tophpinfo()function, which could return in an array
what it usually directly print throught the SAPI print() function (HTMLing
the output when needed).The use case would be :
<?php
$output = phpinfo(INFO_GENERAL, true);var_dump($output);
/* something like
['Debug Build' =>'no', 'Thread Safety'=>'yes', 'Configure
Command'=>['--enable-foo', '--with-config-file-scan-dir'=>'/etc'
]]As you can see, it is rather simple but would need some work as it is
better for the "Configure Command" to return an array with the options
instead of a big string ; easier to parse.Thoughts ?
Julien.Pauli
Hi
2013/4/4 Julien Pauli jpauli@php.net:
As you can see, it is rather simple but would need some work as it is
better for the "Configure Command" to return an array with the options
instead of a big string ; easier to parse.Thoughts ?
As Johannes already said, we got Reflection, and we should stick to
that, having the configure command is nice yeah, but its a mere of
edge cases that needs to parse this to correctly function because they
are doing something thats unusual in a general purpose environment you
have no control over.
Moreover, this will not work for shared extensions, imagine PECL
extensions for Windows for example.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hello everybody,
Today we talked about a way to detect --with-curlwrappers at runtime.
It is nowadays not possible easilly.Then , I remembered I once proposed to add a new function that could return
every ./configure options used to compile the runtime PHP the code is
beeing run on.We already have "php-config --configure-options", but that needs to exist
and that needs anexec()call.
We also already havephpinfo()which returns that, but not in a very fancy
way (we need to preg_ the output which is ugly and not very simple).Today, Seldaek proposed what I think is a cool way to solve this problem :
add a new parameter tophpinfo()function, which could return in an array
what it usually directly print throught the SAPI print() function (HTMLing
the output when needed).The use case would be :
<?php
$output = phpinfo(INFO_GENERAL, true);var_dump($output);
/* something like
['Debug Build' =>'no', 'Thread Safety'=>'yes', 'Configure
Command'=>['--enable-foo', '--with-config-file-scan-dir'=>'/etc'
]]As you can see, it is rather simple but would need some work as it is
better for the "Configure Command" to return an array with the options
instead of a big string ; easier to parse.Thoughts ?
Julien.Pauli
Seems like a good idea to me ...
So ... https://gist.github.com/krakjoe/5311608
Array
(
[with-apxs2] => /opt/php-nts/bin/apxs
[prefix] => /opt/php-nts
[exec-prefix] => /opt/php-nts
[with-config-file-path] => /opt/php-nts/
[with-config-file-scan-dir] => /opt/php-nts/modules.d/
[with-curl] => /usr
[with-zlib] => 1
[with-libxml-dir] => /usr
[enable-simplexml] => 1
[with-mysql] => mysqlnd
[with-pdo-mysql] => mysqlnd
[enable-gd-native-ttf] => 1
[with-mysqli] => 1
[enable-sockets] => 1
[with-gd] => 1
[enable-debug] => 1
)
Something that hasn't been mentioned, installation of software like
wordpress or whatever, might be able to offer advice to the end user
based on the configuration defaults, regardless of ini settings.
Joe
Joe Watkins krakjoe@php.net wrote:
Something that hasn't been mentioned, installation of software like
wordpress or whatever, might be able to offer advice to the end user
based on the configuration defaults, regardless of ini settings.
Le me repeat what I said in this thread using other words:
No, it can't. In a typical case (PHP from distribution with "all" extensions shared) this has no relevance regarding the running system. The extensions loaded might be built completely different from what's said there.
Provide the information needed by constants or function calls from an extenson or whatever makes sense, don't advocate to do the wrong thing.
johannes
Joe Watkins krakjoe@php.net wrote:
Something that hasn't been mentioned, installation of software like
wordpress or whatever, might be able to offer advice to the end user
based on the configuration defaults, regardless of ini settings.Le me repeat what I said in this thread using other words:
No, it can't. In a typical case (PHP from distribution with "all" extensions shared) this has no relevance regarding the running system. The extensions loaded might be built completely different from what's said there.
Provide the information needed by constants or function calls from an extenson or whatever makes sense, don't advocate to do the wrong thing.
johannes
Many extensions do not provide constants or functions to detect the way
they are configured, this may or may not expose those options, which is
better than not being able to expose those options by any reasonable means.
More importantly, it does not only contain information about extensions,
or which extensions are loaded and how ( I am aware of the problems of
using this kind of information as authoritative, I still say something
is better than nothing, see every 404 page in all modern browsers, why
not provide suggestions, even if they are wrong ).
Path information I figure could be useful while setting up software, so
could many other configure time options, for example if more than one
SAPI was built at configure time, you might advise the use of the most
suitable SAPI for your software, you might generate an ini file and tell
the user where to put it (scandir), you might have the abnormal path to
php-config or other things distributed with php and installed in a
non-standard path (/opt/php-nts in example output).
There's a bunch of useful stuff in the configure command ... not just
extensions loaded ...
Joe Watkins krakjoe@php.net wrote:
Many extensions do not provide constants or functions to detect the way
they are configured, this may or may not expose those options, which is
better than not being able to expose those options by any reasonable
means.
Then those extensions should expose the required information. These are bugs then.
More importantly, it does not only contain information about
extensions,
or which extensions are loaded and how ( I am aware of the problems of
using this kind of information as authoritative, I still say something
is better than nothing, see every 404 page in all modern browsers, why
not provide suggestions, even if they are wrong ).Path information I figure could be useful while setting up software, so
The paths set during configure time don't have to match those where things are installed. Especially admins might prefer to use symlinked paths for configuration and users might be misled.
could many other configure time options, for example if more than one
SAPI was built at configure time, you might advise the use of the most
suitable SAPI for your software,
SAPIs might be built individually. Having them enabled during configure time doesn't mean they are enabled or accessible by the user.
you might generate an ini file and
tell
the user where to put it (scandir), you might have the abnormal path to
php-config or other things distributed with php and installed in a
non-standard path (/opt/php-nts in example output).
configure options often won't tell-
There's a bunch of useful stuff in the configure command ... not just
extensions loaded ...
Yes and a lot of wrong information.
johannes
Joe Watkins krakjoe@php.net wrote:
Many extensions do not provide constants or functions to detect the way
they are configured, this may or may not expose those options, which is
better than not being able to expose those options by any reasonable
means.Then those extensions should expose the required information. These are bugs then.
More importantly, it does not only contain information about
extensions,
or which extensions are loaded and how ( I am aware of the problems of
using this kind of information as authoritative, I still say something
is better than nothing, see every 404 page in all modern browsers, why
not provide suggestions, even if they are wrong ).Path information I figure could be useful while setting up software, so
The paths set during configure time don't have to match those where things are installed. Especially admins might prefer to use symlinked paths for configuration and users might be misled.
could many other configure time options, for example if more than one
SAPI was built at configure time, you might advise the use of the most
suitable SAPI for your software,SAPIs might be built individually. Having them enabled during configure time doesn't mean they are enabled or accessible by the user.
you might generate an ini file and
tell
the user where to put it (scandir), you might have the abnormal path to
php-config or other things distributed with php and installed in a
non-standard path (/opt/php-nts in example output).configure options often won't tell-
There's a bunch of useful stuff in the configure command ... not just
extensions loaded ...Yes and a lot of wrong information.
johannes
A combination of ENV, ini, phpversion and phpconfopt options should
allow you to make much more informed decisions or do nothing at all,
there is not a reasonable means to acquire this information, nor is it
reasonable to suggest that we modify every single bundled extension in
order to expose their configuration options, additional constants and
maybe add new functions/methods.
I keep using the words could, might, maybe, on purpose, I am aware
that the configuration time options may not match runtime parameters, I
don't think it falls to us to provide the business logic, so it doesn't
really matter that the setup may be completely different, it may be the
same, or similar. It may be vital information, it may also be completely
irrelevant, exposing it provides more flexibility than doing nothing at all.
Joe
Joe Watkins krakjoe@php.net wrote:
Many extensions do not provide constants or functions to detect the way
they are configured, this may or may not expose those options, which is
better than not being able to expose those options by any reasonable
means.Then those extensions should expose the required information. These are
bugs then.More importantly, it does not only contain information about
extensions,
or which extensions are loaded and how ( I am aware of the problems of
using this kind of information as authoritative, I still say something
is better than nothing, see every 404 page in all modern browsers, why
not provide suggestions, even if they are wrong ).Path information I figure could be useful while setting up software, so
The paths set during configure time don't have to match those where
things are installed. Especially admins might prefer to use symlinked paths
for configuration and users might be misled.could many other configure time options, for example if more than one
SAPI was built at configure time, you might advise the use of the most
suitable SAPI for your software,SAPIs might be built individually. Having them enabled during configure
time doesn't mean they are enabled or accessible by the user.you might generate an ini file and
tell
the user where to put it (scandir), you might have the abnormal path to
php-config or other things distributed with php and installed in a
non-standard path (/opt/php-nts in example output).configure options often won't tell-
There's a bunch of useful stuff in the configure command ... not just
extensions loaded ...
Yes and a lot of wrong information.
johannes
A combination of ENV, ini, phpversion and phpconfopt options should allow
you to make much more informed decisions or do nothing at all, there is not
a reasonable means to acquire this information, nor is it reasonable to
suggest that we modify every single bundled extension in order to expose
their configuration options, additional constants and maybe add new
functions/methods.I keep using the words could, might, maybe, on purpose, I am aware that
the configuration time options may not match runtime parameters, I don't
think it falls to us to provide the business logic, so it doesn't really
matter that the setup may be completely different, it may be the same, or
similar. It may be vital information, it may also be completely irrelevant,
exposing it provides more flexibility than doing nothing at all.Joe
--
I don't see any useful production applications for this. However, I could
say the same thing about phpinfo() itself. From a debugging and QA
standpoint, on the other hand, this could be potentially useful. If, for
example, I was writing some sort of server analysis or troubleshooting
utility, it might be helpful for me to be able to grab the configure
command (or anything else in phpinfo(), for that matter) without having to
do a screen scape.
So even though the use case for this is somewhat narrow, I think it's
something we should have in place, anyway. You should definitely write an
RFC for this.
--Kris