better management of php-src/pear and PEAR's future in php

16 years ago by Greg Beaver — view source — reply

unread

Hi,

I'd like to start a discussion on php-src/pear and how we can manage it
better for PHP 5.3, and to discuss the future of PEAR in PHP.

First, take note that both internals@ and pear-dev@ are copied on this
email.

For some background, currently the pear components are dynamically added
to a checkout by downloading from pear.php.net. These components are
install-pear-nozlib.phar and go-pear.phar (for windows). In addition,
the windows go-pear.phar is only downloaded by the build script for
windows. Although this works, it adds some obscurity to how the process
really works.

I'd like to consider instead using svn:externals to pull in PEAR stuff
directly from a STABLE branch from somewhere in the pear/ hierarchy.
This would allow us over at PEAR to push the installation phars into
that branch at the same time a release is made, and would also allow
quick fixes by a quick revert to a previous revision.

In terms of the future of PEAR in php-src, now that Pyrus is approaching
its first public releases, I'd like to brainstorm how best to replace
PEAR when the time is right. Some questions that I have:

how important is the backwards compatibility of the "pear" and "pecl"
script commands? I.e. does Pyrus need to provide a way to emulate the
interface to these scripts or can we break backwards compatibility on
this point by having these scripts just call pyrus's frontend with
default channels pear/pecl?
what about php 6? Any interest in providing Pyrus with php 6? (this
is much more long-term hypothetical than the previous question since few
of you know anything about pyrus. Pyrus is a PHP 5.3+ re-write of the
PEAR installer)

Thanks,
Greg

16 years ago by Pierre Joye — view source — reply

unread

hi,

Hi,

I'd like to start a discussion on php-src/pear and how we can manage it
better for PHP 5.3, and to discuss the future of PEAR in PHP.

First, take note that both internals@ and pear-dev@ are copied on this
email.

For some background, currently the pear components are dynamically added
to a checkout by downloading from pear.php.net. These components are
install-pear-nozlib.phar and go-pear.phar (for windows). In addition,
the windows go-pear.phar is only downloaded by the build script for
windows. Although this works, it adds some obscurity to how the process
really works.

Is it possible to have one single phar for all platforms? That would
already make the whole thing easier to manage.

I'd like to consider instead using svn:externals to pull in PEAR stuff
directly from a STABLE branch from somewhere in the pear/ hierarchy.
This would allow us over at PEAR to push the installation phars into
that branch at the same time a release is made, and would also allow
quick fixes by a quick revert to a previous revision.

Sounds clean enough and will hopefully avoid the recent issues.

how important is the backwards compatibility of the "pear" and "pecl"
script commands? I.e. does Pyrus need to provide a way to emulate the
interface to these scripts or can we break backwards compatibility on
this point by having these scripts just call pyrus's frontend with
default channels pear/pecl?

New tools, new commands. How different is it to install a package?

Too early for php6 :)

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

16 years ago by Greg Beaver — view source — reply

unread

Pierre Joye wrote:

hi,

Hi,

I'd like to start a discussion on php-src/pear and how we can manage it
better for PHP 5.3, and to discuss the future of PEAR in PHP.

First, take note that both internals@ and pear-dev@ are copied on this
email.

For some background, currently the pear components are dynamically added
to a checkout by downloading from pear.php.net. These components are
install-pear-nozlib.phar and go-pear.phar (for windows). In addition,
the windows go-pear.phar is only downloaded by the build script for
windows. Although this works, it adds some obscurity to how the process
really works.

Is it possible to have one single phar for all platforms? That would
already make the whole thing easier to manage.

This would be more challenging to do, but may be possible. The biggest
problem is that go-pear is interactive, and install-pear is not.

One thing that is good to note is that both go-pear/install-pear may be
obsoleted by Pyrus since it doesn't need to be installed to work. The
only thing that we'd need to distribute would be scripts to invoke
Pyrus. My question is mainly whether to make stub "pear" and "pecl"
scripts that will invoke Pyrus, and if these should pretend to be PEAR
(support some of the more obscure things PEAR supports).

I'd like to consider instead using svn:externals to pull in PEAR stuff
directly from a STABLE branch from somewhere in the pear/ hierarchy.
This would allow us over at PEAR to push the installation phars into
that branch at the same time a release is made, and would also allow
quick fixes by a quick revert to a previous revision.

Sounds clean enough and will hopefully avoid the recent issues.

how important is the backwards compatibility of the "pear" and "pecl"
script commands? I.e. does Pyrus need to provide a way to emulate the
interface to these scripts or can we break backwards compatibility on
this point by having these scripts just call pyrus's frontend with
default channels pear/pecl?

New tools, new commands. How different is it to install a package?
Basic stuff is all the same, install/upgrade/uninstall work as PEAR
does, identical syntax and all. Some of the more obscure stuff has been
removed, such as --soft, --register-only and --ignore-errors.
Configuration has changed a bit, and the config-set command has been
replaced with just "set" The "info" command performs the duty of both
info and remote-info, and remote-list has replaced list-all. In
addition, the --installroot option as implemented by PEAR (which was
always strange) is gone, --packagingroot is the option for those doing
RPM building.

Pyrus, however, is alpha, which is why I'm asking what is really
important, we can still change it if anything is really crucial.

Greg

16 years ago by Pierre Joye — view source — reply

unread

Is it possible to have one single phar for all platforms? That would
already make the whole thing easier to manage.

This would be more challenging to do, but may be possible. The biggest
problem is that go-pear is interactive, and install-pear is not.

One thing that is good to note is that both go-pear/install-pear may be
obsoleted by Pyrus since it doesn't need to be installed to work. The
only thing that we'd need to distribute would be scripts to invoke
Pyrus. My question is mainly whether to make stub "pear" and "pecl"
scripts that will invoke Pyrus, and if these should pretend to be PEAR
(support some of the more obscure things PEAR supports).

Even better :)

New tools, new commands. How different is it to install a package?
Basic stuff is all the same, install/upgrade/uninstall work as PEAR
does, identical syntax and all. Some of the more obscure stuff has been
removed, such as --soft, --register-only and --ignore-errors.
Configuration has changed a bit, and the config-set command has been
replaced with just "set" The "info" command performs the duty of both
info and remote-info, and remote-list has replaced list-all. In
addition, the --installroot option as implemented by PEAR (which was
always strange) is gone, --packagingroot is the option for those doing
RPM building.

Pyrus, however, is alpha, which is why I'm asking what is really
important, we can still change it if anything is really crucial.

I would go with the new syntax, there is no need to keep BC here.

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

16 years ago by johannes@php.net — view source — reply

unread

I'd like to consider instead using svn:externals to pull in PEAR stuff
directly from a STABLE branch from somewhere in the pear/ hierarchy.
This would allow us over at PEAR to push the installation phars into
that branch at the same time a release is made, and would also allow
quick fixes by a quick revert to a previous revision.

How does this work with tagging or releases?
Currently the phar thing isn't tagged at all when building PHP releases,
but I assume the svn:externals would be copied as is and might lead to
wrong assumptions (like that a newer version was included) meaning we
make the tagging more complex or avoiding confusion.

Additionally: With the current process I can be assured that the package
being used is a released" package, such a linkage might catch a random
dev version or bad version numbers or ....

johannes

16 years ago by Lukas Kahwe Smith — view source — reply

unread

I'd like to consider instead using svn:externals to pull in PEAR
stuff
directly from a STABLE branch from somewhere in the pear/ hierarchy.
This would allow us over at PEAR to push the installation phars into
that branch at the same time a release is made, and would also allow
quick fixes by a quick revert to a previous revision.

How does this work with tagging or releases?
Currently the phar thing isn't tagged at all when building PHP
releases,
but I assume the svn:externals would be copied as is and might lead to
wrong assumptions (like that a newer version was included) meaning we
make the tagging more complex or avoiding confusion.

if you svn copy .. it will copy the externals ..

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

16 years ago by Matteo Beccati — view source — reply

unread

Greg Beaver ha scritto:

Matteo Beccati wrote:

Not really: it will copy the link, not its content. At least that was my
experience when I managing releases for an internal project using
externals. What I usually did was to change the externals property to
point to a specific revision, e.g.

Property svn:externals set to
foo -r33165 https://svn.example.com/bar

Depending on the process it can either be done in the branch before
tagging or on the tag itself.

As a result exporting a tag will consistently retrieve the same version
of the external resource even years after packaging.

This sounds easy to forget - is it possible to script this?

Not sure how packaging currently works, but I'm pretty sure it is
possible to extend whatever we currently have to create an svn tag and
do the required changes before exporting for packaging.

If needed I can help with it once the whole process is defined.

Cheers

Matteo Beccati

OpenX - http://www.openx.org

16 years ago by Lukas Kahwe Smith — view source — reply

unread

Greg Beaver ha scritto:

Matteo Beccati wrote:

Not really: it will copy the link, not its content. At least that
was my
experience when I managing releases for an internal project using
externals. What I usually did was to change the externals property
to
point to a specific revision, e.g.

Property svn:externals set to
foo -r33165 https://svn.example.com/bar

Depending on the process it can either be done in the branch before
tagging or on the tag itself.

As a result exporting a tag will consistently retrieve the same
version
of the external resource even years after packaging.

This sounds easy to forget - is it possible to script this?

Not sure how packaging currently works, but I'm pretty sure it is
possible to extend whatever we currently have to create an svn tag and
do the required changes before exporting for packaging.

If needed I can help with it once the whole process is defined.

err .. of course you need to either point to a specific revision .. or
better yet to a tag.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

16 years ago by Matthew Weier O'Phinney — view source — reply

unread

Matteo Beccati wrote:

Lukas Kahwe Smith wrote:

I'd like to consider instead using svn:externals to pull in PEAR stuff
directly from a STABLE branch from somewhere in the pear/ hierarchy.
This would allow us over at PEAR to push the installation phars into
that branch at the same time a release is made, and would also allow
quick fixes by a quick revert to a previous revision.

How does this work with tagging or releases?
Currently the phar thing isn't tagged at all when building PHP releases,
but I assume the svn:externals would be copied as is and might lead to
wrong assumptions (like that a newer version was included) meaning we
make the tagging more complex or avoiding confusion.

if you svn copy .. it will copy the externals ..

Not really: it will copy the link, not its content. At least that was my
experience when I managing releases for an internal project using
externals. What I usually did was to change the externals property to
point to a specific revision, e.g.

Property svn:externals set to
foo -r33165 https://svn.example.com/bar

Depending on the process it can either be done in the branch before
tagging or on the tag itself.

As a result exporting a tag will consistently retrieve the same version
of the external resource even years after packaging.

This sounds easy to forget - is it possible to script this?

Yes -- we do it in ZF as we pull in Dojo via svn:externals.

We use "svn propget" to find where the svn:externals point, and then use
"svn info" on that externals URL to determine what the current revision
is. When we build the tag, we then create a new svn:externals definition
for the new tag that pins to that specific revision.

I'll find the relevant code from our build scripts and paste it in here
if you need specifics.

--
Matthew Weier O'Phinney
mweierophinney@gmail.com
http://weierophinney.net/matthew/