On Mon, Dec 16, 2013 at 11:06 AM, Andy Parker <[email protected]> wrote: > > <quote Jeff> > I'd really like configuration information, which is basically what command > line options are, to be read from the environment. This isn't to say that > the environment is the only place, just that it MUST be supported. This > will enable subcommands to work well in stateless environments like Heroku, > Docker, etc... > > This has worked very well for Heroku applications and is specifically > called out in documentation on the subject, such as the 12 Factor App > http://12factor.net/config > </quote> >
Just a point of clarification, I mean "MUST" in the RFC style of MAY/SHOULD/MUST requirements specification, not in the sense that I'm trying to dictate anything. So, configuration information would be required to be looked up in the environment in addition to other sources. > I think that some sort of synthesis of those two concerns/suggestions > might get to something that would be a) powerful for configuring, b) robust > in the face of future changes to puppet and subcomands, and c) > understandable to users of the system where command line args and > environment variables just "do the right thing". > > I'm however having a little trouble with exactly what it might be. Any > thoughts? > I've had really good luck with a two-pass command line option parser in my own little "toy" sub commands. The form would look like: puppet [global options] subcommand [subcommand options] At the implementation layer, all global options are guarnteed to be fully resolved by the time subcommand options are parsed. The way both of these are resolved is by walking the precedence list and using the first one that's defined: 1: Value specified as a command line option. 2: Value specified as an environment variable. 3: Value specified in a configuration file. 4: Default value located in the code. If we require that no subcommand option conflicts the name of a global option, would this give us what we need? While we have a ton of options and specifying all of them as environment variables might over-flow the environment, in practice only a handful of options after vary from one context to another so I doubt we'd exceed the capacity of the environment. -- *Jeff McCune <http://jeffmccune.com/>* -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAOXx1vHHJy-8NjZz12vrpaR-%2Bo6FV9%2BSVaVLXRoDU-%2Be3RG2Kw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
