After my last post, and having discovered that The Enlightened Perl Organisation/EPO were in fact attempting to do part of what I described, I joined up to help them herd cats. So now I'm part of the Extended Core Working Group. Has a fancy name doesn't it?
Enlightened Perl is about improving the public face of Perl, and thus encouraging companies to use it.
They have a Wiki, which doesn't have terribly much on it yet. What it does have is a list of Issues, which I read, and then tweaked a bit. The item that stuck out the most to me, was the one about CPAN not being a good tool for seasoned professionals (or in general). Why not, and why CPANPLUS isn't either, wasn't mentioned. So here's my guess as to the reasons, and some ideas for ways of solving it.
CPAN and CPANPLUS do their jobs pretty well, however those jobs are quite Perl-centric. They just build and install Perl modules and their Perl dependencies. I think what we need is something that integrates better with existing package management systems (e.g. dpkg, rpm, emerge).
Before you say "But CPANPLUS has a thingy to build .deb files!" keep listening.. I said to James, "How well do you know aptitude" and from there we discussed for an hour or so.
My initial idea was that what we need is a tool that is similar to aptitude, in that it would visually display the available packages, their dependencies and so on. The thing would then install the module, AND interact with the actual package management system of whatever OS it was on, and convince it that that module was installed. It would need several backends, for dpkg, rpm and so on.
As for figuring out actual real dependencies, for example XML::LibXML requires libxml to be installed, the tool maintainers would initially run their own CPAN server, and enhance the META.yaml or packages files to contain this info.
James however had a much better idea for the frontend. Instead of writing our own frontend, it would be saner to have the server serve the appropriate types of packages for various package managers. E.g. for dpkg, a service that can be added to /etc/apt/sources.list. And if necessary, build packages on the fly, for requested modules.
It would probably be easier to start with a subset of CPAN distributions, say for example, the one that EPO-EC decides to support.
Contribute and/or discuss (This is a Kwiki, for spam avoidance, please enter the page token 'TC' to actually edit the page)
Last modified: 2013-05-19T02:28:53