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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
