Composer support for Console_Color

[RobLoach]

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]

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]

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]

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]

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

[Seldaek]

@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]

On Wed, Apr 18, 2012 at 2:30 PM, Markus Tacker <
reply@reply.github.com

wrote:

@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.

Unfortunately
https://github.com/pyrus/Pyrus/blob/master/src/Pyrus/PackageFile/v2.php
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
tool.

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]

@Seldaek

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.

and

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
  feasible?)
• 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]

@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]

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]

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.

[davidcoallier]

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]

@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]

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.

[davidcoallier]

@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]

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

[till]

@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]

@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.

[davidcoallier]

@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]

@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]

@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]

Fine. :D

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

[Seldaek]

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