puppet_forge 2.2.7 installs semantic_puppet 1.0.0, which breaks r10k

[stblassitude]

/usr/local/lib/ruby/site_ruby/2.3/rubygems/specification.rb:1436:in block in activate_dependencies': can't satisfy 'semantic_puppet (~> 0.1.0)', already activated 'semantic_puppet-1.0.0' (Gem::LoadError) from /usr/local/lib/ruby/site_ruby/2.3/rubygems/specification.rb:1428:ineach' from /usr/local/lib/ruby/site_ruby/2.3/rubygems/specification.rb:1428:in activate_dependencies' from /usr/local/lib/ruby/site_ruby/2.3/rubygems/specification.rb:1410:inactivate' from /usr/local/lib/ruby/site_ruby/2.3/rubygems.rb:300:in block in activate_bin_path' from /usr/local/lib/ruby/site_ruby/2.3/rubygems.rb:300:insynchronize' from /usr/local/lib/ruby/site_ruby/2.3/rubygems.rb:300:in activate_bin_path' from /usr/local/bin/r10k:23:in

'

I believe r10k should either bump semantic_puppet as well, or require puppet_forge 2.2.6.

[scotje]

Looks like there is only one place that r10k invokes code from semantic_puppet so it might be better to add a helper to puppet_forge to handle that case so that r10k doesn't need to depend directly on semantic_puppet at all.

[scotje]

https://github.com/puppetlabs/r10k/blob/master/lib/r10k/module/forge.rb#L20 is the only usage I see.

[stblassitude]

I believe bumping the dependency is necessary and useful for cases where r10k is installed through an OS package. I'm running a Puppetserver on FreeBSD, where all components are installed from OS packages. Since the FreeBSD packages mirror the dependencies of the gems, the package manager would normally refuse to install both rubygem-puppet_forge 2.2.7 (requiring semantic_puppet 1.0.0) and rubygem-r10k (semantic_puppet 0.1.0). The maintainers have chosen to create a separate package rubygem-semantic_puppet0, which works around the issue for the package manager, but only shifts the problem to runtime, because r10k loads both puppet_forge and semantic_puppet, creating a conflict with two versions of semantic_puppet being in the path.

If you could apply the PR #755 and release 2.5.6, the FreeBSD package maintainers could update the packages, making me very happy :-)

[nmaludy]

+1

[stblassitude]

The FreeBSD package maintainer has bumped the dependency locally, so the problem has been rectified there: https://svnweb.freebsd.org/ports?view=revision&revision=445537

[hmorrised]

I am getting a similar error when I attempt to install r10k using gem install in CentOS 7:

[root@puppet ~]# gem install r10k
ERROR:  While executing gem ... (Gem::DependencyError)
    Unable to resolve dependencies: r10k requires semantic_puppet (~> 0.1.0); puppet_forge requires semantic_puppet (~> 1.0)
[root@puppet ~]# uname -a
Linux puppet.local 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root@puppet ~]# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
[root@puppet ~]# ruby --version
ruby 2.0.0p648 (2015-12-16) [x86_64-linux]

[jeff1evesque]

I got a workaround via https://github.com/jeff1evesque/machine-learning/issues/2991. However, I'm getting errors in my travis ci build, which I am wondering is related to my fix.

[mkayontour]

As I got this error while packaging for RHEL7, I decided to use puppet_forge 2.2.6 which depends still to semantic version 0.1.x

It might be better to have a puppet_forge 2.3.x which then depends to semantic 1.x

Then r10k won't struggle with the dependency forge 2.2.x

But so far, install puppet_forge 2.2.6 afterwards r10k and you are good to go.

[andersonmills]

Finally working on this... https://tickets.puppetlabs.com/browse/RK-306 with a PR up in forge-ruby (https://github.com/puppetlabs/forge-ruby/pull/51) waiting for approval so we can release a new version and r10k can depend on it.

[andersonmills]

puppet_forge gem 2.2.8 is released and now waiting on r10k PR (https://github.com/puppetlabs/r10k/pull/775) to be merged which utilizes the helper method and drops the direct dependency on semantic_puppet.

[andersonmills]

@mkayontour The problem is that we can't go back and remove puppet_forge v2.2.7 at this point. (I do agree that we probably should've made puppet_forge 2.3.0 when we made the dependency on semantic 1.x.)

[mkayontour]

@andersonmills I know going backwards is no option - I'm looking forward to the 2.3.x ;)

and thanks for your work take care :)

[github-actions[bot]]

This issue has been marked stale because it has had no activity for 60 days. The Puppet Team is actively prioritizing existing bugs and new features, if this issue is still important to you please comment and we will add this to our backlog to complete. Otherwise, it will be closed in 7 days.