On Wed, May 25, 2011 at 1:19 AM, Jeffrey Thalhammer <j...@imaginative-software.com> wrote: > I realize this doesn't solve the "big" problem of automatically building a > particular CPAN mirror with a magical mix modules. But based on my own > development patterns, I think this model could provide a workable framework > for organically evolving application dependencies, while providing a stable > and reproducible dependency stack at the same time.
I hadn't quite taken it that far in my thinking, but I'm glad to have a use case to consider as I work. My mental model to date has been along these lines: * You're working off a particular version of perl (/opt/perl/5.XX/) which has no site_lib modules installed * Modules you're adding as dependencies get installed into your local::lib (possibly per application, if you need that separation) * When you're done with your application, you tar it up and inject it into a repository that can be accessed via a URL * You add your tarball to a "local+BackPAN" index (local supersedes BackPAN) * You run the dependency analysis tool against your tarball, using the perl as a base and using the local+BackPAN to resolve dependencies. * Tool spits out the ordered list of tarballs (probably as URLs) needed to install the application If you need to patch a module from CPAN, you treat it just like an app, publish locally and add it to the local index. To deploy, on some other machine, you run a deployment tool against the matching perl on that machine, giving it the ordered list of URLs. For instances where you might have App A and App B, the tool should be able to factor out a common set of dependencies, which could be deployed separately. Then with the right ordering of library paths, you could have App A use version X of a module, while App B uses version Y of a module and otherwise, they use a common set of modules. I hadn't considered the team development case much. My snap reaction is that you would regularly "deploy" to a shared development library path rather than install modules to a personal local::lib during development. As long as the local+BackPAN index can reverse your dependency (module name and version) to the right tarball (including locally patched ones), it all should just work. My though is to write a separate tool for this rather than try to make it work with either M::B or dzil. -- David
