Jira (PUP-6134) Unable to install a Ruby gem to non-Puppet Ruby stack using the package resource type on Windows

46 views
Skip to first unread message

Nate McCurdy (JIRA)

unread,
Apr 6, 2016, 7:46:04 PM4/6/16
to puppe...@googlegroups.com
Nate McCurdy created an issue
 
Puppet / Bug PUP-6134
Unable to install a Ruby gem to non-Puppet Ruby stack using the package resource type on Windows
Issue Type: Bug Bug
Affects Versions: PUP 4.3.2
Assignee: Unassigned
Components: Windows
Created: 2016/04/06 4:45 PM
Priority: Normal Normal
Reporter: Nate McCurdy

Puppet is unable to install a Ruby gem into anything other than Puppet's Ruby stack on Windows nodes.

Example of the issue

For example, say I want to install the puppet-lint gem so that I can validate Puppet code while writing modules. Normally, I'd install Ruby from http://rubyinstaller.org/ then run gem install puppet-lint. But, let's say I wanted to automate that process using Puppet! First, I would install Chocolatey then use Chocolatey to install Ruby:

include chocolatey
 
package { 'ruby':
 
  ensure   => present,
 
  provider => 'chocolatey',
 
  require  => Class['chocolatey'],
 
}

Then I'd use the gem provider to install puppet-lint:

package { 'puppet-lint':
 
  ensure   => present,
 
  provider => 'gem',
 
  require  => Package['ruby'],
 
}

After doing this, the puppet-lint executable is not available in %PATH%, and gem list doesn't show puppet-lint as installed:

C:\Users\Administrator>puppet-lint
 
'puppet-lint' is not recognized as an internal or external command,
 
operable program or batch file.
 
C:\Users\Administrator>gem list
 
 
 
*** LOCAL GEMS ***
 
 
 
bigdecimal (1.2.6)
 
io-console (0.4.3)
 
json (1.8.1)
 
minitest (5.4.3)
 
power_assert (0.2.2)
 
psych (2.0.8)
 
rake (10.4.2)
 
rdoc (4.2.0)
 
test-unit (3.0.8)
 
 
 
C:\Users\Administrator>

But, if I use's Puppet's gem command, I see that puppet-lint got installed into Puppet's Ruby stack:

C:\Users\Administrator>"C:\Program Files\Puppet Labs\Puppet\sys\ruby\bin\gem.bat" list
 
 
 
*** LOCAL GEMS ***
 
 
 
bigdecimal (1.2.4)
 
deep_merge (1.0.1)
 
ffi (1.9.10 x64-mingw32)
 
io-console (0.4.3, 0.4.2)
 
json (1.8.1)
 
minitar (0.5.4)
 
minitest (4.7.5)
 
psych (2.0.5)
 
puppet-lint (1.1.0)
 
rake (10.1.0)
 
rdoc (4.1.0)
 
stomp (1.3.3)
 
test-unit (2.1.8.0, 2.1.7.0, 2.1.6.0, 2.1.5.0)
 
win32-dir (0.4.9)
 
win32-eventlog (0.6.2)
 
win32-process (0.7.4)
 
win32-security (0.2.5)
 
win32-service (0.8.6)

Likely Cause

Puppet is putting its bin directory at the start of %PATH% during all invocations of puppet, which causes the gem provider to find Puppet's gem command rather than the gem command I installed via chocolatey.
This is happening in environment.bat which puppet.bat always invokes:

...
 
SET PATH=%PUPPET_DIR%\bin;%FACTERDIR%\bin;%HIERA_DIR%\bin;%MCOLLECTIVE_DIR%\bin;%PL_BASEDIR%\bin;%PL_BASEDIR%\sys\ruby\bin;%PL_BASEDIR%\sys\tools\bin;%PATH%
 
...

On the command line, I can install gems into my Ruby stack from Chocolatey without issue:

C:\Users\Administrator>where gem
 
C:\tools\ruby22\bin\gem
 
C:\tools\ruby22\bin\gem.bat
 
 
 
C:\Users\Administrator>gem install gist
 
Fetching: gist-4.5.0.gem (100%)
 
Successfully installed gist-4.5.0
 
Parsing documentation for gist-4.5.0
 
Installing ri documentation for gist-4.5.0
 
Done installing documentation for gist after 0 seconds
 
1 gem installed
 
 
 
C:\Users\Administrator>gem list --local
 
 
 
*** LOCAL GEMS ***
 
 
 
bigdecimal (1.2.6)
 
gist (4.5.0)
 
io-console (0.4.3)
 
json (1.8.1)
 
minitest (5.4.3)
 
power_assert (0.2.2)
 
psych (2.0.8)
 
rake (10.4.2)
 
rdoc (4.2.0)
 
test-unit (3.0.8)

But when Puppet runs, the %PATH% gets re-written to have Puppet's BIN dir at the start:

C:\Users\Administrator>echo %PATH%
 
C:\ProgramData\chocolatey\bin;C:\tools\ruby22\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\Git\bin;C:\Program Files\Puppet Labs\Puppet\bin
 
 
 
C:\Users\Administrator>puppet apply -e "notice($::path)"
 
Notice: Scope(Class[main]): C:/Program Files/Puppet Labs/Puppet/facter/bin;C:\Program Files\Puppet Labs\Puppet\puppet\bin;C:\Program Files\Puppet Labs\Puppet\facter\bin;C:\Program Files\Puppet Labs\Puppet\hiera\bin;C:\Program Files\Puppet Labs\Puppet\mcollective\bin;C:\Program Files\Puppet Labs\Puppet\bin;C:\Program Files\Puppet Labs\Puppet\sys\ruby\bin;C:\Progr
 
am Files\Puppet Labs\Puppet\sys\tools\bin;C:\ProgramData\chocolatey\bin;C:\tools\ruby22\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\Git\bin;C:\Program Files\Puppet Labs\Puppet\bin
 
Notice: Compiled catalog for pe-201533-agent-win2012 in environment production in 0.03 seconds
 
Notice: Applied catalog in 0.09 seconds

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Atlassian logo

Henrik Lindberg (JIRA)

unread,
Apr 6, 2016, 7:55:03 PM4/6/16
to puppe...@googlegroups.com
Henrik Lindberg updated an issue
Change By: Henrik Lindberg
Scrum Team: Windows

Nate McCurdy (JIRA)

unread,
Apr 6, 2016, 7:55:03 PM4/6/16
to puppe...@googlegroups.com
Nate McCurdy updated an issue
Change By: Nate McCurdy
Puppet is unable to install a Ruby gem into anything other than Puppet's Ruby stack on Windows nodes.

h2. Example of the issue
For example, say I want to install the {{puppet-lint}} gem so that I can validate Puppet code while writing modules. Normally, I'd install Ruby from http://rubyinstaller.org/ then run {{gem install puppet-lint}}. But, let's say I wanted to automate that process using Puppet! First, I would install Chocolatey then use Chocolatey to install Ruby:
{code}

include chocolatey
package { 'ruby':
  ensure   => present,
  provider => 'chocolatey',
  require  => Class['chocolatey'],
}
{code}


Then I'd use the gem provider to install puppet-lint:
{code}

package { 'puppet-lint':
  ensure   => present,
  provider => 'gem',
  require  => Package['ruby'],
}
{code}

 A {{--debug}} log of that package installation looks like this:
{code}
C:\Users\Administrator>puppet resource package puppet-lint ensure=present provider=gem --debug
(... removing Facter resolution messages ...)
Debug: /Package[puppet-lint]: Provider gem does not support features virtual_packages; not managing attribute allow_virtual
Debug: Loaded state in 0.03 seconds
Debug: Evicting cache entry for environment 'production'
Debug: Caching environment 'production' (ttl = 0 sec)
Debug: Evicting cache entry for environment 'production'
Debug: Caching environment 'production' (ttl = 0 sec)
Debug: Evicting cache entry for environment 'production'
Debug: Caching environment 'production' (ttl = 0 sec)
Debug: Evicting cache entry for environment 'production'
Debug: Caching environment 'production' (ttl = 0 sec)
Debug: Failed to load library 'selinux' for feature 'selinux'
Debug: Prefetching gem resources for package
Debug: Executing: 'C:/Program Files/Puppet Labs/Puppet/sys/ruby/bin/gem.bat list --local'
Debug: Finishing transaction 39019400
Debug: Storing state
Debug: Stored state in 0.05 seconds
package { 'puppet-lint':
  ensure => ['1.1.0'],
}
{code}
After doing this, the {{puppet-lint}} executable is not available in %PATH%, and {{gem list}} doesn't show puppet-lint as installed:
{code}

C:\Users\Administrator>puppet-lint
'puppet-lint' is not recognized as an internal or external command,
operable program or batch file.
C:\Users\Administrator>gem list

*** LOCAL GEMS ***

bigdecimal (1.2.6)
io-console (0.4.3)
json (1.8.1)
minitest (5.4.3)
power_assert (0.2.2)
psych (2.0.8)
rake (10.4.2)
rdoc (4.2.0)
test-unit (3.0.8)

C:\Users\Administrator>
{code}

*But*, if I use's Puppet's {{gem}} command, I see that puppet-lint got installed into Puppet's Ruby stack:
{code}

C:\Users\Administrator>"C:\Program Files\Puppet Labs\Puppet\sys\ruby\bin\gem.bat" list

*** LOCAL GEMS ***

bigdecimal (1.2.4)
deep_merge (1.0.1)
ffi (1.9.10 x64-mingw32)
io-console (0.4.3, 0.4.2)
json (1.8.1)
minitar (0.5.4)
minitest (4.7.5)
psych (2.0.5)
puppet-lint (1.1.0)
rake (10.1.0)
rdoc (4.1.0)
stomp (1.3.3)
test-unit (2.1.8.0, 2.1.7.0, 2.1.6.0, 2.1.5.0)
win32-dir (0.4.9)
win32-eventlog (0.6.2)
win32-process (0.7.4)
win32-security (0.2.5)
win32-service (0.8.6)
{code}

h2. Likely Cause
Puppet is putting its bin directory at the start of %PATH% during all invocations of {{puppet}}, which causes the {{gem}} provider to find Puppet's gem command rather than the gem command I installed via chocolatey.

This is happening in {{environment.bat}} which {{puppet.bat}} always invokes:
{code}

...
SET PATH=%PUPPET_DIR%\bin;%FACTERDIR%\bin;%HIERA_DIR%\bin;%MCOLLECTIVE_DIR%\bin;%PL_BASEDIR%\bin;%PL_BASEDIR%\sys\ruby\bin;%PL_BASEDIR%\sys\tools\bin;%PATH%
...
{code}


On the command line, I can install gems into my Ruby stack from Chocolatey without issue:
{code}

C:\Users\Administrator>where gem
C:\tools\ruby22\bin\gem
C:\tools\ruby22\bin\gem.bat

C:\Users\Administrator>gem install gist
Fetching: gist-4.5.0.gem (100%)
Successfully installed gist-4.5.0
Parsing documentation for gist-4.5.0
Installing ri documentation for gist-4.5.0
Done installing documentation for gist after 0 seconds
1 gem installed

C:\Users\Administrator>gem list --local

*** LOCAL GEMS ***

bigdecimal (1.2.6)
gist (4.5.0)
io-console (0.4.3)
json (1.8.1)
minitest (5.4.3)
power_assert (0.2.2)
psych (2.0.8)
rake (10.4.2)
rdoc (4.2.0)
test-unit (3.0.8)
{code}


But when Puppet runs, the %PATH% gets re-written to have Puppet's BIN dir at the start:
{code}

C:\Users\Administrator>echo %PATH%
C:\ProgramData\chocolatey\bin;C:\tools\ruby22\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\Git\bin;C:\Program Files\Puppet Labs\Puppet\bin

C:\Users\Administrator>puppet apply -e "notice($::path)"
Notice: Scope(Class[main]): C:/Program Files/Puppet Labs/Puppet/facter/bin;C:\Program Files\Puppet Labs\Puppet\puppet\bin;C:\Program Files\Puppet Labs\Puppet\facter\bin;C:\Program Files\Puppet Labs\Puppet\hiera\bin;C:\Program Files\Puppet Labs\Puppet\mcollective\bin;C:\Program Files\Puppet Labs\Puppet\bin;C:\Program Files\Puppet Labs\Puppet\sys\ruby\bin;C:\Progr
am Files\Puppet Labs\Puppet\sys\tools\bin;C:\ProgramData\chocolatey\bin;C:\tools\ruby22\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\Git\bin;C:\Program Files\Puppet Labs\Puppet\bin
Notice: Compiled catalog for pe-201533-agent-win2012 in environment production in 0.03 seconds
Notice: Applied catalog in 0.09 seconds
{code}

Ethan Brown (JIRA)

unread,
Apr 6, 2016, 8:16:03 PM4/6/16
to puppe...@googlegroups.com
Ethan Brown commented on Bug PUP-6134
 
Re: Unable to install a Ruby gem to non-Puppet Ruby stack using the package resource type on Windows

Typically when customers are performing module development on Windows, there are a couple of options:

  • Use the Ruby vendored with Puppet and avoid dealing with installing / managing Ruby
  • Manually install a Ruby version (or multiples) and manage those by hand. This is essentially what the Windows team does to build / test Puppet code – but note this isn't a scenario where I would recommend using Puppet to manage the system. In other words, it's generally recommended against installing both Puppet and various Ruby runtimes if the intent is to do module development.
  • Furthermore, a local module project should use / manage gems with bundler by specifying dependencies like puppet-lint in a Gemfile specific to the project, and using bundle install --path to segregate the gems - installing a global puppet-lint is not desireable.

So it would be good to get a better sense of:

package { 'puppet-lint':
 
  ensure   => present,
 
  provider => 'gem',
 
  require  => Package['ruby'],
 
  install_options => '-​-install-dir C:\tools\ruby22\lib\ruby\gems --bindir c:\tools\ruby22\bin'
 
}

  • How might you expect this to work if changes were made to the gem package provider?

FWIW - I also don't think that this is a bug.

Ben Ford (JIRA)

unread,
Apr 6, 2016, 9:58:03 PM4/6/16
to puppe...@googlegroups.com
Ben Ford commented on Bug PUP-6134

I think that the choice of gems described may not have been the best. Let's say that the intent was to install minecraftctl so that the logged in user could issue commands to their Minecraft server. On Linux/OSX/whatever, that would be

package { 'minecraftctl':
 
    ensure => present,
 
    provider => gem,
 
}

and on Windows it would be

package { 'minecraftctl':
 
    ensure => present,
 
    provider => gem,
 
    #some weird arbitrary values that some forum said to use. I dunno what they do.
 
    install_options => '-​-install-dir C:\tools\ruby22\lib\ruby\gems --bindir c:\tools\ruby22\bin' 
}

And what happens when the "system" ruby is 2.0 instead of 2.2?

In any case, I think that what Nate McCurdy is suggesting is that Puppet not be the first item in the %PATH. That's all.

Nate McCurdy (JIRA)

unread,
Apr 7, 2016, 1:51:03 PM4/7/16
to puppe...@googlegroups.com
Nate McCurdy commented on Bug PUP-6134

Thanks for the clarification Ben Ford. That's exactly my point.

There are many other reasons that someone would want a gem on their Windows system that have nothing to do with developing Puppet modules. Are we going to tell them to use Puppet's Ruby stack for all of those reasons? If the answer is yes, then that is completely opposite of our answer on the *nix side of things.

The gem provider should ideally function exactly the same or at least have feature parity on all Puppet supported operating systems. In its current state, it does the exact opposite of its description when used on Windows. It does what the puppet_gem provider was made for.

A user should be able to run this Puppet code on any supported OS and expect the same outcome. That is the Puppet way after all.

#  - minecraftctl to interact with a MineCraft server.
 
#  - gist to be able to share code snippets on gist.github.com.
 
#  - github to be able to interact with GitHub's API.
 
#  - colored to be able to add color to fun little Ruby scripts.
 
package { [ 'minecraftctl', 'gist', 'github', 'colored' ] :
 
    ensure   => present,
 
    provider => gem,
 
}

I think that it is absolutely a bug that provider => 'gem' doesn't do on Windows what it does on all other operating systems. From what I can tell, that bug is caused by the fact that Puppet puts its sys/ruby/bin directory at the start of %PATH% during a Puppet run.

Ethan Brown I tried setting install_options, and didn't have any luck at first. The puppet run threw errors that gem was unable to install the Ruby gem, and then it fell back to using Puppet's gem command and installed the Ruby gem into Puppet's Ruby stack:

# gems.pp
 
package { 'colored':
 
  ensure          => present,
 
  provider        => 'gem',
 
  install_options => '--install-dir C:\tools\ruby22\lib\ruby\gems\2.2.0 --bindir c:\tools\ruby22\bin',
 
}


C:\vagrant>puppet apply gems.pp
 
Warning: Facter: skipping external facts for "C:/ProgramData/PuppetLabs/puppet/cache/facts.d": The request is not supported
 
Notice: Compiled catalog for pe-201533-agent-win2012 in environment production in 0.62 seconds
 
Error: Execution of 'C:/Program Files/Puppet Labs/Puppet/sys/ruby/bin/gem.bat install --no-rdoc --no-ri colored "--install-dir C:\tools\ruby22\lib\ruby\gems\2.2.0 --bindir c:\tools\r
 
uby22\bin"' returned 1: ERROR:  While executing gem ... (URI::InvalidURIError)
 
    bad URI(is not URI?): ?gems="--install-dir C:\tools\ruby22\lib\ruby\gems\2.2.0 --bindir c:\tools\ruby22\bin"
 
Successfully installed colored-1.2
 
Error: /Stage[main]/Main/Package[colored]/ensure: change from absent to present failed: Execution of 'C:/Program Files/Puppet Labs/Puppet/sys/ruby/bin/gem.bat install --no-rdoc --no-
 
ri colored "--install-dir C:\tools\ruby22\lib\ruby\gems\2.2.0 --bindir c:\tools\ruby22\bin"' returned 1: ERROR:  While executing gem ... (URI::InvalidURIError)
 
    bad URI(is not URI?): ?gems="--install-dir C:/tools/ruby22/lib/ruby/gems/2.2.0 --bindir c:\tools\ruby22\bin"
 
Successfully installed colored-1.2
 
Notice: Applied catalog in 5.19 seconds

Interestingly, I changed the install_options to a hash, and it worked on Windows and installed the gem into my "system" ruby stack:

package { 'colored':
 
  ensure          => present,
 
  provider        => 'gem',
 
  install_options => {'--install-dir' => 'C:\tools\ruby22\lib\ruby\gems\2.2.0',  '--bindir' => 'c:\tools\ruby22\bin'},
 
}

So, yes, using install_options does result in the desired effect (when used correctly); however, that can't be our answer to the problem for at least three reasons:

  1. What happens if my Ruby version changes? I'll need to update all my Puppet code.
  2. It's tedious to have to path out and add those options.
  3. In *nix, I don't have to add those options because it just does "the right thing". Why does it have to be different for Windows?

Kylo Ginsberg (JIRA)

unread,
Apr 7, 2016, 2:04:04 PM4/7/16
to puppe...@googlegroups.com
Kylo Ginsberg commented on Bug PUP-6134

Are there downsides to modify the .bat files to build a path where puppet's bin directories are at the end of the path?

Offhand it does seem preferable to have Windows use the model on *nix where you can simply select the provider, gem vs puppet_gem rather than tinkering with install_options.

Also, a note that if we make that change we'll also need to update the puppet_gem provider we added in puppet 4, because it's implementation at https://github.com/puppetlabs/puppet/blob/4.4.1/lib/puppet/provider/package/puppet_gem.rb#L9-L13 currently relies on the path being setup as it is, rather than the provider knowing the path to puppet's ruby's gem (as it does on *nix).

Nate McCurdy (JIRA)

unread,
Apr 7, 2016, 3:36:04 PM4/7/16
to puppe...@googlegroups.com
Nate McCurdy commented on Bug PUP-6134

After a bit of testing, realized that this is not idempotent. The gem gets installed on every puppet run.

package { 'colored':
 
  ensure          = present
 
  provider        => 'gem',
 
  install_options => {'--install-dir' => 'C:\tools\ruby22\lib\ruby\gems\2.2.0',  '--bindir' => 'c:\tools\ruby22\bin'},
 
}

The reason for that is because the is state is determined by running C:/Program Files/Puppet Labs/Puppet/sys/ruby/bin/gem.bat list --local ^colored$. So it's searching Puppet's gem list rather than the "system" gem list.

Nate McCurdy (JIRA)

unread,
Apr 21, 2016, 3:20:04 PM4/21/16
to puppe...@googlegroups.com
Nate McCurdy updated an issue
Change By: Nate McCurdy
CS Priority: Needs Priority

Kenaz Kwa (JIRA)

unread,
Aug 29, 2016, 7:47:23 PM8/29/16
to puppe...@googlegroups.com
Kenaz Kwa updated an issue
Change By: Kenaz Kwa
Team: Agent & Platform Support

Ethan Brown (JIRA)

unread,
Jan 4, 2017, 6:10:06 PM1/4/17
to puppe...@googlegroups.com
Ethan Brown commented on Bug PUP-6134
 
Re: Unable to install a Ruby gem to non-Puppet Ruby stack using the package resource type on Windows

I've made some comments on the new PR at https://github.com/puppetlabs/puppet/pull/5460

We can't modify the existing .bat files or there will be breakage.

I'm leaning toward modifying the package type to express a path / command parameter override OR alternatively an environment like exec that allows for complete customization of PATH. Only then would it be easy to install gems in multiple Ruby versions on a system.
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Atlassian logo

Thomas Kishel (JIRA)

unread,
Jan 5, 2017, 4:23:03 PM1/5/17
to puppe...@googlegroups.com
Thomas Kishel commented on Bug PUP-6134

Reviewing our list of package providers, I see two types of providers: single-instance and multiple-instance. For the single-instance providers, such as yum, there

should be only one executable, and it should be in PATH. For multiple-instance providers, such as gem, there could be n-number of instances, each with its own executable and none of them may be in PATH. We recognize this with our puppet_gem provider, which differs from the gem provider only in that it defines an absolute path to :gemcmd (except on Windows).

The provider attribute of a package is, in practice, overloaded as a command attribute: but is an attribute that does not accept an absolute path. An optional command (or to a lesser extent{{environment}} and/or path) attribute for providers, as implemented in the Exec resource type would support multiple-instance providers without requiring a custom provider type for each instance.

So, I agree that an attribute-based solution would be preferable to the PR, which is limited to addressing this issue for one provider on one operating system. Modifying the package type is larger in scope, and may best be executed by someone else, but I'm willing.

Thomas Kishel (JIRA)

unread,
Jan 6, 2017, 6:20:30 PM1/6/17
to puppe...@googlegroups.com
Thomas Kishel commented on Bug PUP-6134

I've updated the pull request that: reverts puppet_gem.rb, defines a new which_without_puppet_paths method in package.rb that reuses the existing which method, and updates gem.rb to use that new method, which is then also available to other package providers. It's a limited set of changes with a limited scope that restores functionality to the gem provider on Windows, and allows time to consider adding attributes to providers.

Implementing attributes to allow multiple-instance packages via an explicit command will require identifying an attribute to maintain uniqueness via a composite uniqueness key. It looks like the command attribute is the best candidate. For example: ['sinatra', 'gem', '/usr/bin/gem'].

Rob Reynolds (JIRA)

unread,
Jan 31, 2017, 8:27:03 PM1/31/17
to puppe...@googlegroups.com
Rob Reynolds updated an issue
 
Change By: Rob Reynolds
Labels: gem package provider windows
Sprint: AP Grooming

Geoff Nichols (JIRA)

unread,
Mar 9, 2017, 5:51:02 PM3/9/17
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Fix Version/s: PUP 6.0.0

Geoff Nichols (JIRA)

unread,
Mar 15, 2017, 2:09:05 PM3/15/17
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Sprint: Agent  Accepted  Grooming

Geoff Nichols (JIRA)

unread,
Mar 15, 2017, 2:14:06 PM3/15/17
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Fix Version/s: PUP 6.0.0
Fix Version/s: PUP 5.y

Geoff Nichols (JIRA)

unread,
Mar 15, 2017, 2:16:04 PM3/15/17
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Acceptance Criteria: - Ability to opt-in to behavior where Puppet's vendored Ruby is not in the PATH. 

John Duarte (JIRA)

unread,
Mar 15, 2017, 2:17:05 PM3/15/17
to puppe...@googlegroups.com
John Duarte updated an issue
Change By: John Duarte
QA Risk Assessment: Automate

Geoff Nichols (JIRA)

unread,
Mar 15, 2017, 2:19:03 PM3/15/17
to puppe...@googlegroups.com
Geoff Nichols assigned an issue to Adam Bottchen
Change By: Geoff Nichols
Assignee: Adam Bottchen

Thomas Kishel (JIRA)

unread,
Mar 15, 2017, 4:14:17 PM3/15/17
to puppe...@googlegroups.com
Thomas Kishel commented on Bug PUP-6134
 
Re: Unable to install a Ruby gem to non-Puppet Ruby stack using the package resource type on Windows

1) The specific issue is that Windows users cannot manage Ruby gems because our Ruby is placed first in the PATH on Windows. The most recent PR (earlier ones overreached) addresses this specific issue with a few lines of code.

2) The general issue is that package providers use 'which' to find the first command (for example, 'gem') specified in code by the provider. This 'first' model prevents managing 'multiple.'

One suggested solution is for users to create a new provider that inherits from the base provider. Creating a new provider (for example: https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/puppet_gem.rb) to specify commands for each instance of a provider seems excessive compared to being able to specify commands via a parameter.

Here's a different/similar case (https://tickets.puppetlabs.com/browse/PUP-6895) where the 'first' model fails (albeit due to an unfortunate choice by a Perl developer to name a command 'pip') that could be resolved by being able to specify the full path of the command as a parameter.

A command parameter could/would need to be used to establish a third level uniqueness key, as per https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/package.rb#L274

Adam Bottchen (JIRA)

unread,
Mar 21, 2017, 4:25:03 PM3/21/17
to puppe...@googlegroups.com
Adam Bottchen assigned an issue to Unassigned
 
Change By: Adam Bottchen
Assignee: Adam Bottchen

Geoff Nichols (JIRA)

unread,
Mar 29, 2017, 2:29:04 PM3/29/17
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Story Points: 5

Geoff Nichols (JIRA)

unread,
Mar 29, 2017, 2:29:05 PM3/29/17
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Sprint: Agent  Needs Information  Ready for Engineering

Chris Denneen (JIRA)

unread,
Apr 12, 2017, 11:41:04 AM4/12/17
to puppe...@googlegroups.com
Chris Denneen commented on Bug PUP-6134
 
Re: Unable to install a Ruby gem to non-Puppet Ruby stack using the package resource type on Windows

Same issue with `sensu_gem` provider with the master branch of sensu/sensu on github (this fixed some other issues for Windows installs that haven't been released to forge).
Current `package` installs of `sensu-plugins-windows` using `provider => sensu_gem` install the gem's in puppet/sys/ruby/bin instead of sensu/embedded/bin/

Can this be fixed in LTS as well.

Moses Mendoza (JIRA)

unread,
May 16, 2017, 4:41:05 PM5/16/17
to puppe...@googlegroups.com
Moses Mendoza updated an issue
 
Change By: Moses Mendoza
Labels: gem package provider  triaged  windows

Maggie Dreyer (JIRA)

unread,
May 30, 2017, 11:34:04 AM5/30/17
to puppe...@googlegroups.com
Maggie Dreyer assigned an issue to Ethan Brown
Change By: Maggie Dreyer
Assignee: Ethan Brown

Owen Rodabaugh (JIRA)

unread,
Aug 3, 2017, 12:27:03 PM8/3/17
to puppe...@googlegroups.com
Owen Rodabaugh updated an issue
Change By: Owen Rodabaugh
CS Priority: Reviewed Minor
CS Impact: This can be worked around via an exec. It's another tick against supporting windows as a first class citizen in our ecosystem.
CS Severity: 2 - Annoyance
CS Business Value: 3 - $$$$
CS Frequency: 1 - 1-5% of Customers

Thomas Kishel (JIRA)

unread,
Aug 3, 2017, 12:49:03 PM8/3/17
to puppe...@googlegroups.com
Thomas Kishel commented on Bug PUP-6134
 
Re: Unable to install a Ruby gem to non-Puppet Ruby stack using the package resource type on Windows

This bug prevents Package Inspection from being able to inspect system gems, making Package Inspection inaccurate.

I wrote a module to workaround this bug:

https://forge.puppet.com/tkishel/system_gem

It's basically the PR.

Thomas Kishel (JIRA)

unread,
Oct 13, 2017, 4:05:37 PM10/13/17
to puppe...@googlegroups.com
Thomas Kishel commented on Bug PUP-6134

That PR is rather old, it may need to be rebased. I’m on PTO today. I could
look at it on Monday.

Thomas Kishel (JIRA)

unread,
Oct 16, 2017, 3:38:03 PM10/16/17
to puppe...@googlegroups.com
Thomas Kishel updated an issue
 
Change By: Thomas Kishel
Comment:
That PR is rather old, it may need to be rebased. I’m on PTO today. I could
look at it on Monday.

Geoff Nichols (JIRA)

unread,
Nov 11, 2017, 6:34:03 PM11/11/17
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Team: Platform OS Windows
This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)
Atlassian logo

Erick Banks (JIRA)

unread,
Sep 24, 2018, 2:19:06 PM9/24/18
to puppe...@googlegroups.com
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Geoff Nichols (JIRA)

unread,
Oct 2, 2018, 4:46:09 PM10/2/18
to puppe...@googlegroups.com
Geoff Nichols assigned an issue to Unassigned
 
Change By: Geoff Nichols
Assignee: Ethan Brown

Geoff Nichols (JIRA)

unread,
Oct 2, 2018, 4:47:05 PM10/2/18
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Team: Windows Platform OS

Geoff Nichols (JIRA)

unread,
Oct 2, 2018, 4:47:06 PM10/2/18
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Labels: cs_pr_review customer gem package provider windows

Geoff Nichols (JIRA)

unread,
Oct 2, 2018, 4:48:06 PM10/2/18
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Story Points: 5

Scott McClellan (JIRA)

unread,
Oct 15, 2018, 2:52:10 PM10/15/18
to puppe...@googlegroups.com
Scott McClellan updated an issue
Change By: Scott McClellan
Fix Version/s: PUP 5.y
Fix Version/s: PUP 6.y

Geoff Nichols (JIRA)

unread,
Dec 6, 2018, 12:17:05 PM12/6/18
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Fix Version/s: PUP 6.y
Fix Version/s: PUP 7.0.0

Thomas Kishel (JIRA)

unread,
Dec 6, 2018, 12:22:04 PM12/6/18
to puppe...@googlegroups.com
Thomas Kishel commented on Bug PUP-6134
 
Re: Unable to install a Ruby gem to non-Puppet Ruby stack using the package resource type on Windows

Oh, yes. There are other issues with more activity without a workaround.

Adam Bottchen (JIRA)

unread,
Dec 6, 2018, 1:20:05 PM12/6/18
to puppe...@googlegroups.com
Adam Bottchen commented on Bug PUP-6134

I have removed it from the CS Top 10.

Thomas Kishel (JIRA)

unread,
Dec 28, 2018, 4:58:03 PM12/28/18
to puppe...@googlegroups.com
Thomas Kishel commented on Bug PUP-6134

 https://github.com/puppetlabs/puppet/pull/7311 should be preferred over https://github.com/puppetlabs/puppet/pull/5814

as it includes the same stripping of Puppet's RUBY_DIR from PATH prior to setting gemcmd on Windows

Geoff Nichols (JIRA)

unread,
Jun 19, 2019, 6:47:04 PM6/19/19
to puppe...@googlegroups.com
Geoff Nichols updated an issue
Change By: Geoff Nichols
Team: Platform OS Puppet Romania

Mihai Buzgau (JIRA)

unread,
Jul 30, 2019, 11:28:03 AM7/30/19
to puppe...@googlegroups.com
Mihai Buzgau updated an issue
Change By: Mihai Buzgau
Sprint: PR - Triage

Mihai Buzgau (JIRA)

unread,
Aug 7, 2019, 5:01:05 AM8/7/19
to puppe...@googlegroups.com
Mihai Buzgau updated an issue
Change By: Mihai Buzgau
Sprint: PR NW - Triage 2019-08-21

Mihai Buzgau (JIRA)

unread,
Aug 7, 2019, 5:01:05 AM8/7/19
to puppe...@googlegroups.com
Mihai Buzgau updated an issue
Change By: Mihai Buzgau
Story Points: 3

Gheorghe Popescu (JIRA)

unread,
Aug 14, 2019, 8:15:05 AM8/14/19
to puppe...@googlegroups.com
Gheorghe Popescu assigned an issue to Gheorghe Popescu
Change By: Gheorghe Popescu
Assignee: Gheorghe Popescu

Thomas Kishel (JIRA)

unread,
Aug 14, 2019, 10:37:04 AM8/14/19
to puppe...@googlegroups.com
Thomas Kishel commented on Bug PUP-6134
 
Re: Unable to install a Ruby gem to non-Puppet Ruby stack using the package resource type on Windows

I remember there being a concern with this change similar to "but what about users who depend on this bug to mange Puppet Ruby gems (instead of using the puppet_gem provider" but I don't thank that is common or valid, and they have/should use the the puppet_gem provider.

BTW: I've implemented Ethan's recommendation on 2017/01/04 3:09 PM via the command attribute in PUP-6488.

I'm writing acceptance tests for PUP-8949 now, and once those are complete, I'll re-review this and add a test for this ...

Mihai Buzgau (JIRA)

unread,
Aug 21, 2019, 5:17:08 AM8/21/19
to puppe...@googlegroups.com
Mihai Buzgau updated an issue
Change By: Mihai Buzgau
Sprint: NW - 2019-08-21 , NW - 2019-09-03

Mihai Buzgau (JIRA)

unread,
Sep 4, 2019, 5:17:08 AM9/4/19
to puppe...@googlegroups.com
Mihai Buzgau updated an issue
Change By: Mihai Buzgau
Sprint: NW - 2019-08-21, NW - 2019-09-03 , NW - 2019-09-18

Josh Cooper (JIRA)

unread,
Sep 10, 2019, 6:48:04 PM9/10/19
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-6134
 
Re: Unable to install a Ruby gem to non-Puppet Ruby stack using the package resource type on Windows

I made a note in the PR, I think we can close this ticket as a dup of PUP-6488 and close the PR. Using the new targetable functionality it's possible to manage gems on windows (and other platforms) for ruby installations different than the vendored ruby in our puppet-agent package:

I installed chocolatey using:

C:\Users\Administrator>choco install ruby
 
...
 
Ruby is going to be installed in 'C:\tools\ruby26'
 
Installing 64-bit ruby...
 
...

Then installed the gem into that ruby using:

package { 'puppet-lint':
 
  ensure   => present,
 
  provider => 'gem',
 
  command => 'C:\tools\ruby26\bin\gem.cmd',
 
}


C:\Users\Administrator>puppet apply manifest.pp -d
 
...
 
Debug: Prefetching gem resources for package
 
Debug: Executing: 'C:\tools\ruby26\bin\gem.cmd list --local'
 
Debug: Executing: 'C:\tools\ruby26\bin\gem.cmd list --local \Apuppet-lint\z'
 
Debug: Executing: 'C:\tools\ruby26\bin\gem.cmd --version'
 
Debug: Executing: 'C:\tools\ruby26\bin\gem.cmd install --no-document puppet-lint'
 
Notice: /Stage[main]/Main/Package[puppet-lint]/ensure: created

And the gem is installed

C:\tools\ruby26\bin>gem which puppet-lint
 
c:/tools/ruby26/lib/ruby/gems/2.6.0/gems/puppet-lint-2.3.6/lib/puppet-lint.rb

Thomas Kishel (JIRA)

unread,
Sep 10, 2019, 8:02:04 PM9/10/19
to puppe...@googlegroups.com
Thomas Kishel commented on Bug PUP-6134

Yes but it is counterintuitive that ...

On Windows, the gem provider installs into Puppet
On Linux, the gem provider installs into system Ruby
On both Linux and Windows, the puppet_gem provider installs into Puppet

Thomas Kishel (JIRA)

unread,
Sep 10, 2019, 8:05:05 PM9/10/19
to puppe...@googlegroups.com
Thomas Kishel commented on Bug PUP-6134

I realize this may be a matter of principle ... but I'm imagining trying to explain this to a user in documentation or a support ticket.

Josh Cooper (JIRA)

unread,
Sep 11, 2019, 6:50:05 PM9/11/19
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-6134

How about:

puppet_gem provider installs into Puppet

gem provider installs into system ruby

Caveat: The gem provider on Windows installs into Puppet's ruby. To manage gems in system ruby, specify the path to gem.cmd as the command parameter. In Puppet 7, the behavior will be changed so it's not necessary.

Thomas Kishel (JIRA)

unread,
Sep 11, 2019, 8:05:03 PM9/11/19
to puppe...@googlegroups.com
Thomas Kishel commented on Bug PUP-6134

I defer to a principle engineer about principles

That's reasonable, especially if we actually fix this in P7.

Thomas Kishel (Jira)

unread,
Mar 2, 2021, 7:58:57 PM3/2/21
to puppe...@googlegroups.com
Thomas Kishel commented on Bug PUP-6134

Thank you for fixing this in PUP-10677 !!!
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages