Hi Chris,
In interests of clarity for all, can you explain what you anticipate
will change for PECL with Phar/Pyrus for Windows and non-Windows?
From my PoV as a Windows user, the primary case for optimisim is based on
the fact that local PEAR installs recently started working properly on
Windows via the PEAR installer. I take that as a welcome sign of maturity in
the original installer script.
Secondary is that Greg's Phar format's coming along really well - it's
possible to run the same phar created with the extension + default stub in
any PHP setting, CLI or web. You don't need to have anything installed other
than PHP itself, and you don't need to unpack a phar to run the application
contained within it. The PHP_Archive-based phars we've been seeing for the
PEAR installer have similar qualities, but I suspect the whole PEAR
inter-dependency thing is a big turnoff for many - so phar's been an
invisible good idea for a long while. That's not necessarily a bad thing, it
means it's had time to evolve.
It would be nice (Greg may not agree here) to have the PECL installer script
completely independent of PEAR classes - at present it throws a hissy fit if
Tar_Archive isn't installed, for example, which is reasonable enough for a
PEAR installation but a complete pain in the butt if you just wanted to pick
up runkit. There's no good reason I know of not to slip tar extraction
functionality directly into the phar stub. PHP's built-in getopt() is
cross-platform from 5.3 on, albeit less than perfect, so we can probably
just about get away without Console_Getopt now. Unless I'm missing something
major, we don't need to know a whole lot about the clientside environment
for PECL either - just the platform, PHP version, extension_dir() and the
path to a writable temp directory. So it should be possible to drop the PEAR
association and simply drop something like pecl.phar into the top-level PHP
directory in releases and snaps; you'd type "php pecl.phar" to open the
application and direct commands thereafter, or stick it in htdocs and type
http://localhost/pecl.phar if you'd prefer your installation via a form. If
you're building PHP fresh out of CVS you can check out the whole of PECL
anyway.
The situation with the PHP_Archive-based phar currently used for the PEAR
installer is that the installer script in it offers PECL release src
packages and installs them on demand, though I gather this is still a little
rough around the edges. The equivalent binary download for Windows isn't in
place at all, but AFAICS there's no real reason it couldn't be made to work,
so long as there's a sane form of tagging somewhere along the line so that a
specific PHP version would be offered appropriate PECL binaries. (I would
imagine this might require *release* binaries to be made available via
pecl.php.net - leaving pecl4win for snapshots - but that's just a wild
thought at present.)
If you can tag individual packages you can also tag groups, so it's not too
big a leap from 'appropriate binary release' to 'appropriate selection of
binaries'. The only thing that can't reasonably be automated is updating the
PHP INI file to load them - and that's not because it's technically
difficult.
Basically I think the technology is pretty much in place, between the PEAR
channels and phar, to make pecl installs a trivial matter across all
platforms. It's mostly a case of getting the PECL infrastructure to work
with it, which is a much tougher task because it needs the PHP core/PECL
community to agree to that in principle, figure out the best approach and
then help make it happen.
- Steph
Chris
--
Christopher Jones, Oracle
Email: [EMAIL PROTECTED] Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book:
http://tinyurl.com/f8jad
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
