> IMO, PECL is an antiquated system that needs a successor, in much the same > way Composer is the successor to PEAR. I think there are folks working on a > solution for this, but I’m not sure where they are in their efforts. If we > could make extensions as easy to package, distribute, and install (and load > without root privileges) as Composer packages are, then I think we could say > that PECL extensions are preferable.
In case anyone reading this cares to do anything about this situation, there are a few key issues with PECL today: 1. Its codebase tied to PEAR, which has been deprecated. For PECL to survive it needs to separate itself from PEAR to some degree, and it also needs maintained. 2. It doesn't work on Windows. 3. It isn't designed to work with ini configuration directories, and instead is focused on changing a singular `php.ini` file. However, PECL is actually a much better tool than I realized. It supports many things that are useful for package authors, but they don't seem to be used much -- my only guess is that they aren't well known or documented: - It can replace things in files, for example bumping version numbers in source files. - It supports post-install scripts, although they run separately from `pecl install`. - It can install PHP files into the PEAR directories, which allows you to ship PHP files with an extension. I'm hoping that over time with preloading and other features this becomes a viable model, but it's still useful today. ----- There is a tool called pickle that is intended to work on Windows and Linux. It doesn't seem recently maintained (but probably still in better shape than pecl). It has too much abstraction for my taste, so I didn't look at its source a lot; maybe someone else can comment more. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
