Hello Elliot, Thanks for the thoughtful dissent. :)
On Fri, Jun 1, 2012 at 8:03 PM, Elliot Shank <p...@galumph.com> wrote: > When the contents of a distro change, dependency-on-a-module continues to > work, whereas a dependency-on-a-distro does not. The thing is, removing a module from a distro generally means breaking backwards compatibility. It may be possible to avoid the compat break if a module gets spun off into a new distro which gets added to the dependency chain of the original, but under most other circumstances simply removing a module is going to cause problems for at least some subset of users -- and therefore it should only be done when the consequences of breaking back compat have been weighed and deemed acceptable. You can take a hard line and say that your users must always use per-module specification because you reserve the right to change the composition of a distro at any time, but there's no way to validate their dependency specs and guarantee that they did so. Some of them are going to get screwed. Mandatory per-module dependency specification is conceptully flawed in any case simply due to existence of distros with very large numbers of modules. If you depend on a big suite like Moose, Catalyst::Runtime or Lucy, should you be required to specify each class from them that you use? That's going to be tedious and error prone. (Are you *sure* that you listed every last module that you need?) But then if you relax the requirements and allow per-distro dependency specification for big suites, where do you draw the line and start requiring per-module dependency spec for distros that insist on the freedom to drop a module at any moment? Marvin Humphrey
