Hi, On 01/27/2012 04:22 PM, jcbollinger wrote: > From a usability perspective, I think this is a far better proposal > than anything else on the table:
I've thought of another plus. Even though the design proposal adds to the DSL (and complexity is generally to be avoided), it does so in a manner that will not make it necessary for novices (or any end user) to deal with the particular featureset, but instead limits its target audience to developers of public modules. >> Wouldn't this put an end to self-contained modules? > > No. What makes you think it would? I think it allows modules to be > *more* self-contained than they currently are. I was thinking along the lines of "currently modules will just install the packages they need", for instance. But you're right of course - currently modules can break each other because of this, so a way for the compiler to clearly pinpoint reasons and locations of mismatches would indeed be superior. > I do not mean to say that a tool that automatically downloaded and > installed modules from the Forge would be useless -- far from it. I > just don't think that it would adequately address the inter-module > dependency issue, and therefore I would recommend that such a tool not > even try to do so. It solves an altogether different problem. Again, I'm inclined to concur. The issue at hand is to stop modules from breaking each other horribly. Once that's off the table, a module management system is a whole new issue in and of itself. Cheers, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
