Skip to content

Instantly share code, notes, and snippets.

@lox
Created November 23, 2010 04:03
Show Gist options
  • Save lox/711221 to your computer and use it in GitHub Desktop.
Save lox/711221 to your computer and use it in GitHub Desktop.
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
Copy link

pda commented Nov 23, 2010

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

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
Copy link
Author

lox commented Nov 24, 2010

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

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

pda commented Nov 25, 2010

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

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

Has this conversation moved elsewhere? died?

@augustohp
Copy link

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

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

@lox
Copy link
Author

lox commented Dec 13, 2010

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

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

@jdp
Copy link

jdp commented Dec 30, 2010

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

@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
Copy link
Author

lox commented May 5, 2011

Not dead! Thanks for reminding me!

@rowanmanning
Copy link

rowanmanning commented May 5, 2011 via email

@lox
Copy link
Author

lox commented May 7, 2011

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

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

@zquintana
Copy link

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

dersam commented Jun 11, 2012

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

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
Copy link
Author

lox commented Jun 11, 2012

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

dersam commented Jun 11, 2012

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