develooper Front page | perl.qa | Postings from May 2011

RFC: Private CPAN In A Box

Thread Next
From:
Jeffrey Thalhammer
Date:
May 20, 2011 00:51
Subject:
RFC: Private CPAN In A Box
Message ID:
5532852A-231C-4BDB-AD5B-C4D3B4FEC365@imaginative-software.com
NOTE: This was also posted on perlmonks at http://perlmonks.org/?node_id=905878.  I'm trying to reach a wide audience, so I'm posting it here too.

Over the last few years, I've helped build private CPANs (DarkPANs or DPANs as brian d foy calls them) for 3 different organizations. Each time I cobbled together some combination of different CPAN::Site, CPAN::Mini::Inject and CPAN modules with various shell scripts, commit hooks, and cron jobs. Although they were generally effective, I feel they were clunky, highly specialized, and hard to maintain.

Once again, I'm faced with building another private CPAN. But this time, I have an opportunity to build something that could have broader appeal in the Perl community.  In fact, the explicit goal is to produce an open source, turnkey framework for creating, deploying, and maintaining a private CPAN.

So with that in mind, I'm looking for feedback on what you might want from such a framework. Here are some questions I've been asking myself -- hopefully they will help stir your mind:

How would it provide an identifiable & reproducible stack of dependencies that developers can use to write, test, and deploy their code against?
How would it allow one to define and deliver a standardized set of dependencies to all your environments?
How would it enable developers to experiment with dependencies that are not part of the standard environment?
How would it enable different teams to work against different versions of their dependencies?
How would it enable teams to independently upgrade, add, and remove their dependencies in a controlled, reproducible manner?
How would teams use it to distribute and share their own modules and applications within the organization?
Which parts of the larger CPAN ecosystem would be most valuable in a private CPAN (e.g. CPAN Testers, AnnoCPAN, search.cpan.org, CPAN Ratings)?
How would one migrate their legacy code into CPAN-style distributions?
How would one migrate from their existing dependency management infrastructure to a private CPAN?
How might one want incorporate a private CPAN with their other development infrastructure, such as bug trackers & continuous integration servers?
Thanks for sharing your thoughts!

-Jef







Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About