Darkpan => CPAN Service (part two)

A few months ago, when discussing how to support the 'darkpan' (what Perl programmers call the vast body of perl code floating around the internet or in private companies that we know nothing about) I suggested leveraging the vast CPAN distribution system as a sort of continuous integration/build service which we could offer as a for pay service to companies using Perl.  This would have the dual benefit of encouraging corporations to package up their perl code properly (ie as  CPAN module with a Makefile.PL, etc) and could help raise money to sponser Perl development.

What I'm thinking about would be similar to a ruby only service I noticed: http://runcoderun.com

Check that out and let me know what you think.  What kind of services would the 'quasipan' be required to offer in order to entice companies into paying for it?  For example, what do you think of the idea of being able to build a EC2 or other cloud image type from a base OS that intergrate any given set of CPAN and Darkcpan modules?  Like, "I want a virtualbox VM with Perl 5.10.1 on debian with git, postgresql and Catalyst preinstalled, although with my private repo of proprietary code?"

Comments

[martin]

[this is good] The most useful service for DarkPan/CPAN would be to provide a complete timeboxed CPAN snapshot..

[John Napiorkowski]

You mean like a minicpan of current versions to a certain point in time? I guess a build service for that wold not be too hard, but I'm not sure it would meet any particular need, since creating a minicpan is pretty straightforward.http://perlbuzz.com/mechanix/2008/01/make-your-own-mini-cpan.htmlI'd love to hear more about the type of problem you have that you think this could solve. Thanks!

[martin]

[this is good]
Hi John,
Apologies for taking a while to reply..
Imagine
the situation, you've got a webfarm of 5 machines and a dev machine.
Those 5 machines have been added at the rate of one machine every 6
months. Each machine built from live CPAN mirrors ends up having
slightly different versions of CPAN code. Eventually at some point in
time the newest machine you try to build has problems/incompatibilties
with your own in house apps.. (the problem we currently face). e.g. One
of the newer versions of a core module like DBIx::Class simply fails at
runtime somehwere deep within our application.

[John Napiorkowski]

^^ martin: In this case I imagine a situation were a company could pay for a 'frozen' version of cpan that contained known working versions plus their custom code. However my guess is that its better to just keep building against the newest cpan and just try to id and fix problems.Definitely all 6 machines in the above case need to be synced. What I do is build to box one and then rsync to the remaining, including perl local libs.