If the method signature was changed it could make possible a pattern
(with the addition of plumbing in Puppet::Provider and
Puppet::Provider::Command) such as
:commands => [ 'powershell.exe', [ ENV['PATH'],
'C:\Windows\System32\Powershell1.0' ] ]
BUT, and thanks to the powershell exec provider, I found a totally
usable pattern:
commands :powershell =>
if
File.exists?("#{ENV['SYSTEMROOT']}\\sysnative\\WindowsPowershell\\v1.0\\powershell.exe")
"#{ENV['SYSTEMROOT']}\\sysnative\\WindowsPowershell\\v1.0\\powershell.exe"
elsif
File.exists?("#{ENV['SYSTEMROOT']}\\system32\\WindowsPowershell\\v1.0\\powershell.exe")
"#{ENV['SYSTEMROOT']}\\system32\\WindowsPowershell\\v1.0\\powershell.exe"
else
'powershell.exe'
end
That pattern will suffice perfectly well for me. Setting the puppet
agent path is a pretty flexible technique (I didn't realize there was a
puppet.conf knob for it until your responses) but as a module writer, I
don't want to tell users they have to change their puppet.conf path for
very common path cases.
Thanks for all of your responses, you definitely triggered me finding a
way to help myself,
Jeff
On 12/12/2013 01:03 PM, Andy Parker wrote:
On Thu, Dec 12, 2013 at 8:31 AM, Jeff McCune <[email protected]
<mailto:[email protected]>> wrote:
On Thu, Dec 12, 2013 at 8:26 AM, Jeff Bachtel
<[email protected]
<mailto:[email protected]>> wrote:
(repost from puppet-users)
When creating a provider that uses a command not in PATH, what
is the best-practice pattern for case'ing out different
potential locations? As an example, the puppetlabs rabbitmq
pupmod has a rabbitmqplugins provider that falls down on
CentOS using the rabbitmq upstream package due to
rabbitmq-plugins being in /usr/lib/rabbitmq/bin .
As an aside (I don't know how often Puppet devs read this
list), could the Puppet::Util::which method perhaps be
extended to add a non-user PATH-like variable to the path
search string? Something like PUPPET_PROVIDER_PATH, if it
exists, being concatenated before PATH. I could then configure
the system environment on weird hosts to provide that variable
for puppet without mucking with user/system PATH.
It seems reasonable to modify which() [1] to take an optional PATH
instead of hard-coding it to ENV['PATH']. The method depends on
PATH, so it's probably a bit "better" to inject that dependency
rather than hardcode it in the method body as it is now.
Maybe def which(bin, path=ENV['PATH']) ?
I'm not sure if changing the method signature would achieve what Jeff
B is asking for. If I'm understanding this right the problem is that
the PATH doesn't contain the executables that the providers need and
so `which` isn't finding the executables and the provider then isn't
available on the platform. If that is the case, then trying to
hardcode other paths in the provider implementation would be difficult
to maintain since it could be very different on every platform, and so
trying to specify a new argument to which won't solve this problem.
I think the suggestion is to create a PUPPET_PROVIDER_PATH that which
(or at least the provider system) always uses to search, but at that
point why not just modify the PATH environment variable that puppet is
running with?
https://github.com/puppetlabs/puppet/blob/780ecb238d47f1ab5d6ce18fc8e38f98a12d66c0/lib/puppet/util.rb#L178
--
*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]
<mailto:puppet-dev%[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CAOXx1vG0cvcir-H93_icz54WzawsPwOGr0Mcb2%2BirA%3D_i%3D7bJA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Andrew Parker
[email protected] <mailto:[email protected]>
Freenode: zaphod42
Twitter: @aparker42
Software Developer
*Join us at PuppetConf 2014, September 23-24 in San Francisco*
--
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/CANhgQXuQQK80Ju%2B0BDnzhoBOVmjER6XMNM2sWQZJw1DSYCkdpg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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/52AA09BB.3020900%40bericotechnologies.com.
For more options, visit https://groups.google.com/groups/opt_out.
