On Jun 3, 3:44 am, Daniel Pittman <[email protected]> wrote: > On Thu, Jun 2, 2011 at 10:42, James Turnbull <[email protected]> wrote: > > Daniel Pittman wrote: > >> On Thu, Jun 2, 2011 at 10:09, Jacob Helwig <[email protected]> wrote: > > >>> Just my personal opinion: I think we're actually better off > >>> implementing #4113[2] in the long-run. > > >> When I spoke to Luke about those options, his expectation would be > >> that this was a single parameter on the package type, which would take > >> a set of boolean options. You could add a little language to that > >> (like, say, the environment) that allowed options with arguments to be > >> passed, and let each provider parse it themselves, but ... that sounds > >> like an invitation to unmanageable data to me. > > >> In solving that I would strongly encourage you to address additional > >> per-provider top level parameters and properties available, rather > >> than just packing complex data into strings. > > > +1 - plus what Daniel said. > > I should clarify: I think that options, as Luke described them, do > solve some genuine problems and might well be valuable in and of > themselves. I just don't want to see 'proxy=...', or worse, > 'enablerepo=foo,bar,baz' packed into them. >
Hello, >From reading this thread it seems as though most people seem to think #4113 is the way to go. It would probably be wise to then close 2247 if this is the case. I may throw my 2c into the 4113 ticket then. I may have a crack at that one instead, however my ruby learning is just beginning so it may be out of my scope for a while. Nathan -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
