A proposal for a sane php package manager

phark_proposal.md

Proposal for Phark, a sane php package manager

As it stands PEAR sucks. It's complicated, clumsy and is full of utter garbage (sorry).

PHP is rapidly dying because we don't have any decent way of writing code that can easily build on the work of others. What we need is a simple, open package management system like rubygems.

We now have decent support for namespaces, class autoloading and archives. I propose we abandon PEAR (and PEAR2, sorry guys) and indeed all of the XML files and channels and what-not and start again.

Well written, re-usable PHP should be:

• PHP 5.3+
• Autoloading, integrate well into different codebases
• Leave the include_path alone, not depend on CWD
• Consistent way of running test suites (think rake)

The package manager should be:

• Terse! (phark install pheasant)
• Multiple versions installed system wide, configured per environment (think virtualenv)
• Channel agnostic, support git, svn, pear channels (see pearhub)
• Allow a project to lock on a particular set of dependancy versions (Gemfile.lock)
• Allow dependancies on pecl
• Installable via pear (yes, I realize the irony)

Accordingly, I am going to try and write Phark in under 2000 lines of code. If it's not possible, I'm jumping ship and never looking back. Any takers?

Amended.

Dennis' suggestion of aliases for the following are inspired:

phark yeah pheasant
phark off pheasant

Hell yes :)

I like the way Bundler / Rubygems does multiple versions of a single gem, and specifying which to use the the Gemfile.
I'd lean towards that model rather than python virtualenv style.

Interesting packaging guidelines for ruby: http://chneukirchen.github.com/rps/

Discussion on issues with RubyGems that lead to Bundler. http://yehudakatz.com/2009/06/15/rubygems-problems-and-proposed-solutions/

They thought they had problems... :/

Any replacement for PEAR needs to be able to install packages into a project's folder. System-wide installs only work in the bedroom.

I've always felt the same about system-wide installs. But the way Bundler locks a project to only the gems specified in the projects Gemfile makes them work very nicely. This also relies on the ability to have multiple versions of a gem installed, and Bundler picks the right one.

Maybe an interesting thing to consider is using PHAR as a mean of distribution of the packages also, since it is only PHP 5.3+ ...
And this discussion and brainstorm should be moved elsewhere, I mean, in a better place for discussions.
But the idea is great. I always thought of something very simple and configuration-free for use.

PEAR is not a piece of crap, but the world moved forward and PEAR2 stayed in the very-same place with almost the same purposes.

Yup phar archives seem like a good idea, Phar was actually the reason for the name "Phark" :)

I maintain that a packaging system that only allows for one globally installed version of a package at a time was never good.

Where would you suggest moving the discussion to?

Phar <=> Phark, that makes sense :P Sorry for the moment of dumbness ...

Actually, a system in a global path has its purposes and uses, but installing it in a local place should be as easy as to install in a global one. If we sit, plan and architect the system based on the existing ones (mentioned on the gist), we can actually make some great work with little, efficient and scalable code. An example of that is Doctrine2.

Moving the discussion to GoogleGroups for example. Right now there isn't much need for that but in a time ....
Fell free to add me on Gtalk (augusto [at] gmail.com) and MSN (augusto_hp [at] msn.com)

Doctrine 2 ORM is 16,595 lines of code across class files.

It is not that uncommon for the cost of an abstraction to outweigh the benefit it delivers. Kill one today!"

-- John Carmack

That said, Bundler is 5,534 lines and rubygems is 9,618 - but they've been out in the wild for some time, especially rubygems. Doctrine 2 isn't even done yet :)

LOC comparison between projects with different objectives can be tricky.
Don't get me bad here, please. What I meant is that Doctrine has a nice architecture for what it does. The second version is already done, they are just waiting for Symfony 2. What we should aim as Doctrine did is to plan a lot first, than put hans on code. Otherwise it could just happen as it did with PEAR2.

In Pear2 they haven't planned what they were going to do, the just had a list of things they wanted. Some people just started coding and done. They try to cure cancer and forget the real problem: the end user.

I completely agree with the quote, I just fear to waste time in something worst and more complicated to maintain than Pear itself or even worst, to realize in the middle of the way that we missed some point and could do something much different.

Wishlist: http://blog.izs.me/post/1675072029/10-cool-things-you-probably-didnt-realize-npm-could-do

Has this conversation moved elsewhere? died?

Maybe it died, but we could schedule a kick-off online meeting to discuss things better, it would be a lot better I think ...

Also we can create a mailing-list, if you pass your e-mails i can create and put everyone on it ...

I'm planning on writing up some more on it this weekend, definitely hasn't died, just waiting for a spare minute! Now that Google Groups is back, perhaps I'll create a mailing list over there.

For those who are interested the list is: https://groups.google.com/group/phark-dev/

I'm very interested in the development of a more modern PHP package system. It's something I've wanted for a while, out of frustration with PEAR and PECL, and longing for hybrid package and environment managers like rip or virtualenv and pip. I'd also be glad to help out.

@lox is this still alive? I'd love to lend a hand or just to see this built! PEAR is large and monolithic, I want installing PHP packages to be as enjoyable as using homebrew :)

Not dead! Thanks for reminding me!

Excellent! Give me a shout when you have an action plan

Ok, rowan got me motivated, so I've written up a README and created the start of the project.

https://github.com/lox/phark

Going to start some discussion on the phark-dev list around package definitions. Can't decide between a Homebrew like system with recipes to define a package, or a ruby gemspec like system where each package has to conform to a best practice layout.

this looks awsome, I miss my bundler and this looks like it may well fill the gap!

I'm all in! I'd love this for a few projects I'm working on currently (a Rails like PHP 5.4 framework and blogging software built on it). Would be great for easily integrating things like php-activerecord and php-sprockets into projects. Let's get it started! I'll help.

Is this dead? I'd like to contribute, but the project doesn't seem to have had any active work in the past few months.

I'm not sure if its dead, but I'd look at composer. I started to contribute there. Good project so far with a fairly active community. Not quite like gem but a start. getcomposer.org. I hope no one gets mad at me for pushing another project :)

At this stage, I think composer is light-years ahead of Phark. Unfortunately I never had the time to dedicate to the project to get it off the ground.

Highly recommend http://getcomposer.org and http://packagist.com, I'm using them personally and at 99designs. I'll update the project README for Phark.

Composer looks like exactly what I was looking for- thanks!