PEAR2 is a repository of code that seeks to solve these
problems:

 1) provide a simpler installation system than PEAR
 2) provide code that takes advantage of the best new
features in PHP 5
and beyond
 3) provide a stronger coding community than PEAR
 4) provide more flexible code that can be used in more
settings
 5) provide better application support
 6) provide a more rigorous standard for stable code
 7) provide a safer and more relaxed environment in which to
innovate
 8) pay more conscious attention to performance as part of
the goal to
be flexible and attract more developers who will use this
code in
high-traffic situations

Specific problems that have arisen recently include:

* inability to easily relocate a PEAR installation
Many people find it difficult to move a PEAR installation to
another
location on the same computer, or more importantly, to
deploy it to a
production server.  There have been regular messages on
pear-general
dealing with problems of remotely installing PEAR, whether
it is with
PEAR_Frontend_Web on unix, PEAR_RemoteInstaller, or strange
bundlings of
PEAR files that break the relative locations of files,
requiring odd
include_path hacks.

* difficulty bundling PEAR libraries inside applications not
distributed
through the PEAR installer
It is generally more complex to bundle a PEAR library
because the
relative includes in require_once force the user to set up a
relative
include_path programmatically, and to ensure that there are
no files
with the same names (i.e. DB.php, for example) that would be
loaded instead.

* difficulty managing multiple PEAR installations
This has been a problem most often when users on unix have a
system PEAR
installation and a local installation, or other similar
setups where
include_path points at the wrong installation, making it
look like
packages have been installed that have not otherwise been
installed.

* difficulty managing uncaught PEAR_Error
We've all seen the posts like "I get fatal error: call
to unknown method
PEAR_Error->add(), but I asked for a Foo object!"

* great difficulty re-bundling a PEAR package into another
non-PEAR format
Some examples: any phar archive, go-pear, installation
scripts for web
applications that require PEAR like blogs.
Many people asking for technical support are having trouble
understanding how their application expects them to set up
include_path
because it is not immediately apparent where the files
should be, or why
the application is not detecting their properly installed
PEAR
repository and so on, which is evidence that the web
application authors
also had difficulty with this question of re-bundling PEAR
or externally
requiring it.

* complications making code based on PEAR opcode-cacheable
This point has been hashed and re-hashed on the mailing
lists, and I
don't wish to pick at old scabs if possible, but will
clarify if asked
(again).

PEAR2 also seeks to preserve the strengths of PEAR, which
include:

 1) passionate developers who want a venue to voice their
talents
 2) strong dependency management
 3) strong stability (stable/beta/alpha) management
 4) a clear, unified coding standard
 5) easily debugged code with clear documentation of
inter-file dependencies

With these problems and goals in mind, the RFC was born. 
Several
exciting changes have happened in the core of PHP itself
that will
directly influence the final decisions of what PEAR2 and its
installer
Pyrus will look like.  The first genesis of the RFC occurred
after
several high-profile blog posts of Rasmus, Gopal and a few
others that
all reviled the usage of require_once/include_once as a
performance
killer and enemy of the KISS principle in PHP.  Rasmus's
post was the
un-framework PHP framework (which incidentally recommends
writing the
framework yourself primarily, rather than using re-usable
components,
but I think we can prove that sentiment to be misguided with
time .

Gopal posted several entries on his struggles getting APC to
cache
require_once/include_once and some of the misguided attempts
to
circumvent include_once.

After reading these, I posted a message to pear-group
(http://osdir.com/ml/php.pear.core/2006-10/msg00018.html) which I
excerpt here:

"...a list of my priorities for the next generation
installer.

#1 installer should run out of the box without needing
installation
#2 libraries need to be opcode cache-friendly (require
instead of
require_once, or a class loader)
#3 simpler configuration
#4 better registry

Only #2 affects the PEAR community at large, although as
you'll see #3
could have a significant impact."

I've already implemented #3 and #4, and in part of the
effort to implement #1, discovered a few of the other
aspects of the RFC.  #2 shows my initial thoughts.  After
several people including Rasmus volunteered opinions, one of
which in particular was very influential (http://osdir.com/ml/php.pear.core/2006-10/msg00020.html), and his reply here (http://osdir.com/ml/php.pear.core/2006-10/msg00027.html) to my next attempt.  Watching the evolution of the
original idea, which can be summed up as "class loader,
maybe __autoload() or something?" to the last message
should make some more sense seeing it.

Once the idea of using autoload() or not was settled, only
then did it occur to me that this would solve the problem of
bundling a package into a phar archive and glomming a
packaging into a single file was suggested much later by a
developer (sorry, don't remember who).  As such, these are
ancillary benefits.  The primary goal is to make PEAR2 just
as easy to work with but more efficient than PEAR on the
systemic level.  It will still be up to the individual
authors to make their code run as fast as it can, and PEAR2
as a repository won't seek to control that, it will be up to
developers and their collectives to do so.  However,
removing an obvious barrier that can make a difference is
worth doing IF it doesn't compromise the other goals.

The addition of the "allfiles" idea was simply an
attempt to help beginners load a package all at once without
needing to do any configuration whatsoever - this is the
sole goal of the "allfiles idea" and as can be
seen, this simple idea ends up being very complex in
practice.

My best experiences working with PHP apps and libraries have
been the ones that have needed the least configuration, and
have both made good assumptions for me, and offered few
options.  One of the primary goals of PEAR2 is to capture
this experience for PEAR packages.  This is why the idea of
removing php_dir and data_dir as configurable values is so
appealing - it removes the need for either php_dir or
data_dir replacements in most situations, simplifying both
the packaging process and the installation process, and
thereby cutting down on errors.

It must be noted that the addition of namespaces changes a
great deal.  There is an uncommitted patch on php-internals
adding autoload support to namespaces which will change
things quite a bit.  Because of that patch, using
unqualified classnames no longer works with autoload if they
share the same name as an internal class (like Exception),
which will happen with this code:

PEAR2/Package/Exception.php:
<?php
namespace PEAR2::Package;
class Exception extends PEAR2::Exception {}
?>

PEAR2/Package/Thing.php:
<?php
namespace PEAR2::Package;
class Thing
{
    function __construct()
    {
        // this should load PEAR2::Package::Exception, but
instead throws the built-in Exception
        throw new Exception('hi');
    }
}
?>

However, by using an explicit import, the problem goes
away:

PEAR2/Package/Thing.php:
<?php
namespace PEAR2::Package;
import PEAR2::Package::Exception; // from
PEAR2/Package/Exception.php
class Thing
{
    function __construct()
    {
        // this now loads PEAR2::Package::Exception
        throw new Exception('hi');
    }
}
?>

Suddenly, this doesn't look so different from:

PEAR2/Package/Thing.php:
<?php
namespace PEAR2::Package;
require_once 'PEAR2/Package/Exception.php';
class Thing
{
    function __construct()
    {
        // this should load PEAR2::Package::Exception, but
instead throws the built-in Exception
        throw new Exception('hi');
    }
}
?>

So perhaps by substituting the import statement for
require_once, this will preserve the readability and
maintainability?  It should be noted that for conflicting
classnames, we can also use:

import PEAR2::OtherPackage::Exception as OException;

and then use it freely in the file as
"OException"

I hope this document will help to settle some of the bad
blood that has occurred on pear-dev.  I, and the entire PEAR
Group, wish to apologize for any appearance of
strong-arming, and hope that with this message, the motives,
the problems, and some of the potential solutions are better
understood.

Thanks for your time and reading all the way to here.
Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Gregory Beaver wrote:
> 
> It must be noted that the addition of namespaces
changes a great deal.  There is an uncommitted patch on
php-internals adding autoload support to namespaces which
will change things quite a bit.  Because of that patch,
using unqualified classnames no longer works with autoload
if they share the same name as an internal class (like
Exception), which will happen with this code:
> 
[snip]
> 
> Suddenly, this doesn't look so different from:
> 
> PEAR2/Package/Thing.php:
> <?php
> namespace PEAR2::Package;
> require_once 'PEAR2/Package/Exception.php';
> class Thing
> {
>     function __construct()
>     {
>         // this should load PEAR2::Package::Exception,
but instead throws the built-in Exception
>         throw new Exception('hi');
>     }
> }
> ?>
> 
> So perhaps by substituting the import statement for
require_once, this will preserve the readability and
maintainability?  It should be noted that for conflicting
classnames, we can also use:
> 
> import PEAR2::OtherPackage::Exception as OException;
> 
> and then use it freely in the file as
"OException"
> 
> I hope this document will help to settle some of the
bad blood that has occurred on pear-dev.  I, and the entire
PEAR Group, wish to apologize for any appearance of
strong-arming, and hope that with this message, the motives,
the problems, and some of the potential solutions are better
understood.
> 
> Thanks for your time and reading all the way to here.
> Greg

Just a quick note: I'd strongly suggest to not shortcut the
namespaces
or even use import at all in PEAR2, but always use fully
qualified
namespaces. It makes the code much clearer for debugging,
and prevents
WTF moments.

 -Philippe

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

Philippe Jausions wrote:
> Just a quick note: I'd strongly suggest to not shortcut
the namespaces
> or even use import at all in PEAR2, but always use
fully qualified
> namespaces. It makes the code much clearer for
debugging, and prevents
> WTF moments.

For me the most obvious benefit of namespaces is getting rid
of 
PEAR2_Obnoxiously_Long_Class_Names 
(HTML_QuickForm2_Element_Select_OptionContainer, add PEAR2
to the front and you 
get the idea). Your suggestion kinda defeats this benefit.

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

Gregory Beaver wrote:
> PEAR2 is a repository of code that seeks to solve these
problems:

Sorry, Greg, but these are not problems, these are goals or
even mission 
statements (as in here: 
http://www.dilbert.com/comics/dilbert/games/career/
bin/ms.cgi )

>  1) provide a simpler installation system than PEAR

PEAR isn't simple in the following areas:
a) ...
b) ...
...
z) ...
?

>  2) provide code that takes advantage of the best new
features in PHP 5
> and beyond

which isn't possible with the current PEAR because...

>  3) provide a stronger coding community than PEAR

Current coding community isn't strong enough in the
following areas:
a) ...
b) ...
...
z) ...
?

>  4) provide more flexible code that can be used in more
settings

Current code is inflexible in the following settings:
a) ...
...
z) ...
?

>  5) provide better application support

PEAR application support lacks in the following areas:
a) ...
...
z) ...
?

>  6) provide a more rigorous standard for stable code

which isn't possible with the current PEAR because...

>  7) provide a safer and more relaxed environment in
which to innovate

That part must've come directly from Dilbert mission
statement generator.

>  8) pay more conscious attention to performance as part
of the goal to
> be flexible and attract more developers who will use
this code in
> high-traffic situations

We already had developers who wanted to use PEAR in high
traffic situations, but 
they didn't do it because...

> Specific problems that have arisen recently include:
> 
> * inability to easily relocate a PEAR installation
> Many people find it difficult to move a PEAR
installation to another
> location on the same computer, or more importantly, to
deploy it to a
> production server.  There have been regular messages on
pear-general
> dealing with problems of remotely installing PEAR,
whether it is with
> PEAR_Frontend_Web on unix, PEAR_RemoteInstaller, or
strange bundlings of
> PEAR files that break the relative locations of files,
requiring odd
> include_path hacks.

We must be reading very different pear-general mailing
lists, since the only 
references to RemoteInstaller I can find there are its
release announcements:
http://marc.info/?l=pear-general&a
mp;w=2&r=1&s=remoteinstaller&q=b
the situation with Frontend_Web is roughly the same:
http://marc.info/?l=pear-general&
w=2&r=1&s=frontend+web&q=b

That being said, I support removing the possibility to
separately set the 
php_dir / data_dir / test_dir / doc_dir and rely on relative
paths here.


> * difficulty bundling PEAR libraries inside
applications not distributed
> through the PEAR installer
> It is generally more complex to bundle a PEAR library
because the
> relative includes in require_once force the user to set
up a relative
> include_path programmatically, and to ensure that there
are no files
> with the same names (i.e. DB.php, for example) that
would be loaded instead.

include_path is a non-issue here since we are speaking not
of the newbies but of 
the developers who are already distributing their app with
bundled PEAR packages.

The second point can (and should) be fixed by prefixing,
since having the files 
named DB.php and classes named Date is asking for trouble.

> * difficulty managing multiple PEAR installations
> This has been a problem most often when users on unix
have a system PEAR
> installation and a local installation, or other similar
setups where
> include_path points at the wrong installation, making
it look like
> packages have been installed that have not otherwise
been installed.

...and the proposed solution here is allowing the
unzip-and-go installation, 
which will lead to yet another copy of the package, not
appearing in either of 
"pear list" commands. Nice.

This was a real problem when PEAR was distributed as
unzip-and-go with PHP 
rather than as installer, see the first question in
QuickForm FAQ:
http://pear.php.net/manual/en/pa
ckage.html.html-quickform.intro-faq.php#AEN60110

After people began installing packages with the PEAR
installer, such questions 
died out. I definitely don't look forward to their return.

Maybe we should revisit the installer's output instead, so
that it would be 
immediately obvious where is the installation it manages
located?

> * difficulty managing uncaught PEAR_Error
> We've all seen the posts like "I get fatal error:
call to unknown method
> PEAR_Error->add(), but I asked for a Foo
object!"

This was addressed long ago with the Exception RFC.

> * great difficulty re-bundling a PEAR package into
another non-PEAR format
> Some examples: any phar archive, go-pear, installation
scripts for web
> applications that require PEAR like blogs.
> Many people asking for technical support are having
trouble
> understanding how their application expects them to set
up include_path
> because it is not immediately apparent where the files
should be, or why
> the application is not detecting their properly
installed PEAR
> repository and so on, which is evidence that the web
application authors
> also had difficulty with this question of re-bundling
PEAR or externally
> requiring it.

The solution to include_path problems is educating people
about it not dropping 
the include_path.

Building the distribution is the job of the special build
tools, this shouldn't 
be forced on the package authors. Most of the Open Source
projects just provide 
a source tarball, you don't expect them to provide a file
that will be 
installable with both RPM, MSI and also directly runnable on
15 platforms.

> * complications making code based on PEAR
opcode-cacheable
> This point has been hashed and re-hashed on the mailing
lists, and I
> don't wish to pick at old scabs if possible, but will
clarify if asked
> (again).

If we don't go a "one package --- one file" path,
then we are not performance 
conscious enough. Why settle for a half-solution when the
full solution is 
available?

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

Gregory Beaver wrote:
> It must be noted that the addition of namespaces
changes a great deal.  There is an uncommitted patch on
php-internals adding autoload support to namespaces which
will change things quite a bit.  Because of that patch,
using unqualified classnames no longer works with autoload
if they share the same name as an internal class (like
Exception), which will happen with this code:
> 
> ...
> 
> So perhaps by substituting the import statement for
require_once, this will preserve the readability and
maintainability?  

I read the php-internals threads until my head started to
hurt and I'd like to 
suggest once again that RFC in question should be split in
parts, with those 
parts that people mostly agree upon being proposed soon and
require_once-related 
stuff left until the proverbial dust settles on PHP
namespace implementation.

In any case, thank you Greg for this in-depth description,
it was really helpful.

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Alexey Borzov wrote:
> Hi,
>
> Philippe Jausions wrote:
>> Just a quick note: I'd strongly suggest to not
shortcut the namespaces
>> or even use import at all in PEAR2, but always use
fully qualified
>> namespaces. It makes the code much clearer for
debugging, and prevents
>> WTF moments.
> For me the most obvious benefit of namespaces is
getting rid of
> PEAR2_Obnoxiously_Long_Class_Names
> (HTML_QuickForm2_Element_Select_OptionContainer, add
PEAR2 to the
> front and you get the idea). Your suggestion kinda
defeats this benefit.
I agree that long names are a PITA, and that with namespace
they would
even get longer, :: vs _ . But I feel that spelling things
out
completely reduces the need to track down whatever namespace
a class
might belong to.

IMO the namespace are great to allow you to name your
classes whatever
you like without worrying about collision with others' code,
PHP base
code included.

Call me paranoid if you will, but bugs in implementation of
namespaces
in PHP are always possible and I do not wish to get bug
reports from
users that start doing a bunch of "imports" and
suddenly nothing works
anymore or copying/pasting snippets of
"conveniently-simplified" code
and asking what's wrong.

Anyway, we're not even there yet There will be ample time to
define a
coding standard regarding namespaces when we can play with
them in PHP.

My $.02

 -Philippe

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 8/29/07, Philippe Jausions <Philippe.Jausions11abacus.com> wrote:
> (...)
> Call me paranoid if you will, but bugs in
implementation of namespaces
> in PHP are always possible and I do not wish to get bug
reports from
> users that start doing a bunch of "imports"
and suddenly nothing works
> anymore or copying/pasting snippets of
"conveniently-simplified" code
> and asking what's wrong.

I see your point, but let's not assume that hell freezes
over.

Bugs can happen - maybe will -, but we should not refrain
from using a
feature because there *could* be one. If there is a bug, I
am sure it
will be fixed. On the other hand we shouldn't use a feature
when it
doesn't meet the concept/idea.

One more reason to get involved and help the PHP-people
test, test, test.

Till

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Alexey Borzov wrote:
> Hi,
> 
> Gregory Beaver wrote:
>> It must be noted that the addition of namespaces
changes a great
>> deal.  There is an uncommitted patch on
php-internals adding autoload
>> support to namespaces which will change things
quite a bit.  Because
>> of that patch, using unqualified classnames no
longer works with
>> autoload if they share the same name as an internal
class (like
>> Exception), which will happen with this code:
>>
>> ...
>>
>> So perhaps by substituting the import statement for
require_once, this
>> will preserve the readability and maintainability? 

> 
> I read the php-internals threads until my head started
to hurt and I'd
> like to suggest once again that RFC in question should
be split in
> parts, with those parts that people mostly agree upon
being proposed
> soon and require_once-related stuff left until the
proverbial dust
> settles on PHP namespace implementation.

OK.  This is a plan.  It is important to note that PEAR2 is
targeting
technology that is so new, we may need to retool the way
things are used
prior to release when we understand it better.  I think it
is important
that this basic fact is taken into account.

In other words, those developing for PEAR2 may need to make
a few
structural changes prior to the first truly stable release,
but the goal
is to keep this to a minimum, which is why these coding
standard changes
are being proposed now.  As you recall, mandating exception
usage was
like pulling teeth, and is now clearly recognized as the
best way to do
things in PHP 5 and in PEAR, with no complaints on the
mailing list for
months.  It's always hard to imagine what something might be
like and
always a bit scary to do so.

One of the biggest goals of PEAR2 that I completely forgot
to mention in
the email I sent yesterday, as it is one of my basic
assumptions, is to
bring on board more of the developers who work on the core
of PHP
itself.  PHP core and PEAR historically have had rather icy,
if not
downright hostile, relationship.  I remember a year and a
half ago, for
instance, one of the more belligerent developers practically
screamed at
me on the internals IRC channel for mentioning PEAR, and
quoted all
kinds of figures in the PHP world as saying "PEAR is
crap."

The same person was caught using a PEAR package in his own
code last
week, and has been actually collaborating a bit behind the
scenes on
PEAR .

Other internals developers who previously would not be
caught dead using
PEAR have thawed in their opinions of PEAR as well, and a
few are
running PEAR channels for their own code.  Many of the ideas
in the RFC
come from discussions with these developers (like Rasmus,
for instance).

One of the primary reasons cited is that PEAR remains
PHP4-compatible.
This is unfair for obvious reasons, but they feel PEAR
should be
supporting recent PHP development more strongly.

For full disclosure, I have not formally asked for any kind
of alliance
or participation from core PHP devs, but if PEAR2 can be
shown to
actually enhance the usability of PHP for these advanced
users as well
as for the existing userbase, it will go a long ways towards
making the
repository attractive to other brilliant outsider developers
who use PHP
but have until now refused to touch PEAR with a 10 foot
pole.

Certainly, one could always rely upon other organizations
like Zend or
the Cake foundation to provide the latest advanced
functionality of PHP,
but we all know that the PHP world would suffer from the
lack of the
power provided by the PEAR installer, particularly in
relation to
managing dependencies and smooth upgrades.  I know I'm
biased in this
regard, but those of you developing on this list are all
here indirectly
for these reasons as well.

> In any case, thank you Greg for this in-depth
description, it was really
> helpful.

I'll try to answer your need for clarification on the
problems as soon
as possible.

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Alexey Borzov wrote:
> Hi,
>
> Gregory Beaver wrote:
>> PEAR2 is a repository of code that seeks to solve
these problems:
>
> Sorry, Greg, but these are not problems, these are
goals or even
> mission statements (as in here:
> http://www.dilbert.com/comics/dilbert/games/career/
bin/ms.cgi )
>
>>  1) provide a simpler installation system than
PEAR
>
> PEAR isn't simple in the following areas:
> a) ...
> b) ...
> ...
> z) ...
> ?
PEAR Installer is not simple in that in order to even try
out a package,
an installer must be downloaded and installed with
extensive
configuration, root access is often required just to get
started,
configuration is confusing, registry is not human-readable,
and a
completely unrelated php.ini variable (include_path) must be
configured
properly before the first line of code successfully
executes.
>>  2) provide code that takes advantage of the best
new features in PHP 5
>> and beyond
>
> which isn't possible with the current PEAR because...
This is possible with the current PEAR, but not in the
current PEAR
Installer, which must remain backwards compatible with PHP
4.
>>  3) provide a stronger coding community than PEAR
>
> Current coding community isn't strong enough in the
following areas:
> a) ...
> b) ...
> ...
> z) ...
> ?
Current coding community encourages apathy once a package is
accepted
because there are no demands placed on implementing tests
or
documentation prior to a stable release, the only review is
done at
package proposal, and developers are not encouraged or
required to
collaborate on packages.  Instead, the lead developer has
absolute
control to the point that even the QA group must wait a long
time before
fixing  a package with critical bugs.  In addition,
collaboration on API
is non-existent, each package is on its own, with no
encouragement to
collaborate on interoperability of libraries, even though
PEAR's purpose
is to provide libraries to plug in for solutions.
>>  4) provide more flexible code that can be used in
more settings
>
> Current code is inflexible in the following settings:
> a) ...
> ...
> z) ...
> ?
As I have said many times, the current code has hard-coded
relative
require_once calls that limit PEAR to the
include_path-based
installation, use replacements and hard-coded paths in the
registry that
make it difficult to deploy or relocate a PEAR
installation.
>>  5) provide better application support
>
> PEAR application support lacks in the following areas:
> a) ...
> ...
> z) ...
> ?
PEAR lacks application support in the areas of simply
dropping in PEAR
packages to a non-PEAR application because of the strong
dependence on
relative include_path for loading files.  PEAR also makes it
harder for
applications that often are distributed as "download
this, unzip it, and
run the configuration script" to have dependencies on
PEAR packages, as
most users will not do "download this, install the PEAR
Installer,
install a bunch of packages, run the configuration
script."
>>  6) provide a more rigorous standard for stable
code
>
> which isn't possible with the current PEAR because...
...there is no review of API, tests, or documentation prior
to a stable
release.
>>  7) provide a safer and more relaxed environment in
which to innovate
>
> That part must've come directly from Dilbert mission
statement generator.
Now there's a helpful criticism, thanks Alexey.  I'm sure
the rest of
pear-dev is really glad you contributed this useful and
brilliant idea
to the discourse.

PEAR does not provide a safe or relaxed environment in which
to innovate
because in order to propose a new package, you must first:

1) apply for an account
2) apply for a PEPr proposal with completed code
3) wait 1 week minimum for comments
4) wait for votes for 1 week
5) when approved, apply for a CVS account
6) wait...
7) get CVS karma

The new system proposes something like:

1) apply for an account
2) apply for PEPr proposal with idea and propose it for
development
4) wait for votes for 1 week
5) get SVN account at svn.pear.php.net
6) begin development
7) work without limits until package is ready for beta
status, then
undergo code review

>>  8) pay more conscious attention to performance as
part of the goal to
>> be flexible and attract more developers who will
use this code in
>> high-traffic situations
>
> We already had developers who wanted to use PEAR in
high traffic
> situations, but they didn't do it because...
Many PEAR packages pay absolutely no attention to
performance? 
require_once adds significant drain on performance even
in APC environment, and the use of PEAR_Error and PEAR base
class
imposed noticeable performance drains for many developers
because of
emulation of destructors and the extra penalties of static
method calls
for checking on error conditions (isError()).
>> Specific problems that have arisen recently
include:
>>
>> * inability to easily relocate a PEAR installation
>> Many people find it difficult to move a PEAR
installation to another
>> location on the same computer, or more importantly,
to deploy it to a
>> production server.  There have been regular
messages on pear-general
>> dealing with problems of remotely installing PEAR,
whether it is with
>> PEAR_Frontend_Web on unix, PEAR_RemoteInstaller, or
strange bundlings of
>> PEAR files that break the relative locations of
files, requiring odd
>> include_path hacks.
>
> We must be reading very different pear-general mailing
lists, since
> the only references to RemoteInstaller I can find there
are its
> release announcements:
> http://marc.info/?l=pear-general&a
mp;w=2&r=1&s=remoteinstaller&q=b
> the situation with Frontend_Web is roughly the same:
> http://marc.info/?l=pear-general&
w=2&r=1&s=frontend+web&q=b
The messages I am referring to often don't mention
PEAR_RemoteInstaller
or PEAR_Frontend_Web.  Usually they say things like
"Why can't I erase
files installed by PEAR?" (PEAR_Frontend_Web issue when
run on unix with
permissions set to 0666, the default setting), there was a
message
recently where someone was trying to use an HTML_QuickForm
that had been
installed all into the same directory, breaking the
relative
require_once calls.  Things of this nature are harder to
find with a
straight keyword search, but they have popped up with
surprising regularity.
> That being said, I support removing the possibility to
separately set
> the php_dir / data_dir / test_dir / doc_dir and rely on
relative paths
> here.
>> * difficulty bundling PEAR libraries inside
applications not distributed
>> through the PEAR installer
>> It is generally more complex to bundle a PEAR
library because the
>> relative includes in require_once force the user to
set up a relative
>> include_path programmatically, and to ensure that
there are no files
>> with the same names (i.e. DB.php, for example) that
would be loaded
>> instead.
>
> include_path is a non-issue here since we are speaking
not of the
> newbies but of the developers who are already
distributing their app
> with bundled PEAR packages.
>
> The second point can (and should) be fixed by
prefixing, since having
> the files named DB.php and classes named Date is asking
for trouble.
>
>> * difficulty managing multiple PEAR installations
>> This has been a problem most often when users on
unix have a system PEAR
>> installation and a local installation, or other
similar setups where
>> include_path points at the wrong installation,
making it look like
>> packages have been installed that have not
otherwise been installed.
>
> ...and the proposed solution here is allowing the
unzip-and-go
> installation, which will lead to yet another copy of
the package, not
> appearing in either of "pear list" commands.
Nice.
No, the proposed solution is not allowing unzip-and-go.  The
proposed
solution is a Pyrus-only solution: to more closely link the
registry to
include_path, so that it is harder to install a package in a
random
location, or to support passing in a path that pyrus should
install/update the package directly.  Unzip-and-go is
unrelated to this
problem.
> This was a real problem when PEAR was distributed as
unzip-and-go with
> PHP rather than as installer, see the first question in
QuickForm FAQ:
> http://pear.php.net/manual/en/pa
ckage.html.html-quickform.intro-faq.php#AEN60110
>
>
> After people began installing packages with the PEAR
installer, such
> questions died out. I definitely don't look forward to
their return.
>
> Maybe we should revisit the installer's output instead,
so that it
> would be immediately obvious where is the installation
it manages located?
Again, just because it will be possible to use a package as
unzip-and-go
does not make it the recommended way to use PEAR2 packages. 
Pyrus will
be so much easier to install than the PEAR Installer that
most people
will be comfortable simply downloading it and using it. 
However, some
users will benefit from the added flexibility of not needing
to install
a package in order to use it.  Making this possible does not
mark the
end of the world, nor the beginning of the return to issues
like the one
above.  If the scenario above is what you're worried about,
I understand
where all the fear is coming from.
>> * difficulty managing uncaught PEAR_Error
>> We've all seen the posts like "I get fatal
error: call to unknown method
>> PEAR_Error->add(), but I asked for a Foo
object!"
>
> This was addressed long ago with the Exception RFC.
>
>> * great difficulty re-bundling a PEAR package into
another non-PEAR
>> format
>> Some examples: any phar archive, go-pear,
installation scripts for web
>> applications that require PEAR like blogs.
>> Many people asking for technical support are having
trouble
>> understanding how their application expects them to
set up include_path
>> because it is not immediately apparent where the
files should be, or why
>> the application is not detecting their properly
installed PEAR
>> repository and so on, which is evidence that the
web application authors
>> also had difficulty with this question of
re-bundling PEAR or externally
>> requiring it.
>
> The solution to include_path problems is educating
people about it not
> dropping the include_path.
>
> Building the distribution is the job of the special
build tools, this
> shouldn't be forced on the package authors. Most of the
Open Source
> projects just provide a source tarball, you don't
expect them to
> provide a file that will be installable with both RPM,
MSI and also
> directly runnable on 15 platforms.
Again, nothing in this proposal suggests or encourages
dropping
include_path!  Packages will still be distributed in exactly
the same
layout as before, relative to php_dir.  In fact, the work
done at
installation time of doing baseinstalldir will be done at
packaging
time, so that the distributed packages are identical in most
cases to
how they will look on-disk.

The *only* removal is require_once, which has no relevance
to
include_path, nor to the question of dependencies.

By making it possible to add unrelated files (dependencies)
to a package
archive, this adds the possibility of using a package
without
installation, it does not remove any of the existing
benefits of PEAR. 
This also need not impede the normal way of doing things:

 * develop
 * prepare package.xml for release
 * package
 * upload

Developers may not even notice a difference beyond the
removal of
require_once and using PEAR2_Autoload for development or
some other
custom include() solution.

Are these ideas making more sense yet?
>
>> * complications making code based on PEAR
opcode-cacheable
>> This point has been hashed and re-hashed on the
mailing lists, and I
>> don't wish to pick at old scabs if possible, but
will clarify if asked
>> (again).
>
> If we don't go a "one package --- one file"
path, then we are not
> performance conscious enough. Why settle for a
half-solution when the
> full solution is available?
You can't be for this and also against removing
require_once. 

As I said in the reply to your more recent message, the
proposed
solution is more flexible than simply cramming into one
file.  Yes, it
would allow packages to be crammed into a single file, but
it also
allows them to run off disk the normal way, to be put into a
phar
archive without modification, and even to be crammed into a
single
directory without any relative path hierarchy (not that I
would *ever*
consider doing this, but it's hard to predict the future
with 100%
accuracy, isn't it?).  All of this flexibility simply from
the removal
of a require_once statement at the top of each file.

Greg

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Hi,

Gregory Beaver wrote:
>>>  2) provide code that takes advantage of the
best new features in PHP 5
>>> and beyond
>> which isn't possible with the current PEAR
because...
> This is possible with the current PEAR, but not in the
current PEAR
> Installer, which must remain backwards compatible with
PHP 4.

Thanks for clarification.

>>>  3) provide a stronger coding community than
PEAR
>> Current coding community isn't strong enough in the
following areas:
>> a) ...
>> b) ...
>> ...
>> z) ...
>> ?
> Current coding community encourages apathy once a
package is accepted
> because there are no demands placed on implementing
tests or
> documentation prior to a stable release, the only
review is done at
> package proposal, and developers are not encouraged or
required to
> collaborate on packages.  

Agree here.

> Instead, the lead developer has absolute
> control to the point that even the QA group must wait a
long time before
> fixing  a package with critical bugs.  

This actually makes sense now, since without tests to define
the behaviour it is 
dangerous to allow anyone to "fix bugs" in fact
introducing dozens of new ones.

> In addition, collaboration on API
> is non-existent, each package is on its own, with no
encouragement to
> collaborate on interoperability of libraries, even
though PEAR's purpose
> is to provide libraries to plug in for solutions.

Don't agree here, as you'll only get API collaboration if
you design PEAR as a 
framework rather than a collection of packages. On the other
hand, PEAR has some 
well depended-upon packages even now.

>>>  5) provide better application support
>> PEAR application support lacks in the following
areas:
>> a) ...
>> ...
>> z) ...
>> ?
> PEAR lacks application support in the areas of simply
dropping in PEAR
> packages to a non-PEAR application because of the
strong dependence on
> relative include_path for loading files.  PEAR also
makes it harder for
> applications that often are distributed as
"download this, unzip it, and
> run the configuration script" to have dependencies
on PEAR packages, as
> most users will not do "download this, install the
PEAR Installer,
> install a bunch of packages, run the configuration
script."

Umm, in *nix land you either use a package manager for all
your apps or download 
a .tar.gz, run a ./configure script and that script
complains if it can't find 
something it needs. If you install something commercial then
it comes as a 
bundle with most of its dependencies inside. As I already
said, you are trying 
to mix these approaches.

>>>  7) provide a safer and more relaxed
environment in which to innovate
>> That part must've come directly from Dilbert
mission statement generator.
> Now there's a helpful criticism, thanks Alexey.  I'm
sure the rest of
> pear-dev is really glad you contributed this useful and
brilliant idea
> to the discourse.

Sorry, but these were just generic words that I couldn't tie
to anything at all. 
With your clarification I now understand the specific
problem you were addressing.

>>> * difficulty managing multiple PEAR
installations
>>> This has been a problem most often when users
on unix have a system PEAR
>>> installation and a local installation, or other
similar setups where
>>> include_path points at the wrong installation,
making it look like
>>> packages have been installed that have not
otherwise been installed.
>> ...and the proposed solution here is allowing the
unzip-and-go
>> installation, which will lead to yet another copy
of the package, not
>> appearing in either of "pear list"
commands. Nice.
> No, the proposed solution is not allowing unzip-and-go.
 The proposed
> solution is a Pyrus-only solution: to more closely link
the registry to
> include_path, so that it is harder to install a package
in a random
> location, or to support passing in a path that pyrus
should
> install/update the package directly.  Unzip-and-go is
unrelated to this
> problem.

Thanks for clarification.

>>> * great difficulty re-bundling a PEAR package
into another non-PEAR
>>> format
>>> Some examples: any phar archive, go-pear,
installation scripts for web
>>> applications that require PEAR like blogs.
>>> Many people asking for technical support are
having trouble
>>> understanding how their application expects
them to set up include_path
>>> because it is not immediately apparent where
the files should be, or why
>>> the application is not detecting their properly
installed PEAR
>>> repository and so on, which is evidence that
the web application authors
>>> also had difficulty with this question of
re-bundling PEAR or externally
>>> requiring it.
>> The solution to include_path problems is educating
people about it not
>> dropping the include_path.
>>
>> Building the distribution is the job of the special
build tools, this
>> shouldn't be forced on the package authors. Most of
the Open Source
>> projects just provide a source tarball, you don't
expect them to
>> provide a file that will be installable with both
RPM, MSI and also
>> directly runnable on 15 platforms.
> Again, nothing in this proposal suggests or encourages
dropping
> include_path!  Packages will still be distributed in
exactly the same
> layout as before, relative to php_dir.  In fact, the
work done at
> installation time of doing baseinstalldir will be done
at packaging
> time, so that the distributed packages are identical in
most cases to
> how they will look on-disk.

OK, thanks for clarification, the problem is the initial
advocacy efforts for 
this proposal mentioned how "include_path is hard"
and we should get rid of it.

> The *only* removal is require_once, which has no
relevance to
> include_path, nor to the question of dependencies.
> 
> By making it possible to add unrelated files
(dependencies) to a package
> archive, this adds the possibility of using a package
without
> installation, it does not remove any of the existing
benefits of PEAR. 
> This also need not impede the normal way of doing
things:
> 
>  * develop
>  * prepare package.xml for release
>  * package
>  * upload
> 
> Developers may not even notice a difference beyond the
removal of
> require_once and using PEAR2_Autoload for development
or some other
> custom include() solution.
> 
> Are these ideas making more sense yet?

Yes, they do, but I still have issues with the exact
solution proposed.

>>> * complications making code based on PEAR
opcode-cacheable
>>> This point has been hashed and re-hashed on the
mailing lists, and I
>>> don't wish to pick at old scabs if possible,
but will clarify if asked
>>> (again).
>> If we don't go a "one package --- one
file" path, then we are not
>> performance conscious enough. Why settle for a
half-solution when the
>> full solution is available?
> You can't be for this and also against removing
require_once. 

I'm not exactly against removing require_once, I'm against
juggling "10% faster" 
arguments.

I'll respond to other points in the other thread,
"smart developers".

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php