Splitting the subject: the PECL/PHP relationship

Hello Lukas,

Sunday, February 3, 2008, 10:56:08 AM, you wrote:

Steph Fox wrote:

Hi Marcus,

what I want is php-src as minimum you can depend on. And php-
default as
release managers playground. The RM can then say what he thinks is
mature
enough to make it into a release.
What I want is a PHP core that is really core. By that I mean
things like: date, spl, pcre, zlib, filter, simplexml, core-ish
stuff such as PDO (no PDO drivers, unless we bundle SQLite as we
could/should IMHO so there's a working DB for all), and underlying
libs like libxml and mysqlnd that will make life easier for the
many. I think what is distributed with PHP should be built-in and
enabled by default, and it should include the basic essentials for
making a simple website without anything else being added - and
nothing more.

This opens another can of worms :(
Why include installation specific stuff in the core. MySQL was
dropped as the default for a reason lets not reintroduce it.
Not bothering much WITH MySQL ( other than ensuring that SQL
generated in my projects will still run on it ) I see that this new
mysqlnd module is intended to SUPPORT PDO. Is THIS the way forward,
building native drivers that can be used via PDO or is it just a
another indication that one needs both PDO and a native driver?

I am also not sure if including mysqlnd in PHP core is the way to go.
However I would not be generally opposed to including it in the PHP
distribution.

So just to make sure that this list is also aware of what has spawned
out of the PDO discussion. One of the proposals has been to keep PDO
driver development in PECL and therefore no CLA'ed stuff would be in
php-src. The obvious problem is that currently PECL<>core do not
really have the necessary concepts in place to make this happen,
though the ideas necessary to make this work predate even PDOv1.

Very long ago some people have formulated the vision that a PHP
release would be similar to that of a Linux distribution.

PHP core ~ Linux Kernel
Various PECL extensions ~ Various OSS extensions

Some Linux Distributions also go so far to include some closed source
components. I doubt that we want to go there, but we might want to
include CLA'ed stuff. However that is beyond the discussion of this
thread. This thread is about discussing if there is a better way to
handle PECL packages.

• most new extensions these days begin their life in PECL

MySQLND was the last extension started in php-src and I don't even remember
when this was discussed (though in the current structure I like it there
pretty much). Anyway my idea is to start everything in PECL and
to to move everything out that can be moved out. And that includes all MySQL
extensions as well as SQLite. Only this way people will use the PELC
infrastructure. Otherwise we would just reduce functionality of PHP. And btw
nearly all linux distributions today offer a bunch of PECL extensions, and
for windows we offer DLLs for most PECL extensions for a long time now.

marcus

• generally PECL extensions are expected to follow internals CS (but
  they are not really checked if they do so)
• most extensions are not dramatically changed before inclusion to fit
  PHP core, they either fit or they do not .. most extensions are
  actually either developed with the idea of eventually being included
  or they will most likely never make it into core (Steph already gave
  an example, that some PECL extensions tend to be much liberal with the
  use of Exceptions than is currently accepted in php-src)
• if an extension is added to php-src, it is done through symlinking
  the PECL and php-src CVS
• a few extension are also removed from php-src .. I am not quite sure
  how the process is there, but I presume the code is removed in php-src
  and checked into PECL CVS

We move the directory (or would drop the link).

• ... (please complete this list)

regards,
Lukas

Best regards,
Marcus

Hi Lukas,

Correct me if I am wrong or if I am missing something, but currently
things work more or less like this. I think its important that we get
an understanding of how things are right now and what the issues are,
before we go off and solve them (maybe with the above mentioned
approach):

• most new extensions these days begin their life in PECL
• generally PECL extensions are expected to follow internals CS (but
  they are not really checked if they do so)
• most extensions are not dramatically changed before inclusion to fit
  PHP core, they either fit or they do not .. most extensions are
  actually either developed with the idea of eventually being included
  or they will most likely never make it into core (Steph already gave
  an example, that some PECL extensions tend to be much liberal with the
  use of Exceptions than is currently accepted in php-src)
• if an extension is added to php-src, it is done through symlinking
  the PECL and php-src CVS
• a few extension are also removed from php-src .. I am not quite sure
  how the process is there, but I presume the code is removed in php-src
  and checked into PECL CVS
• ... (please complete this list)

• No QA.

• Steph

I am also not sure if including mysqlnd in PHP core is the way to go.
However I would not be generally opposed to including it in the PHP
distribution.

There's a technical reason for that: It needs to be statically buildin
to work properly. Same reason why ext/libxml is there actually.

--Jani

Hello Ben,

None of this is necessary though. What I proposed was moving extension
development from php-src to PECL an dthen bundle what we see fit into the
distribution just as we do now, whith the RM having the last say what goes
in and what not. In my proposal we would only put stuff into php-srec that
is the base for other stuff. For instance libxml is tthe base for all other
xml extensions. So you and most other users would get a relase build from
the selection on php-default. And that will most likely include your
xmlreader and writer, just as they are today in php-src.

marcus

Monday, February 4, 2008, 10:42:39 AM, you wrote:

At 04:33 AM 2/4/2008, Derick Rethans wrote:

Everything else - the fashionistas (JSON, xmlreader/writer) and
the downright
useful for some but not all (fileinfo, json, com_dotnet, posix)
and the quirky
stuff (pretty much anything Sara came up with) - should be in PECL.

I see another issue after reading this, and that is that it makes it
much harder for users to depend on specific extensions just being always
available by default. It's important for application distributers to
have this core set of extensions to rely on. It's annoying enough that
some distributions (gentoo, freebsd) already use --disable-all and their
users then bugging us (or me) with "you should check that SPL is enabled
in your code".

     Just poking up my head to concur with Derick. What one 

person thinks of as 'fashionistas', another person will think of as
absolutely core and necessary -- for example, I use xmlreader/writer
in almost every piece of code I put out. If it were suddenly part of
a PECL, a whole bunch of things I've written would break instantly.
Yes, it's easy enough to work around, but backwards-compatibility
will make for a happy PHP community.

--->Ben

Best regards,
Marcus

     Just poking up my head to concur with Derick. What one

person thinks of as 'fashionistas', another person will think of as
absolutely core and necessary

+1

I don't think this list will ever reach concensus on what "should" be
in core, at least not without a LOT of discussion that will ultimately
end up in a solution involving politics more than technology...

Just Thinking Aloud:
PERHAPS, a distribution of a "skinny" PHP with everything in PECL, and
a "fat" one where everything anybody on the Dev Team wants gets linked
in statically would be better?

Then nobody has to fight for their extension to be included; it will
be in the "fat" one.

And the camp that wants "core" to be minimal gets what they want.

Everybody's happy, except that there's now two binaries to choose from
for the initial download to document... :-)

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?

Steph Fox wrote:

Hi Derick,

I see another issue after reading this, and that is that it makes it
much harder for users to depend on specific extensions just being always
available by default. It's important for application distributers to
have this core set of extensions to rely on. It's annoying enough that
some distributions (gentoo, freebsd) already use --disable-all and their
users then bugging us (or me) with "you should check that SPL is enabled
in your code".

Well, you should, while it's possible to disable it!

Consider a distribution that has only the essentials. Consider also a
relatively small bundle of PECL extensions that ships alongside it. Say
we classify them: everything that currently ships with core would be
class A1 or whatever, as would anything else in PECL that is stable and
considered likely to be useful to a wide range of users. Anything in
that bundle is "recommended", and we make it very plain to sysadmins
that they should install any of that bundle supported by their system.
It includes things like (most) PDO drivers, SOAP, sqlite, zip, curl,
json... all things that are currently shipped with the core but not
necessarily (under doze at least) enabled by default. We educate PHP
users to insist on 'the A1 pack'. We also make it possible to operate
PHP without 'the A1 pack', but I do just mean 'possible'. (In other
words it should be possible to write a basic website using PHP as it
comes, without adding or enabling anything.)

If everything in PECL were classified, it'd be much easier for people to
figure out what to load and when. A simple 'justification' line
alongside the classification would be immensely helpful, assuming the
info in package.xml is made obvious via the installer. You'd need a few
extra sections in package.xml, e.g:

<version>2.0</version>
<status>stable</status>
<classification>
<rank>A2</rank>
<reason>specialist interest</reason>
</classification>
<maintenance>
<level>active</level>
<lastfix>10/01/08</lastfix>
<bugsopen>5</bugsopen>
</maintenance>

As a side note, Pyrus development is continuing (will be restarting once
the phar work slows a bit). There are several things I want to do for
pecl that we don't do now. Here's the "off the top of my head" list:

1. build_dir - instead of using a random temporary directory for
   building, so those temp files hang around, making it easier to
   debug/patch (providing "pyrus make-clean" to clean up would be a piece
   of cake as well.
2. any changes you all work out like Steph's proposal for additions to
   package.xml, although I would recommend instead putting those in a
   special file within package.xml that is human-readable and machine
   parseable that pyrus would look for, so that the exts can still be
   installed by the PEAR installer.

Greg

I see another issue after reading this, and that is that it makes it
much harder for users to depend on specific extensions just being always
available by default. It's important for application distributers to
have this core set of extensions to rely on. It's annoying enough that
some distributions (gentoo, freebsd) already use --disable-all and their
users then bugging us (or me) with "you should check that SPL is enabled
in your code".

Well, you should, while it's possible to disable it!

Uh, no? Most of those things (pcre and SPL) are absolutely necessary - I
find it strange enough that they can actually be disabled. I refuse to
make hacks in code just because some distributions fuck up the default
installed extensions.

Consider a distribution that has only the essentials. Consider also a
relatively small bundle of PECL extensions that ships alongside it. Say we
classify them: everything that currently ships with core would be class A1 or
whatever, as would anything else in PECL that is stable and considered likely
to be useful to a wide range of users. Anything in that bundle is
"recommended", and we make it very plain to sysadmins that they should install
any of that bundle supported by their system. It includes things like (most)
PDO drivers, SOAP, sqlite, zip, curl, json... all things that are currently
shipped with the core but not necessarily (under doze at least) enabled by
default. We educate PHP users to insist on 'the A1 pack'. We also make it
possible to operate PHP without 'the A1 pack', but I do just mean
'possible'. (In other words it should be possible to write a basic website
using PHP as it comes, without adding or enabling anything.)

You really think that would work? You forget that for most shared
hosters they just install PHP so that they can say they support it, but
actually don't give a ratsass about what is actually supported.

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org