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 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. As I see it, there are two sides to the problem. The first is creating tools for creating, managing, and using a private CPAN repository. There is already a lot of prior art for this, but I feel that it is fragmented. So this might just be a matter of assembling the right combination of existing technologies. The second (and probably more difficult) side is establishing patterns for using these tools, which enable developers to write, test, and deploy their code against an identifiable and reproducible set of dependencies. I acknowledge that one size will not fit all, but I strongly believe there is (or should be) some common ground here. 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. 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. Jeffrey Thalhammer Imaginative Software Systems vcard: http://www.imaginative-software.com/contact/jeff.vcf
