> 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
- 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