On May 20, 2011, at 11:04 AM, Jeffrey Thalhammer wrote: > I'm not attempting to build an all-encompasing dependency management system. > I've tried to avoid thinking about it in terms of CPAN as we know it, since > in theory, that is an implementation detail. But in practice, I'm will > stipulate that a "dependency" is just a Perl module in some CPAN repository.
Yeah, that's what's confusing me. To me, a "dependency" is a Perl module in some CPAN repository that the module I'm trying to install right now depends on. That is, it's listed in in the "prereqs" section of a META.json file. > The trouble with CPANs is that they are a moving target -- modules are > constantly updated, added, and removed[1]. This creates problems for > developers that want to use the CPAN tool chain, but need to have a stable > set of dependencies. At the same time, they need flexibility to evolve those > dependencies in a systematic way. Well, the new version spec in CPAN Meta Spec 2.0 helps with this. You can specify very precise requirements. > Thanks for bringing PGXN to my attention. The architecture is very similar > to what I was thinking. I will dig deeper to see if we can leverage PGXN. > > [1] I think a lot of this trouble would go away if the CPAN tool chain simply > permitted authors to express precisely which $VERSION of something they > require. So I have to wonder if that is the right place to focus, rather > than building something on top of the tool chain. You can. http://search.cpan.org/~dagolden/CPAN-Meta-2.110930/lib/CPAN/Meta/Spec.pm#Version_Ranges Best, David
