Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Composer support for Console_Color #1

merged 3 commits into from Apr 21, 2012


None yet
7 participants

RobLoach commented Apr 17, 2012

Composer is a dependency management system for PHP packages. This pull request adds Composer support to Console_Color. Having this means that a project can use something like the following in a composer.json to depict a dependency on Console_Color:

"require": {
    "pear/Console_Color": "1.*"

CloCkWeRX commented Apr 17, 2012

Controversial :) The first composer pull request on an official PEAR package. TBH, I have no real problems with it, apart from the double effort to keep the package.xml and composer.json in synch.

Out of curiosity, is there any particular reason that the package.xml support in composer doesn't work? http://getcomposer.org/doc/05-repositories.md#pear


CloCkWeRX commented Apr 17, 2012

Oh, and any chance of a similar pull request for https://github.com/pear/Console_Color2 (I'd encourage you to swap over to that, it'll have PHP5+ syntax) ?


cweiske commented Apr 18, 2012

Why should we do this? Apart from that, Composer has a PEAR compatibility layer so PEAR packages don't need a composer.json file.


coderbyheart commented Apr 18, 2012

@CloCkWeRX About the sync issue: We could modify the pear cli to generate composer.json from package.xml ...

Seldaek commented Apr 18, 2012

@cweiske this may be too early, but I hope we can sit down and talk about this at some point. The way I see it PEAR has a bunch of cool packages to offer, and it would be neat to have access to them easily in composer. Right now yes there is a compat layer, but it's not exactly easy, you have to add the pear.php.net repo by hand, and then it delays everything a lot because initializing it takes ~2min (on a fast line) given the amount of packages and the less than optimal protocol for fast retrieval of info. Obviously we can improve things a bit on our end (caching and whatnot), but in the long term I hope you will agree to support Composer a bit more proactively. Our PEAR support definitely has quirks.

By the way, beyond adding the file and registering it on Packagist, you really don't have to do anything unless the requirements of the package change. For standalone packages like this one this should be really easy and will have virtually zero maintenance cost.


CloCkWeRX commented Apr 18, 2012

On Wed, Apr 18, 2012 at 2:30 PM, Markus Tacker <


@CloCkWeRX About the sync issue: We could modify the pear cli to generate
composer.json from package.xml ...

http://pear.php.net/package/PEAR_PackageFileManager_Cli I do personally
like; but it relies on pear_packagefilemanager. There's a bit of work to do
IMO to refactor pear_packagefilemanager2 into something that's more modern
(pfm3); but there's also Pyrus anyway.

https://github.com/pyrus/Pyrus/blob/master/src/Pyrus/Package.php etc aren't
exactly super documented at the moment either, and there's a few places
where DI would be useful.

So... neither of those at first glance feels like a model of a Package, nor
is there a clear serializer/unserializer distinction - at least with my
limited poking through the code.

On top of that the primary focus of those classes, and the PEAR equivalent
is not "Provide a logical model of a Package" and "Serialize/Unserialize to
format X", but "Unserialize and be useful for the task of installation".

So... it seems like a load of effort to throw JSON serialization onto those
things - PFM_CLI is probably the most easy, but it's certainly a PHP < 5.3

If there's better pear package file parsers and serializers out there which
are decoupled / better documented / etc... then we're talking :D

@saltybeagle @cellog or @helgi please feel free to hit me over the head and
show me that it's not as hard as all of that!

Reply to this email directly or view it on GitHub:
#1 (comment)


CloCkWeRX commented Apr 18, 2012


The way I see it PEAR has a bunch of cool packages to offer, and it would

be neat to have access to them easily in composer.


By the way, beyond adding the file and registering it on Packagist, you
really don't have to do anything unless the requirements of the package
change. For standalone packages like this one this should be really easy
and will have virtually zero maintenance cost.

I've only really had a cursory look through things re composer /
packagist. What does registering it on Packagist actually entail?

We've been putting in a lot of effort to get all of the pear packages onto
github - either for the unmaintained but still loved, a complete migration;
or mirroring SVN for those PEAR developers who are still active but not
ready to give up SVN. The running total is around 467 repos - some of those
containing multiple packages.

If we had a package.xml to composer.json xslt or whatever, it'd be fairly
straight forward to use the github APIs to

  • Fork every PEAR, pear2 package - or whatever subset interests you
  • Programmatically git clone it, transform the package xml and render out
    a composer.json
  • Add in a git commit hook to ping packagist (is... this something
  • git commit + push

That way we PEAR folks could see what an "unofficial" mirror via packagist
looks like, package authors that wanted to pick up composer.json files can
just pull the change in if they wanted to pick it up officially...

Also if enough people were interested I'm sure we'd be happy to repeat the
process skipping the whole "unofficial fork bit"

Reply to this email directly or view it on GitHub:
#1 (comment)

Seldaek commented Apr 18, 2012

@CloCkWeRX: "registering on packagist" means going there, giving it the URL of the github repo, and that's about it. I could directly insert all URLs in the DB if this helps. After that we have a github hook that you can/should enable so that whenever you push, packagist updates the package metadata (since it exposes branches as installable versions this is important).

I would tend to say that taking it slow and adding packages when people show interest would be better, because it means you can try it with just a few packages, no need for massive amounts of scripting, and it also means we'll only add packages that people care about and not ultra-old legacy stuff. While I think it would be great to have the good stable/up to date packages, I'd rather avoid cluttering it with deprecated packages. The PHP4 minimum requirement of this package is already pretty scary :)


CloCkWeRX commented Apr 18, 2012

Re PHP4 - see https://github.com/pear/Console_Color2 :)

Re take it slow, aw c'mon. Who doesn't want 467+ new packages :D. How could we measure the interest btw? Is it easy to query all packagist releases and find deps on pear components?

Seldaek commented Apr 18, 2012

Well yeah, that is still PHP 5.0.0 though, which is also scary but less :)

Anyway the taking it slow is just if you think it helps acceptance on PEAR's end. I don't have a problem adding them all at once. The only gotcha is that it won't "see" the current tags since they don't contain composer.json, so only upcoming tags would be usable (or just use the master branch version). For that reason and what I said above, I still think the list should be filtered and only maintained packages that are relevant should be taken in.

Measuring interest is pretty hard because you basically can't depend on pear components right now unless you add the custom repository yourself, which hinders adoption quite a bit in libraries, though i know a bunch of people use PEAR packages via Composer in their own private projects.

Also maybe an extra point in the "why should you care?" category: the whole Composer ecosystem is growing fast, and no matter whether you like composer as a tool itself or not, it would bring more visibility to the PEAR packages, which can't hurt.

I think adding composer files to the packages is a very good idea indeed. PEAR has been criticized lately for being too hard on developers when it comes to standards and peer reviews (Even though I consider this a good thing that it doens't end up like CPAN), etc.

Having a composer file would allow people to distribute their applications faster. @Seldaek would you be interested in a tradeoff where we have a commit hook or a pingback when a packagist PEAR package is installed? This way we could keep track of the information, bug tracker, etc. On PEAR.

All and all, I believe this could be very useful for our community. We could offer the simplicity of Composer, the complexity of PEAR and keep track of what is happening and still offer the same things to our already large community.

What says you?

Seldaek commented Apr 18, 2012

@davidcoallier so if I get it right, all you want is to know when someone installs a PEAR package from Packagist? This is doable, but you also have the totals displayed straight on packagist (see on the right) if it's just for curiosity. I am not sure what you meant regarding the bug tracker.


RobLoach commented Apr 18, 2012

As requested, here is the pull request for Composer support for Console_Color2. The "php": ">=5.0.0" looks much more sane, but both still work. I stuck Console_Color on Packagist via my fork for a demonstration of what it would look like. We'd simply have to switch the repository back once this is merged.

@Seldaek yep that's what I mean. A pingback to know when a PEAR package is installed so current PEAR devs can benefit from the bug-tracker, documentation, package installer, etc. I think a tight-integration would benefit both communities to be honest.

Seldaek commented Apr 18, 2012

@davidcoallier: Just for the record, as we discussed on IRC quickly, exposing the install stats one way or another should be no problem.


till commented Apr 18, 2012

@davidcoallier, @Seldaek We discussed this and nothing came of it. Remember we wanted to meet? (cc @helgi)

Also, quoting my email:

I agree – also, there is a difference between the PEAR installer and PEAR libraries. At least we always wanted that. ;-)

I'm personally not yet convinced that the PEAR-layer in composer is really solid and useful, but anyhow, I have no objections adding this. People can play with it and see if it's worthwhile. If anything, I'd like to wait until composer matures before we add composer.json files everywhere so we don't have to deal with the hassle of upgrading a JSON structure when stuff changes. And composer is still in a very early state.

Besides, I also agree with Christian that this is not really urgent by any means. Because composer can use a SVN or GIT as a source too to install a package. Or use a zip/tar from GH as a dist source.

Seldaek commented Apr 18, 2012

@till: Sounds to me like you want things to stay the same, and that's fine, we're not trying to take anything away from you. But the fact is, all the ways you mention are workarounds that we have in Composer because it enables people to do crazy stuff, but it is hardly the easiest way to work with it, and as I mentioned above, it really hinders the ability of any library to depend on PEAR stuff (btw when I say PEAR I mean the PEAR libraries, the installer has nothing to do with this discussion).

I think that sucks because while I'm not a huge PEAR guy, I know some libs are pretty useful, and in the past I usually refrained from using them because installing was a pain (IMO, please humor me), so if we can fix that I think it's great for me, and I'm pretty sure for many others as well.

In the end it's up to you (the PEAR group) to decide, but the way I see it you have nothing to lose in trying this. All I can do is offer that you ping me if you need any help.

@till @Seldaek anything to make our community and our developers' lives easier I'm happy about. Community is more important than the project (Either composer or PEAR) and our ultimate goal should be making awesome code that people can use and be more productive with.


till commented Apr 18, 2012

@Seldaek You need to chill and read again.

I wanted to do a hackathon last year or even get people to agree on a rough date. Nothing came out of it. That was what I was referring to. :)

In regard to your projected: I contributed to composer already and spent a lot of time with it. There is absolutely no reason to suggest that I am against progress. Since I spent a lot of time with it, I've also ran into a lot of smaller or bigger issues with composer which is expected of course because it's not stable but that's also why I suggested we play it conservative until composer matures. That is all.

Seldaek commented Apr 19, 2012

@till as I said on IRC after answering (but I guess you missed it) - I probably overreacted a bit, sorry about that :) Anyway I don't know about hackaton, but I'll be at phpDay with david and helgi at least, if you could make it too it'd be great, but if things haven't progressed by then we can at least have a chat.


till commented Apr 19, 2012

Fine. :D

Where is phpDay? Isn't everyday a PHP day? ;)

Seldaek commented Apr 19, 2012

http://2012.phpday.it/ - Verona, italy

CloCkWeRX added a commit that referenced this pull request Apr 21, 2012

Merge pull request #1 from RobLoach/master
Composer support for Console_Color

@CloCkWeRX CloCkWeRX merged commit d63584f into pear:master Apr 21, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment