On Fri, May 20, 2011 at 11:04:24AM -0700, Jeffrey Thalhammer wrote:
> The trouble with CPANs is that they are a moving target -- modules are
> constantly updated, added, and removed[1].
http://cp2010-05an.barnyard.co.uk/ and all its date/time-stamped friends
and relations aren't.
A feature I ke
On May 20, 2011, at 8:29 AM, Leo Lapworth wrote:
> http://beta.metacpan.org/
> https://github.com/szabgab/CPAN-Digger
Thanks! MetaCPAN and CPAN::Digger are definitely part of the picture. But I
see these more as adjunct features of a private CPAN. I think the meat of the
problem lies in ho
On May 20, 2011, at 8:07 AM, David E. Wheeler wrote:
> HTH, sorry I get a bit lost with some of your questions.
No, this is very helpful. I think you've shown that I need to take a step back
and look at the underlying problem.
I'm not attempting to build an all-encompasing dependency managem
Hi Jeffrey,
On 20 May 2011 08:51, Jeffrey Thalhammer wrote:
> 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
>
On May 20, 2011, at 3:51 AM, Jeffrey Thalhammer wrote:
> 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,
> turnke
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 co
