Skip to content

Embed URL

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
A proposal for a sane php package manager

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?

@pda

What's with the version number hanging off "phark install pheasant-1.0" ... I just want the latest :)

@lox
Owner

Amended.

@lox
Owner

Dennis' suggestion of aliases for the following are inspired:

phark yeah pheasant
phark off pheasant

@pda

Hell yes :)

@pda

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.

@lox
Owner

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

@lox
Owner

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... :/

@stuartherbert

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

@pda

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.

@augustohp

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.

@lox
Owner

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?

@augustohp

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)

@pda

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

@augustohp

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.

@karlforshaw

Has this conversation moved elsewhere? died?

@augustohp

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

@augustohp

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

@lox
Owner

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.

@augustohp

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

@jdp

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.

@rowanmanning

@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 :)

@lox
Owner
lox commented

Not dead! Thanks for reminding me!

@rowanmanning
@lox
Owner
lox commented

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.

@paulccarey

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

@zquintana

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.

@dersam

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.

@zquintana

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

@lox
Owner

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.

@dersam

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.