After working with Pear, the PHP package manager, recently one thing has become apparent. PHP needs a new package manager. Over the last couple years I’ve worked with npm, homebrew, and gem which are great package managers for other languages and systems. Using Pear requires extra thought and work as a user, pain for creating packages, and suffering for those handling deployment outside a standard workflow. So, let’s start a conversation about what would be better.
The Problem With Pear
Pear has been around since 1999. The web was an entirely different place. This is back in the day when dial-up internet was common place. After all this time and change in the developer community did Pear become antiquated?From my perspective I have 3 problems and see dozens of places for small potential improvements.
Decentralization
Pear was also built on decentralization. That means something like:$ pear install symfony
Pear doesn’t know what symfony is or where to get it. Before you can install it you need to know where to get it from and add the channel. For example:
$ pear channel-discover pear.symfony-project.com
If there were just a handful of sites providing packages this wouldn’t be an issue. If you use packages from more than a handful of pear channels you could end up needing a manager just for your pear channels much less your PHP packages.
Don’t get me wrong, decentralization is nice in theory. But, in practice it’s lowering my user experience and is a pain point.
The Pain Of Creating Packages
I don't update my projects often in part because of the pain in creating updates to my pear channel.
While I was lamenting over Pear recently a developer shared this with me. That’s when I realized there were others experiencing pain in creating packages. The few times I considered creating a pear channel and packages I started diving into the documentation and walked away after a short bit of screaming. To hear someone who had gone through with creating packages complain about it was new.
Sure, there are tools like Pirum that make it easier. But, creating pear packages is not something many people want to do.
What About Firewalls and Intranets?
Some companies and projects have firewall and packaging restrictions. Sure these can drive developers nuts sometimes but there are often (though not always) good reasons behind them. How do you handle this with Pear?Well, you could create your own Pear channel and put all the packages you want in there. If you look at the package.xml that comes with each package you’ll notice it calls out information like the pear channel it’s associated with. So, you need to update each of the packages before moving them to your internal channel?
Let’s just say this setup is not one I personally want to work in.
A Picture Of What People (Mostly Myself) Want
Putting the justification for why I'm writing this all to long post aside lets focus on what would be great in a PHP package manager. To put it in a single word, simplicity.Can you imagine it being as simple for a user as:
$ foo install bar
$ foo info bar
$ foo self-update
$ foo uninstall bar
$ foo pay bar tab
As an end user I want something simple and easy to use. No channel discovering (yes, I want a central repository). If it’s going to pull from a corporate repository that could be a command line switch or in a system wide config file.
From a developers standpoint simplicity should come first. Imagine the case where creating a new package worked like this.
$ cd /to/package/root
$ foo create bar
At this point a utility asked you a bunch of questions about the package and built the package.xml file for you. Then to publish it you do something like:
$ foo publish bar
This is the type of tool I would want to use. It might even help PHP in the popularity arena.
A Short List Of Requirements
Now that I've painted a picture of what it should look like here's a short list of requirements that should be covered.The ability to create my own distribution site (like the central repo) and easily move packages into it. This will help those secure network types. 2.The ability to import packages into an app. For example:
\Foo\Require(‘bar’);
This may even include a specific version, for example.
\Foo\Require('bar', '1.1.1', '>');
The ability to get apps as well as install them on the system. For example:
$ foo get wordpress
This would go get and download the latest release of wordpress and put it in the directory I’m currently in. Not everything is a package to be installed on a system.