Gabor is looking at setting up corporate CPANs. While it doesn’t cover the web interfaces that he wants, brian d foy has been working on MyCPAN::Indexer and MyCPAN::App::DPAN.
The former has been in progress for a while as part of brian’s BackPAN indexing work. The latter is a more recent effort at creating a tool for managing CPAN-like repositories. It can copy archives into a repository and update the standard index files. It’s being used on a daily basis on both Windows and Linux to maintain a single DarkPAN at present, and, once some more work on automated building of Perl distributions under TeamCity is done, will be used for maintaining a lot more private repositories.
The way that a repository is updated is to have a copy of it checked out of Subversion, put the distribution archive in place, run dpan on it to update the indexes, and check in the result. CPAN.pm can be pointed at the Subversion HTTP URL and use it just as if it were one of the public CPAN mirrors. (Though of course, the DarkPAN repository has a restricted set of distributions in it, not even a mini-CPAN.)
I’m setting up a DarkPAN at work.
CPAN::Site does most of what I want with maintaining it. Unfortunately, it has some bugs with parsing module versions (in particular Test::Object, which is a blocker for PPI); in particular, it can’t distinguish between namespace declarations in actual code and in code examples in documentation. I thought that it could be worked around, but in reading source, it’s doing some pretty incredible stuff.
It’s reading perl code straight out of raw tar files. It ungzips the tarballs, but doesn’t untar them. It simply tries to find perl code in the middle of the tar stream and grab the versions out that. Yech.
So, looks like I’m going to be forced to go back to CPAN::Mini::Inject, taking advantage of parse_version() in ExtUtils::MakeMaker. I’m going to have to have a look at brian d foy’s MyCPAN::Indexer work.