The problem is that there is no way for a single application to use multiple versions of a module. So it's easy to imagine that very specific module prereqs could be in conflict and require manual override. That's not the right answer.
What we need is application level dependencies that are specific and non conflicting and then to make it easy to install into app specific lib directories. That's what im On May 23, 2011 5:22 PM, "David E. Wheeler" <da...@kineticode.com> wrote: > 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 > >
