Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » phar and e_strict »

phar and e_strict

php.internals

Derick Rethans

20 years ago
Hello! I am wondering why "make install-pear" comes up with hundreds of e_strict warnings? The code tests for PHP 5.1 but makes use of all old things that are now considered e_strict or deprecated. Besides this for some reason setting error_reporting to 0 doesn't help at all. First of all the code does: error_reporting(E_ALL);^M if (version_compare(phpversion(), '5.1.0b1', '<')) {^M die('Error: .phar files require PHP 5.1 or newer');^M }^M But it seems E_STRICT is turned on later for some reason too. Can this code please be upgraded to 1. not modify any error reporting setting and 2. PHP 5.1 compatible code. Currently installing pear does not seem to work at all with the .phar. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Pierre-Alain Joye

20 years ago
On Sat, 1 Oct 2005 16:17:19 +0200 (CEST) derick@php.net (Derick Rethans) wrote:
> 1. not modify any error reporting setting
We have to modify it as the underlying code is not php5 _only_ but have to work for both php5 and php4.
> 2. PHP 5.1 compatible code.
It is compatible, or do you mean E_STRICK compatible? --Pierre

Marcus Börger

20 years ago
Hello Pierre, Saturday, October 1, 2005, 4:24:02 PM, you wrote:
> On Sat, 1 Oct 2005 16:17:19 +0200 (CEST) > derick@php.net (Derick Rethans) wrote:
>> 1. not modify any error reporting setting
> We have to modify it as the underlying code is not php5 _only_ but have > to work for both php5 and php4.
>> 2. PHP 5.1 compatible code.
> It is compatible, or do you mean E_STRICK compatible?
You should face reality that php 5 is a bit different than php 4. Many of the things changed in php 5 were made to support exactly pear development but pear is absolutley ignoring it. Why can't at least the things that shall be shipped in 5.1 fashion - especially since you're doing part of it in a way only 5.1 can serve anyway. Best regards, Marcus

Pierre-Alain Joye

20 years ago
On Sat, 1 Oct 2005 16:48:47 +0200 helly@php.net (Marcus Boerger) wrote:
> Hello Pierre, > > Saturday, October 1, 2005, 4:24:02 PM, you wrote: > > > On Sat, 1 Oct 2005 16:17:19 +0200 (CEST) > > derick@php.net (Derick Rethans) wrote: > > > >> 1. not modify any error reporting setting > > > We have to modify it as the underlying code is not php5 _only_ but > > have to work for both php5 and php4. > > >> 2. PHP 5.1 compatible code. > > > It is compatible, or do you mean E_STRICK compatible? > > You should face reality that php 5 is a bit different than php 4.
I do know that, I did explain my opinions about having PEAR bundled by default in 5.1+ and so on. But other php developers seem to fully disagree with me on this topic, as many PEAR developers, nothing more I can do.
> Many of the things changed in php 5 were made to support exactly pear > development but pear is absolutley ignoring it.
As PEAR 1.4 _has_ to be compatible with 1.x, we did not ignore the changes. But we cannnot drop php4 support or maintain 2 code bases.
> Why can't at least the things that shall be shipped in 5.1 fashion - > especially since you're doing part of it in a way only 5.1 can serve > anyway.
I do not get this sentence, can you elaborate? --Pierre

Marcus Börger

20 years ago
Hello Pierre, Saturday, October 1, 2005, 5:04:01 PM, you wrote:
> On Sat, 1 Oct 2005 16:48:47 +0200 > helly@php.net (Marcus Boerger) wrote:
>> Hello Pierre, >> >> Saturday, October 1, 2005, 4:24:02 PM, you wrote: >> >> > On Sat, 1 Oct 2005 16:17:19 +0200 (CEST) >> > derick@php.net (Derick Rethans) wrote: >> >> >> >> 1. not modify any error reporting setting >> >> > We have to modify it as the underlying code is not php5 _only_ but >> > have to work for both php5 and php4. >> >> >> 2. PHP 5.1 compatible code. >> >> > It is compatible, or do you mean E_STRICK compatible? >> >> You should face reality that php 5 is a bit different than php 4.
> I do know that, I did explain my opinions about having PEAR bundled by > default in 5.1+ and so on. But other php developers seem to fully > disagree with me on this topic, as many PEAR developers, nothing more I > can do.
>> Many of the things changed in php 5 were made to support exactly pear >> development but pear is absolutley ignoring it.
> As PEAR 1.4 _has_ to be compatible with 1.x, we did not ignore the > changes. But we cannnot drop php4 support
> or maintain 2 code bases.
Then you don't suit php development and should get stripped out - end of discussion - do what ever you want then!
>> Why can't at least the things that shall be shipped in 5.1 fashion - >> especially since you're doing part of it in a way only 5.1 can serve >> anyway.
> I do not get this sentence, can you elaborate?
You need to provide a 5+ version of core pear components so that we cn ship those with 5.1. Best regards, Marcus

Lukas Smith

20 years ago
Marcus Boerger wrote:
> You should face reality that php 5 is a bit different than php 4. > Many of the things changed in php 5 were made to support exactly pear > development but pear is absolutley ignoring it. Why can't at least the > things that shall be shipped in 5.1 fashion - especially since you're doing > part of it in a way only 5.1 can serve anyway.
We are not ignoring it. However the single most useful feature from PEAR POV was dropped from PHP5: namespaces. Without it we just could not justify dumping our PHP4 userbase and so we decided to try peaceful coexistance, however increasingly new packages are PHP5 only and those packages do not rely in the core PEAR classes, since the main purpose of these classes is error handling which we have decided to move to exceptions (something I personally thought was a bad idea). However the PEAR installer will have to work with PHP4 for sometime and we simply do not have the ressources to maintain two versions of the PEAR installer. Finally the PEAR installer is a more or less self contained application tool. As long as it works it does not need to follow any particular error handling defined for any apps written by users. So all we have to do is make sure that we can disable E_STRICT for the PEAR installer when run in an environment that usually runs in E_STRICT. regards, Lukas

Derick Rethans

20 years ago
On Tue, 4 Oct 2005, Lukas Smith wrote:
> Marcus Boerger wrote: > > > You should face reality that php 5 is a bit different than php 4. > > Many of the things changed in php 5 were made to support exactly pear > > development but pear is absolutley ignoring it. Why can't at least the > > things that shall be shipped in 5.1 fashion - especially since you're doing > > part of it in a way only 5.1 can serve anyway. > > We are not ignoring it. However the single most useful feature from PEAR POV > was dropped from PHP5: namespaces.
That's lame, this has nothing to do with E_STRICT warnings or other dubious code. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Lukas Smith

20 years ago
Derick Rethans wrote:
>>We are not ignoring it. However the single most useful feature from PEAR POV >>was dropped from PHP5: namespaces. > > > That's lame, this has nothing to do with E_STRICT warnings or other > dubious code.
How is it dubious to support PHP4 and PHP5 with the same code base? There have been definate improvements, no doubt about that. But nothing grand enough to say: "he lets start from scratch". regards, Lukas

Jani Taskinen

20 years ago
On Sat, 1 Oct 2005, Pierre wrote:
> We have to modify it as the underlying code is not php5 _only_ but have > to work for both php5 and php4.
You haven't heard about branches either? :) --Jani

Pierre-Alain Joye

20 years ago
On Sat, 1 Oct 2005 16:17:19 +0200 (CEST) derick@php.net (Derick Rethans) wrote:
> But it seems E_STRICT is turned on later for some reason too. Can > this code please be upgraded to 1. not modify any error reporting > setting and 2. PHP 5.1 compatible code. Currently installing pear > does not seem to work at all with the .phar.
Forget to mention than the E_STRICT and is_a warnings have nothing to do with the phar itself but the PEAR code itself. --Pierre

Greg Beaver

20 years ago
Derick Rethans wrote:
> Hello! > > I am wondering why "make install-pear" comes up with hundreds of > e_strict warnings? The code tests for PHP 5.1 but makes use of all old > things that are now considered e_strict or deprecated. Besides this for > some reason setting error_reporting to 0 doesn't help at all. First of > all the code does: > > error_reporting(E_ALL);^M > if (version_compare(phpversion(), '5.1.0b1', '<')) {^M > die('Error: .phar files require PHP 5.1 or newer');^M > }^M > > But it seems E_STRICT is turned on later for some reason too. Can this > code please be upgraded to 1. not modify any error reporting setting and > 2. PHP 5.1 compatible code. Currently installing pear does not seem > to work at all with the .phar.
This is a bit baffling: even a full text search of the entirety of cvs pear-core/ turns up only 1 reference to E_STRICT in the code (there are others in the in-code documentation) - and this is in a file that is not used by the .phar (pearcmd.php). A search for "error_reporting(" only turns up "error_reporting(E_ALL)." As Derick notes, this is also the first thing present in the .phar before any other code is included. It appears that E_STRICT is being triggered even though it is explicitly NOT asked for. All the same, I added another redundant error_reporting() call at the top of install-pear.php, re-built the .phar and committed to pearweb. Hopefully this will fix the issue. The code *is* PHP 5.1-compatible. Understand that the .phar uses PEAR to install things. PEAR uses things like is_a() and "var" and calling static methods because there are no alternatives unless we drop PHP 4.x support entirely from the pear command. Until all the standard unix distros (gentoo/redhat/debian/etc.) start distributing PHP 5.x as the standard PHP version, this isn't an option. I've been running the pear command using PHP 5.1rc1 ever since it came out, and it works just fine. This is a problem specific to the install-pear.phar that in fact did not happen just 2 weeks ago - perhaps something has changed in PHP 5.1 itself? Greg

Jani Taskinen

20 years ago
On Sat, 1 Oct 2005, Greg Beaver wrote:
> support entirely from the pear command. Until all the standard unix > distros (gentoo/redhat/debian/etc.) start distributing PHP 5.x as the > standard PHP version, this isn't an option.
And as long as you keep it backwards-compatible, they won't upgrade. (ever heard about the chicken that was before the egg? :) --Jani

Derick Rethans

20 years ago
On Sat, 1 Oct 2005, Greg Beaver wrote:
> It appears that E_STRICT is being triggered even though it is explicitly > NOT asked for. All the same, I added another redundant > error_reporting() call at the top of install-pear.php, re-built the > .phar and committed to pearweb. Hopefully this will fix the issue.
I tested with the new code, and for some reason it still doesn't work. Interesting is that if I remove the -n from the PEAR_INSTALL_OPTIONS in the makefile, it doesn't show the e_Strict errors anymore...
> The code *is* PHP 5.1-compatible. Understand that the .phar uses PEAR > to install things. PEAR uses things like is_a() and "var" and calling > static methods because there are no alternatives unless we drop PHP 4.x > support entirely from the pear command. Until all the standard unix > distros (gentoo/redhat/debian/etc.) start distributing PHP 5.x as the > standard PHP version, this isn't an option.
Branches? :) regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Greg Beaver

20 years ago
Derick Rethans wrote:
> On Sat, 1 Oct 2005, Greg Beaver wrote: > > >>It appears that E_STRICT is being triggered even though it is explicitly >>NOT asked for. All the same, I added another redundant >>error_reporting() call at the top of install-pear.php, re-built the >>.phar and committed to pearweb. Hopefully this will fix the issue. > > > I tested with the new code, and for some reason it still doesn't work. > Interesting is that if I remove the -n from the PEAR_INSTALL_OPTIONS in > the makefile, it doesn't show the e_Strict errors anymore...
Could it be that by disabling php.iniwith -n, error_reporting() no longer functions as documented? Greg

Helgi Þormar

20 years ago
On Sat, 01 Oct 2005 08:21:57 -0700, Greg Beaver wrote:
> Until all the standard unix > distros (gentoo/redhat/debian/etc.) start distributing PHP 5.x as the > standard PHP version, this isn't an option.
Just so you know, Fedora and FreeBSD have had 5.x as standard for some time now ;-) I can't speak for others but I think it's the same for RHEL 4 and probably Gentoo. So in a way I agree with Jani, specially since many distros are already moving to 5.x - Helgi

Christian Schneider

20 years ago
Helgi Þormar wrote:
> So in a way I agree with Jani, specially since many distros are already > moving to 5.x
Maybe you should look at the installed bases of PHP instead of the PHP version distributed with the latest distros. Anyone got current stats on that? And no, I don't believe in forcing people to upgrade for something as basic as PEAR. Creating a PHP5 branch and freezing PEAR for PHP4 once PHP5 crosses a certain threshold (75%? 90%?) might be an option though. Pragmatically yours, - Chris

Marcus Börger

20 years ago
Hello Christian, Saturday, October 1, 2005, 6:13:51 PM, you wrote:
> Helgi Þormar wrote: >> So in a way I agree with Jani, specially since many distros are already >> moving to 5.x
> Maybe you should look at the installed bases of PHP instead of the PHP > version distributed with the latest distros. Anyone got current stats on > that?
> And no, I don't believe in forcing people to upgrade for something as > basic as PEAR. Creating a PHP5 branch and freezing PEAR for PHP4 once > PHP5 crosses a certain threshold (75%? 90%?) might be an option though.
Noone ever said that pear for php 4 should be frozen in the near future. The only point is that we either need a branch or a tool that allows automatic conversion of pear code to php 5 code. Best regards, Marcus

Justin Patrin

20 years ago
On 10/1/05, Marcus Boerger <helly@php.net> wrote:
> Hello Christian, > > Saturday, October 1, 2005, 6:13:51 PM, you wrote: > > > Helgi Þormar wrote: > >> So in a way I agree with Jani, specially since many distros are already > >> moving to 5.x > > > Maybe you should look at the installed bases of PHP instead of the PHP > > version distributed with the latest distros. Anyone got current stats on > > that? > > > And no, I don't believe in forcing people to upgrade for something as > > basic as PEAR. Creating a PHP5 branch and freezing PEAR for PHP4 once > > PHP5 crosses a certain threshold (75%? 90%?) might be an option though. > > Noone ever said that pear for php 4 should be frozen in the near future. > The only point is that we either need a branch or a tool that allows > automatic conversion of pear code to php 5 code. >
You could do this with a post-install script quite easily. I don't think this is the point, however. Making code E_STRICT isn't really important. The thing that Greg wants to do is drop PHP4 support completely. This would make the code less complicated and make support easier.
-- Justin Patrin

Sergio Carvalho

20 years ago
Helgi Þormar wrote:
> On Sat, 01 Oct 2005 08:21:57 -0700, Greg Beaver wrote: > >> Until all the standard unix >>distros (gentoo/redhat/debian/etc.) start distributing PHP 5.x as the >>standard PHP version, this isn't an option. > > > Just so you know, Fedora and FreeBSD have had 5.x as standard for some > time now ;-) I can't speak for others but I think it's the same for RHEL 4 > and probably Gentoo. > So in a way I agree with Jani, specially since many distros are already > moving to 5.x > > - Helgi >
Gentoo is revamping PHP ebuilds and delayed PHP5 unmasking until that is done: http://svn.gnqs.org/projects/gentoo-php-overlay/wiki I can't find the reference, but I recall it being targeted for the current month. 5.1 will be the preferred version (not 5.0). Regards,
-- Sérgio

Curt Zirzow

20 years ago
On Sat, 01 Oct 2005 08:21:57 -0700, Greg Beaver wrote:
> > I've been running the pear command using PHP 5.1rc1 ever since it came > out, and it works just fine. This is a problem specific to the > install-pear.phar that in fact did not happen just 2 weeks ago - perhaps > something has changed in PHP 5.1 itself?
A little side track on the E_STRICT issue... I ran into two issues while installing php 5.1-branch. 1. zlib is required now with php, and by default php isn't installed with zlib nor does configure catch this, so, while make install is running and when pear is being installed make dies leaving a bad installation. I have have a patch for configure.in that is ready that will add a check for zlib in the configure process to avoid the make install bailing. 2. I'm not sure if the release of php5.1 is going to include the install-pear.phar file, but if I don't have that file within the pear/ directory, make install also requires that the system has wget installed, causing a fail in make install as well. I can write a patch for configure.in to check for wget (or fetch on *bsd machines), if the .phar file isn't going to be included with a release. heck, here is the patch for #1: http://zirzow.org/patches/pear.configure.in.patch I'm not really sure what to do with #2, i just thought i'd bring up these issues while talking about the install process. Curt.

Greg Beaver

20 years ago
Curt Zirzow wrote:
> On Sat, 01 Oct 2005 08:21:57 -0700, Greg Beaver wrote: > >>I've been running the pear command using PHP 5.1rc1 ever since it came >>out, and it works just fine. This is a problem specific to the >>install-pear.phar that in fact did not happen just 2 weeks ago - perhaps >>something has changed in PHP 5.1 itself? > > > A little side track on the E_STRICT issue... I ran into two issues while > installing php 5.1-branch. > > 1. zlib is required now with php, and by default php isn't installed > with zlib nor does configure catch this, so, while make install is > running and when pear is being installed make dies leaving a bad > installation.
I could eliminate this requirement, at the expense of a larger .phar file (3.3MB instead of 640k).
> I have have a patch for configure.in that is ready that will add a check > for zlib in the configure process to avoid the make install bailing. > > 2. I'm not sure if the release of php5.1 is going to include the > install-pear.phar file, but if I don't have that file within the pear/ > directory, make install also requires that the system has wget > installed, causing a fail in make install as well. > > I can write a patch for configure.in to check for wget (or fetch on *bsd > machines), if the .phar file isn't going to be included with a release.
Better (I discussed this with Andi, but haven't had time to do anything fruitful yet) is to write a short PHP script that would download it. Just now, it occurs to me that by changing the wget call in Makefile.frag from: wget http://pear.php.net/install-pear.phar -nd -P $(srcdir); to: @$(top_builddir)/sapi/cli/php -dallow_url_fopen=1 -r "$a = file_get_contents('http://pear.php.net/install-pear.phar');file_put_contents($_SERVER['argv'][1] . '/install-pear.phar',$a);" $(srcdir) this might be our cross-platform ticket. Could one of you kind folks try this, and commit if it works? Thanks, Greg

Curt Zirzow

20 years ago
On Mon, 03 Oct 2005 23:27:31 -0500, Greg Beaver wrote:
> Curt Zirzow wrote: >> On Sat, 01 Oct 2005 08:21:57 -0700, Greg Beaver wrote: >> >>>I've been running the pear command using PHP 5.1rc1 ever since it came >>>out, and it works just fine. This is a problem specific to the >>>install-pear.phar that in fact did not happen just 2 weeks ago - perhaps >>>something has changed in PHP 5.1 itself? >>> >> 1. zlib is required now with php, and by default php isn't installed >> with zlib nor does configure catch this, so, while make install is >> running and when pear is being installed make dies leaving a bad >> installation. > > I could eliminate this requirement, at the expense of a larger .phar file > (3.3MB instead of 640k).
Yeah, that could work. On the other hand I think most/many people will have zlib included. So in that case the installer could/should first check for a compressed file [.phaz?] (if it supports the compression) otherwise just use the uncompressed file.
>> 2. I'm not sure if the release of php5.1 is going to include the >> install-pear.phar file, but if I don't have that file within the pear/ >> directory, make install also requires that the system has wget >> installed, causing a fail in make install as well. >> >> I can write a patch for configure.in to check for wget (or fetch on >> *bsd machines), if the .phar file isn't going to be included with a >> release. > > Better (I discussed this with Andi, but haven't had time to do anything > fruitful yet) is to write a short PHP script that would download it. Just > now, it occurs to me that by changing the wget call in Makefile.frag from: > > wget http://pear.php.net/install-pear.phar -nd -P $(srcdir); > > to: > > @$(top_builddir)/sapi/cli/php -dallow_url_fopen=1 -r "$a = > file_get_contents('http://pear.php.net/install-pear.phar');file_put_contents($_SERVER['argv'][1] > . '/install-pear.phar',$a);" $(srcdir)
At first look this looks like a good solution, i don't know if it is due to a bad copy paste but my test fails right now. The only problem i see with this is that this occurs on 'make install'. I think ideally the download should at least occur in the configure or make process, especially since pear gets installed so late in the process. If the download fails for what ever reason, the person is going to have a partially installed php. Curt.

Derick Rethans

20 years ago
On Mon, 3 Oct 2005, Greg Beaver wrote:
> > 1. zlib is required now with php, and by default php isn't installed > > with zlib nor does configure catch this, so, while make install is > > running and when pear is being installed make dies leaving a bad > > installation. > > I could eliminate this requirement, at the expense of a larger .phar > file (3.3MB instead of 640k).
Please don't do that, as this is going to be part of a release tarball.
> @$(top_builddir)/sapi/cli/php -dallow_url_fopen=1 -r "$a = > file_get_contents('http://pear.php.net/install-pear.phar');file_put_contents($_SERVER['argv'][1] > . '/install-pear.phar',$a);" $(srcdir) > > this might be our cross-platform ticket. Could one of you kind folks > try this, and commit if it works?
I don't think we should do this for our releases, it's going to open way too much cans of worms. Currently the phar still throws still lots of e_strict errors. When that is fixed I'll add a script that puts the phar in the snapshots too. regards, Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Stefan Walk

20 years ago
On 10/4/05, Derick Rethans <derick@php.net> wrote:
> On Mon, 3 Oct 2005, Greg Beaver wrote: > > > > 1. zlib is required now with php, and by default php isn't installed > > > with zlib nor does configure catch this, so, while make install is > > > running and when pear is being installed make dies leaving a bad > > > installation. > > > > I could eliminate this requirement, at the expense of a larger .phar > > file (3.3MB instead of 640k). > > Please don't do that, as this is going to be part of a release tarball.
This tarball is gzipped/bzip2ed though, or am I mistaken? So it wouldn't matter for the size of the tarball if the .phar file is not compressed. Regards, Stefan

Derick Rethans

20 years ago
On Tue, 4 Oct 2005, Stefan Walk wrote:
> On 10/4/05, Derick Rethans <derick@php.net> wrote: > > On Mon, 3 Oct 2005, Greg Beaver wrote: > > > > > > 1. zlib is required now with php, and by default php isn't installed > > > > with zlib nor does configure catch this, so, while make install is > > > > running and when pear is being installed make dies leaving a bad > > > > installation. > > > > > > I could eliminate this requirement, at the expense of a larger .phar > > > file (3.3MB instead of 640k). > > > > Please don't do that, as this is going to be part of a release tarball. > > This tarball is gzipped/bzip2ed though, or am I mistaken? So it > wouldn't matter for the size of the tarball if the .phar file is not > compressed.
Well, that is true :) It would be nice if somebody could check out the difference in size though. Derick
-- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org

Matthew Charles Kavanagh

20 years ago
Derick Rethans wrote:
> On Mon, 3 Oct 2005, Greg Beaver wrote: > > >>> 1. zlib is required now with php, and by default php isn't installed >>> with zlib nor does configure catch this, so, while make install is >>> running and when pear is being installed make dies leaving a bad >>> installation. >> >>I could eliminate this requirement, at the expense of a larger .phar >>file (3.3MB instead of 640k). > > > Please don't do that, as this is going to be part of a release tarball.
Would that really be a problem, given that compressing a compressed file and compressing an uncompressed file will usually yield similar sized resultant files?

Matthew Charles Kavanagh

20 years ago
Matthew Kavanagh wrote:
> Would that really be a problem, given that compressing a compressed file > and compressing an uncompressed file will usually yield similar sized > resultant files? >
...and I failed to see the previous email that says the same thing. Genius at work. ;)

Johannes Schlueter

20 years ago
Hi, on a related note on the .phar stuff: I've just built PHP without zlib support and the PEAR install failed with | Installing PEAR environment: /opt/php-5.1-dev/lib/php/ | | Notice: Error: zlib extension is not enabled - gzinflate() function needed | for compressed .phars in /.../PHP_5_1/pear/install-pear.phar on line 393 | | Warning: main(phar://install-pear.phar/index.php): failed to open stream: | "PHP_Archive::stream_open" call failed | in /.../PHP_5_1/pear/install-pear.phar on line 633 | | Fatal error: main(): Failed opening required | 'phar://install-pear.phar/index.php' (include_path='.:') | in /home/johannes/src/php/cv/PHP_5_1/pear/install-pear.phar on line 633 | | make[1]: *** [install-pear-installer] Error 255 In my opinion there should be a nicer error message, maybe even at configure time. johannes On Saturday 01 October 2005 16:17, Derick Rethans wrote: