(I had a big response going to various details of this thread, and then realized that from Plumage's perspective, the details don't actually matter much; see the more general email below.)
On Mon, 2010-01-04 at 10:45 -0500, Jesse Vincent wrote: > This brings us to "How do we get there from here?" Who are the folks > working on the Perl6 CPAN client? Well ... that's an interesting story. I'm lead developer for Plumage, the Parrot module ecosystem. Whether or not Rakudo chooses to promote it, Plumage will be available as a client, a set of modules for interacting with the ecosystem at large, and a metadata standard. (The online copy of which is out of date WRT my brain -- hopefully I can get that updated soonish.) Plumage wants to see every other module ecosystem as an API to query; systems that don't natively export an API will get wrapped by a library of ugly hacks if need be. For obvious reasons, ecosystems that *do* provide a nice API and/or metadata export facilities will get earliest and best support. :-) However, Plumage is not the only game in town, not least of which because the current implementation requires Parrot, and the larger Perl 6 community doesn't want that requirement. masak++ and mberends++ have been working on 'proto', which last I looked was Rakudo-specific but I think more as an accident of history than a planned restriction. proto however was always meant to be "the one we threw away", so it may be replaced in at least the Rakudo space by Plumage. That however leaves the non-Rakudo Perl 6 implementations with no standard install client for pure Perl 6 (or otherwise cross-implementation) modules. It could be that Plumage expands to support that space, or a workalike written in pure Perl 6 takes over, or a cpan variant does. In any case, Plumage will continue to exist alongside whatever tool gets used by the broader Perl 6 community, because it's currently the only game in town for Parrot-compatible cross-language installation. Thus my main concern is that whatever the CPAN community creates, there be sane metadata standards and an easy API to work and grow with. -'f