Issue #13284 has been updated by Chris Price.
So, I didn't quite investigate this enough to come up with a final proposal but here is where I was leaning: First, I think there are 2 different use cases worth considering (as discussed with Daniel above). The first would be a way to register environment variables on a per-command-definition basis, and the second would be a way to specify them on a per-command-execution basis. For per-command-definition: --------------------------- There is a slight complication as far as API for this is concerned, because of the fact that the existing method for registering a command is via "Provider#commands(hash)", where "hash" is interpreted pretty strictly as string-string key/values (key = name of new meta-method to define, value = executable path or name). In an ideal world we'd simply extend this method signature to support passing the environment vars, but in this case it's tricky because the #1 most important thing is not to break backwards compatibility. Therefore I see two options: 1. add a supplemental method called "command_env" or something, that accepts a command name (symbol) and a hash of environment vars... this is a bummer because it requires an extra method call when registering the command, but it still seems like probably the better choice to me. 2. modify the implementation of "Provider#commands(hash)" so that it interprets the hash argument a little differently. Basically, you could allow the values in the hash to be either strings (in which case you carry out the current behavior) or hashes. If you find a hash there, then you can look inside of it for, e.g., :command and :env. The advantage of this option is that we don't have to introduce a new method, but the disadvantage is that it relies on dynamic typing and will likely result in messier, less maintanable code. ---------------------------------------- Bug #13284: MacPorts provider needs to set HOME while running `port` command. https://projects.puppetlabs.com/issues/13284#change-58014 Author: Daniel Pittman Status: Investigating Priority: Normal Assignee: Chris Price Category: executables Target version: Telly Affected Puppet version: development Keywords: Branch: In [commit e44a8abd7dc7b2cac4c05eb7a50b53bdd71a1cbc][commit] the `HOME`, `USER`, and `LOGNAME` environment variables were set to be removed by default during the execution of external commands. This is generally a good idea, because those are inherited by default from the user who Puppet starts running as, and can be quite misleading if we change user ID - as we commonly do to execute external commands, and on the master. One limitation of this is that the MacPorts provider needs to set HOME to something during invocation, or we run into the error: 1) Package provider macports should be able to get a list of existing packages Failure/Error: provider.instances.each do |package| Puppet::ExecutionFailure: Execution of '/opt/local/bin/port -q installed' returned 1: usage: cut -b list [-n] [file ...] cut -c list [file ...] cut -f list [-s] [-d delim] [file ...] while executing "exec dscl -q . -read /Users/[exec id -un] NFSHomeDirectory | cut -d ' ' -f 2" (procedure "mportinit" line 95) invoked from within "mportinit ui_options global_options global_variations" Error: /opt/local/bin/port: Failed to initialize MacPorts, usage: cut -b list [-n] [file ...] cut -c list [file ...] cut -f list [-s] [-d delim] [file ...] # ./lib/puppet/util/execution.rb:135:in `execute' # ./lib/puppet/util.rb:476:in `execute' # ./lib/puppet/provider.rb:122:in `port' # ./lib/puppet/provider/package/macports.rb:49:in `instances' # ./spec/integration/provider/package_spec.rb:37 Setting `HOME` to `/opt/local` is a good choice, especially since the MacPorts provider only supports the default install location by design. Unfortunately, the `commands` mechanism that is part of the provider interface doesn't allow access to the environment - which it should, since this will not be the final command to require that treatment. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs?hl=en.
