> While we are leaning toward a config-file driven approach, we would be > interested in hearing of any specific use cases you may know of where this > may be insufficient. We would specifically be interested in any use cases > which suggest that some affordance in the design should be made to allow for > some (or all?) variables seen by Ruby code to be drawn from the actual shell > environment, as opposed to just a configuration file.
Might be clutching at straws here, but there might be a case for something like http_proxy (which is a reasonably common convention) in a closed environment that requires it, to be just passed through, versus defining it also in another configuration file again. That kind of environment var is _sometimes_ set globally to avoid configuring the proxy config in all the different clients/services that a *nix box has. I think Net::HTTP honors this environment variable for example, so this might apply to some functions that make outbound http calls. Of course, I'd rather here what the community has to say about this. Maybe users would prefer to manage this more precisely instead of globally anyway from a puppetserver/function perspective. ken. -- 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAE4bNT%3D%3Dd5GBdA1jTx97Xrd7pP6mZi-RMGgq%2BF0v_ZtO_MOKkw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
