I'll only speak for Composer which is a new-ish PHP dependency manager, because I'm the co-lead on the project.

System-wide packages are a massive pain, especially on shared hosts. That's why we took the approach of installing everything local, much like virtualenv or npm do. You get your dependencies for the project, in the project. Upload, done. It comes with an autoloader to load classes and it all works with relative paths, so moving it all around is no problem.

Obviously this only handles php libraries, not apt-get packages or whatever, there are tons of great tools for managing system configuration, and we did not set out to reinvent those. But php libraries can just be downloaded, a few of them might depend on specific extensions but mostly if you have a recent-ish PHP version stuff works on most shared hosts worth their name.

As for your point on adoption, I beg to differ. Symfony which is one of the largest frameworks will use it in it's upcoming 2.1 release, I know of a few other frameworks that are looking into it, many libraries are already made available. Even major apps like Drupal have been looking into using it, not for their plugins at first, only for their own dependencies, but once they also discussed the adoption of it for plugins, and I know a few other CMSs have looked at it for just that, because it's easy to wrap into a web frontend to manage installation of dependencies from anywhere. I'd even argue you could convert an entire ecosystem if you have it all in one controlled database already, generating package metadata on the fly and installing from existing sources, then giving the option to plugin authors to start requiring other plugins and plain libraries instead of bundling everything in their code.

Composer is quite new and it's definitely not widely adopted yet, but things are looking way brighter than you picture them. Given the ease of use of publishing packages (basically you have to write one package definition like in npm, and then for a new release you just have to git tag and push to github), resistance from people should be pretty low. Please see docs on http://getcomposer.org/ if you are curious.

Thanks for the clarification. I guess I was a bit too negative in my first comment.

I'm all for composer if it's going to make library management easier at any level, either local or system-wide. Maybe if several well-known frameworks agree to standardize on composer as their plug-in manager of choice, you may even be able to obtain a de facto monopoly on PHP package management, and that'll be a good thing for all of us. (I'd love to see some sanity in WordPress plug-in management, too, but I guess that's a tall order.)

I just wanted to remind people that as long as you have to make concessions for the current state of shared hosting, you will hit limits at one point or another.

Anymore, I consider system wide package installation to be a liability, not a feature. The whole point/purpose of npm or composer is local installation. Look at the mess of Gem/Bundler and then you have to factor in that rvm and rbenv are basically designed to isolate system wide installation because of the problems associated with system wide installations.

Agreed. I used to dig RVM and rbenv but have come to realize that they are band aids for a problem that should have never been.

BTW, as for pyrus/pear, local install hardly works and it's more of an after-thought anyhow.

I don't think that shared hosting needs to be fixed before you can benefit from a good package manager.

Composer and Pyrus both are able to install packages local to the project.

So just grab the dependencies before and then upload the "damn thing" to the server to deploy and this will work on every shared host out there.

Sure, you can get part of the benefit even if you're on shared hosting. (Off-topic but related example: I use git to manage projects locally even if they are going to be deployed to a server that doesn't support git. Last week I finally moved a small-business client to a git-enabled host, and it was such a relief.) But it's only part of the benefit.

A good packaging system, for example, will track your PHP version and extensions and make appropriate adjustments. But what if your host uses a slightly different version of PHP with a slightly different list of extensions? At best, the packaging system makes adjustments again, and you cross your fingers hoping that nothing breaks. At worst, everything breaks because your host uses the wrong version of GD or whatever.

Every shared host that supports Ruby gets mired in requests for and complaints about specific versions of gems they've installed. I don't think it will be any different for PHP.

The problems you mention are why user land components should be used where possible and wrap builtins. Install the components local to the project and you control the outcome.