The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Feature #7788

Puppet should allow rubygems to deliver new functionality

Added by R.I. Pienaar almost 5 years ago. Updated over 3 years ago.

Status:ClosedStart date:06/04/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:plug-ins
Target version:3.0.0
Affected Puppet version: Branch:https://github.com/kelseyhightower/puppet/tree/feature/3.0rc/autoloader_works_with_rubygems
Keywords:rubygems autoloader

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com


Description

It would be desirable to use Rubygems to install things like parser functions.

There might be cases where you only want a function on the master, pluginsync would copy it everywhere and everywhere might not have the dependencies needed to run it.

If the autoloader considered the rubygem search path while autoloading this should allow gems to extend puppet.

Update: Just to be clear, this ticket is about whether Puppet should allow rubygems as a delivery mechanism for Puppet extensions like parser functions, Faces, types and more. If added in, you could deliver Puppet extensions via modules with pluginsync and via installing a Ruby gem. Both the Puppet DSL and Puppet’s Ruby DSL would be untouched.


Related issues

Related to Puppet - Feature #14149: The Puppet::Modules (or some other namespace) should be r... Closed 04/23/2012
Related to Puppet - Bug #7316: puppet face applications (subcommands) delivered via modu... Closed 05/02/2011
Related to Puppet - Bug #18755: Puppet broken in 3.1rc1 with rubygems >= 1.8 and multiple... Closed

History

#1 Updated by R.I. Pienaar almost 5 years ago

  • Branch set to ripienaar/feature/master/7788

#2 Updated by James Turnbull almost 5 years ago

  • Category set to plug-ins
  • Status changed from Unreviewed to In Topic Branch Pending Review
  • Assignee set to Nigel Kersten
  • Target version set to 2.7.0

#3 Updated by Anonymous almost 5 years ago

  • Target version changed from 2.7.0 to 2.7.x

Damn. So, I was going through the last little steps in testing this after I merged it locally, before pushing, and we ran into a set of concerns that we don’t have time to address right now. Specifically, there are two concrete issues we are worried about here:

One, we are concerned that there might be cases where this adds the gem path, but not everything on the Ruby $LOAD_PATH, to the locations our autoloader (or one of the other open-coded implementations of the same) hunt for things on disk. That should be easy enough to verify, but we want (someone) to audit that before this gets merged.

Two, we are concerned that this potentially adds trouble when someone has two copies of Puppet installed, one through RubyGems, and the other through an OS package, or from source, or something like that. This introduces a new path that code can get loaded, and it isn’t at all clear which will win from the outside.

We have a cluster of other issues in the area, though: we need to be able to pluginsync faces and actions, as well as utility functions; we want to make sure we have consistent search paths to avoid the “face discovered, but can’t be loaded” showing up in another guise, and that sort of thing.

So, from discussion with Nigel and James we are going to hold this off for a bit: the code you have is correct, and ready to merge, and is going to stay there until we merge it as part of sorting out the rest of the mess around this area.

So, sorry: I wish I had thought of this earlier, or could more easily convince myself (and Nigel) that this was a safe step toward the ultimate goal right now, rather than having to delay landing it. :/ I really want to see this feature in.

#4 Updated by Anonymous almost 5 years ago

  • Status changed from In Topic Branch Pending Review to Code Insufficient

#5 Updated by Anonymous almost 5 years ago

On Mon, Jun 6, 2011 at 4:25 PM, tickets@puppetlabs.com wrote:

Two, we are concerned that this potentially adds trouble when someone has two copies of Puppet installed, one through RubyGems, and the other through an OS package, or from source, or something like that. This introduces a new path that code can get loaded, and it isn’t at all clear which will win from the outside.

This is already an issue today; people can’t have two versions of Puppet that exist in different parts of the $LOAD_PATH. It has been for a long time, so I don’t think this is a new concern, just a long standing old concern. =)

The answer is that they both win. You get types loaded from the “other” version and they fight each other.

-Jeff

#6 Updated by James Turnbull almost 5 years ago

Agree on the load path but in this case we’re specifically adding the Gem path – something we’re not doing now – I’ve had puppet installed via gems and via package in the past without conflict.

#7 Updated by Jan Ivar Beddari over 4 years ago

I’d like to see this happen aswell.

Could it be done by creating Puppet-instance-specific paths using modules? http://janveldeman.wordpress.com/2008/04/14/project-specific-rubygems/ Probably not the most elegant solution.

Or a config setting with an explanation? In my (albeit small) Puppet kingdom catering for the dual install case seems less useful than this.

#8 Updated by Gareth Rushgrove over 4 years ago

Had a brief chat at puppetconf about this, specifically about making it easy to package new faces as gems and have them loaded automatically.

I decided to give the patch a whirl and hit a problem, specifically part of the implementation is deprecated when running under 1.9.2-p290

NOTE: Gem.all_load_paths is deprecated with no replacement. It will be removed on or after 2011-10-01.

Looks like Gem::Specification.each might be another approach, depending on which version of rubygems you need to support.

#9 Updated by Nigel Kersten over 4 years ago

Given we’re integrating ‘puppet module’ into Puppet, and assuming that we’re actually going to fulfill our promise to make it easy to distribute all the kinds of Puppet extension points (faces, facts, lib/whatever, providers) via modules, I’d love to get feedback from people on this ticket as to whether they think we really should deliver this functionality?

#10 Updated by Nigel Kersten over 4 years ago

  • Status changed from Code Insufficient to Needs Decision

#11 Updated by R.I. Pienaar over 4 years ago

I think it still has value, unless you also let us control what gets pluginsynced to what places. With gems if we wanted some plugin on a subset of machines we just install it on those machines. With pluginsync thats not possible.

#12 Updated by Anonymous over 4 years ago

R.I. Pienaar wrote:

I think it still has value, unless you also let us control what gets pluginsynced to what places. With gems if we wanted some plugin on a subset of machines we just install it on those machines. With pluginsync thats not possible.

How do environments fail to meet your needs here?

#13 Updated by Nigel Kersten over 4 years ago

That’s a big hammer to solve a small problem.

I guess to invert it, what’s the problem with distributing these plugins to all machines in a given environment? Is it that you end up with version conflicts of the same library? Are they sensitive in some other way?

#14 Updated by Kelsey Hightower almost 4 years ago

  • Status changed from Needs Decision to In Topic Branch Pending Review
  • Target version changed from 2.7.x to 3.0.0
  • Keywords set to rubygems autoloader
  • Branch changed from ripienaar/feature/master/7788 to https://github.com/kelseyhightower/puppet/tree/feature/3.0rc/autoloader_works_with_rubygems

#15 Updated by Kelsey Hightower almost 4 years ago

  • Branch changed from https://github.com/kelseyhightower/puppet/tree/feature/3.0rc/autoloader_works_with_rubygems to https://github.com/puppetlabs/puppet/pull/873

#16 Updated by Kelsey Hightower almost 4 years ago

If you want to try out the updated autoloader with support for rubygems, checkout my autoloader_works_with_rubygems branch.

Cloud Provisioner Gem

As an added bonus I’ve created a gem for cloud provisioner: puppetlabs-cloud_provisioner-1.0.4.gem

Full Speed Ahead

Once you have the autoloader_works_with_rubygems branch setup, simply install the gem and you should be good to go:

$ gem install puppetlabs-cloud_provisioner-1.0.4.gem
...
Successfully installed fog-1.3.1
Successfully installed guid-0.1.1
Successfully installed puppetlabs-cloud_provisioner-1.0.4

$ puppet help
Usage: puppet <subcommand> [options] <action> [options]

Available subcommands:
...
node_aws          View and manage Amazon AWS EC2 nodes.

#17 Updated by Kelsey Hightower almost 4 years ago

More than likely you will run into this bug:

Error: Could not autoload puppet/face/node_aws/bootstrap: "--tags=": already defined in puppet
Error: Could not autoload puppet/face/node_aws/bootstrap: "--tags=": already defined in puppet
Error: Try 'puppet help help help' for usage

This has something to do with the way we are trying to prevent plug-ins from loading twice. I get the same issue without my patch. To get things working I had to comment out a few lines, I’ll file a bug in the morning:

diff --git a/lib/puppet/interface/option.rb b/lib/puppet/interface/option.rb
index 3d0a9c3..7c1455f 100644
--- a/lib/puppet/interface/option.rb
+++ b/lib/puppet/interface/option.rb
@@ -28,7 +28,7 @@ class Puppet::Interface::Option
         # jeffweiss 17 april 2012
         name = optparse_to_optionname(item)
         if Puppet.settings.include? name then
-          raise ArgumentError, "#{item.inspect}: already defined in puppet"
+          # raise ArgumentError, "#{item.inspect}: already defined in puppet"
         end
         if dup = dups[name] then
           raise ArgumentError, "#{item.inspect}: duplicates existing alias #{dup.inspect} in #{@parent}"
diff --git a/lib/puppet/util/autoload.rb b/lib/puppet/util/autoload.rb
index a06b0fb..ecfaa3c 100644
--- a/lib/puppet/util/autoload.rb
+++ b/lib/puppet/util/autoload.rb
@@ -64,7 +64,7 @@ class Puppet::Util::Autoload
       rescue Exception => detail
         message = "Could not autoload #{name}: #{detail}"
         Puppet.log_exception(detail, message)
-        raise Puppet::Error, message
+        # raise Puppet::Error, message
       end
     end

#18 Updated by James Turnbull almost 4 years ago

+1000 – this is awesome.

#19 Updated by Kelsey Hightower almost 4 years ago

With this patch Puppet also supports loading parser functions via gems:

autoloader-test.pp

$port = hiera('port', 8888)

notify {'autoloader test message':
  message => "Port: $port"
}

Puppet apply without the hiera-puppet gem installed:

$ puppet apply autoloader-test.pp 
Error: Unknown function hiera at /workspace/puppet/autoloader-test.pp:1 on node dev.hightower.org
Error: Unknown function hiera at /workspace/puppet/autoloader-test.pp:1 on node dev.hightower.org

Now install the hiera-puppet gem

$ gem install hiera-puppet
Fetching: hiera-puppet-0.3.0.gem (100%)
Successfully installed hiera-puppet-0.3.0
1 gem installed
Installing ri documentation for hiera-puppet-0.3.0...
Installing RDoc documentation for hiera-puppet-0.3.0...

Puppet apply with the hiera-puppet gem installed:

$ puppet apply autoloader-test.pp
Port: 8888
/Stage[main]//Notify[autoloader test message]/message: defined 'message' as 'Port: 8888'
Finished catalog run in 0.03 seconds

#20 Updated by eric sorenson almost 4 years ago

Really nice win, I’ll give the branch a try this weekend.

Interesting to think about this in conjunction with #11419.

#21 Updated by Adam Kosmin almost 4 years ago

It will be nice to not have to manually copy files around. Thanks…

#22 Updated by Ryan Coleman almost 4 years ago

+1 from me. Modules & plugin-sync is great for delivering types, facts and other content to an Agent just-in-time for use in manifests. It’s not a great platform for delivering things like Functions & Faces, especially those that require third-party software like cloud provisioner and fog. Allowing users to distribute this content and more via gems seems like a natural fit (though later, native system packages too).

Side-note: I want to ensure that the Forge becomes a great place to discover Puppet content regardless of its delivery mechanism. If gems become a way to distribute Puppet content, you can expect the Forge to help you discover it.

#23 Updated by Anonymous almost 4 years ago

+1 from me after quizzing #puppet about what benefits this brings. My main concerns lie around the examples from above. If I have a manifest that uses hiera and also has a package { ‘hiera-puppet’: provider => gem } will it be smart enough to load up the gem dependencies and run the catalog? I just don’t want a situation where I need a third party tool to install various gem’s just to get a puppet run functioning. As long as that isn’t a problem or can be worked around then this sounds great.

#24 Updated by Kelsey Hightower almost 4 years ago

  • Assignee changed from Nigel Kersten to Kelsey Hightower

#25 Updated by Andrew Kesterson almost 4 years ago

Voted this up. Anything that gives me more ability to write in ruby is a huge benefit. I can’t tell you how often I’ve found myself wanting to do simple things in a module (like iterate over a hashmap, for example), and had to drop to the ruby DSL to get it done. If I have to drop to ruby to do serious lifting anyway, I would (honestly) rather spend ALL my time there, instead of splitting my work between the ruby language and the puppet DSL. If this can get me one step closer to never having to touch the janky, custom puppet DSL again, I will love it to death.

#26 Updated by Caleb Case almost 4 years ago

+1 Thanks for thinking about developers who want to use more ruby! I’m also of the opinion that the puppet DSL leaves alot to be desired and that dropping to ruby is the only sane choice.

#27 Updated by James Turnbull almost 4 years ago

So to be clear – this doesn’t mean the Puppet DSL is going to go away. Yes it has some oddities but it’s also incredibly powerful and covers the needs of 80% of our user’s requirements. We’re working to identify and fix a lot of those and a lot of the recent dev focus has been on making disparate parts of Puppet more sane. But Puppet with the DSL is way more approachable and usable as a tool than without.

#28 Updated by Louis Coilliot almost 4 years ago

For example, I struggled to install hiera, gem delivery would be nice. No bother anymore with synchonization of the custom Hiera functions (hiera(), hiera_array(), hiera_hash()…) into the master.

#29 Updated by Kelsey Hightower almost 4 years ago

James is right. This feature is more about extending Puppet via rubygems. But yeah, our Ruby DSL could use some love too, that’s a separate issue.

#30 Updated by Ryan Coleman almost 4 years ago

  • Description updated (diff)

#31 Updated by Tim Sharpe almost 4 years ago

Gigantic +1 from me. I would love to ship things like puppet-lint as a Face rather than a separate script, but without the functionality provided in this patch, it’s just not feasible.

#32 Updated by John Vincent almost 4 years ago

Big ups from me as well. The stuff we’re doing to integrate closer with Puppet would be much easier if we could distribute it as a gem and just have folks push that gem to places that need it.

#33 Updated by Anonymous almost 4 years ago

  1. I always prefer OS-based packaging to gems, but gems are clearly the preferred distribution method for Ruby developers, and nothing stops us (or others) from wrapping OS packages around them.

Great work on this, Kelsey – while the rest of us sat around and debated you actually wrote a fix. And a good one, at that.

#34 Updated by Anonymous almost 4 years ago

Well, Redmine turned my “+1” into a bold 1, but it’s +1 nevertheless.

#35 Updated by Matthaus Owens almost 4 years ago

If this makes it easier for folks to deliver puppet content, then it seems like a win. We should keep in mind that not everyone has the ability or desire to use rubygems (while recognizing that can be a powerful delivery mechanism for code).

#36 Updated by Adrien Thebo almost 4 years ago

Given how integral gems are to most of the ruby community, it seems silly to not have this. It’s relied on very heavily as a distribution mechanism, and it would greatly reduce the difficulty of discovering and using puppet extensions.

#37 Updated by Chris Price almost 4 years ago

We need to do some profiling around the autoloader and how performance changes as the number of paths grows, but the more I think about this set of issues (see also #7316 and this pull request:

https://github.com/puppetlabs/puppet/pull/882

), the more I agree with this being necessary. As far as performance goes, we will probably need to deal with it regardless… and if we can clean up a few things and centralize more of our loading into the autoloader, we can focus on performance improvements there without breaking API.

#38 Updated by Anonymous almost 4 years ago

+1 I fully support Puppet Labs supporting Puppet extensions distributed as a rubygem.

#39 Updated by Nigel Kersten almost 4 years ago

As it’s not captured here, I’ve come around to the view that while we’re not going to mandate gem delivery, we absolutely need to support it for all Puppet extension points.

#40 Updated by Kelsey Hightower almost 4 years ago

  • Status changed from In Topic Branch Pending Review to Code Insufficient
  • Branch changed from https://github.com/puppetlabs/puppet/pull/873 to https://github.com/kelseyhightower/puppet/tree/feature/3.0rc/autoloader_works_with_rubygems

Seems like this is going to get merged, but I may need to refactor depending on performance requirements. I’m closing the open pull request for now.

#41 Updated by eric sorenson over 3 years ago

  • Assignee changed from Kelsey Hightower to Patrick Carlisle

This is in progress for 3.0.0.

#42 Updated by Anonymous over 3 years ago

Putting this in causes a new stat call per gem installed:

11430/0x341ea4:        5 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@gem-loading/gems/ruby-hmac-0.4.0/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x79)    = -1 Err#2  
11430/0x341ea4:        3 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@gem-loading/gems/nokogiri-1.5.5/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x78)     = -1 Err#2  
11430/0x341ea4:        2 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@gem-loading/gems/net-ssh-2.5.2/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x77)    = -1 Err#2  
11430/0x341ea4:        2 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@gem-loading/gems/net-scp-1.0.4/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x77)    = -1 Err#2  
11430/0x341ea4:        3 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@gem-loading/gems/multi_json-1.3.6/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x7A)     = -1 Err#2  
11430/0x341ea4:        2 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@gem-loading/gems/mime-types-1.19/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x79)    = -1 Err#2  
11430/0x341ea4:        2 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@gem-loading/gems/guid-0.1.1/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x74)     = -1 Err#2  
11430/0x341ea4:        2 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@gem-loading/gems/formatador-0.2.3/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x7A)     = -1 Err#2  
11430/0x341ea4:        2 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@gem-loading/gems/fog-1.5.0/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x73)    = -1 Err#2  
11430/0x341ea4:        3 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@gem-loading/gems/excon-0.16.1/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x76)     = -1 Err#2  
11430/0x341ea4:        3 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@gem-loading/gems/example-function-1.0.0/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x80)     = -1 Err#2  
11430/0x341ea4:        3 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@gem-loading/gems/cloud_provisioner-1.0.0/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x81)    = -1 Err#2  
11430/0x341ea4:        3 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@global/gems/bundler-1.1.1/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x72)     = -1 Err#2  
11430/0x341ea4:        2 stat64("/Users/andy/.rvm/gems/ruby-1.9.3-p125@gem-loading/gems/builder-3.0.0/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x77)    = -1 Err#2  
11430/0x341ea4:        3 stat64("/Users/andy/.puppet/modules/java_ks/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x56)     = -1 Err#2 
11430/0x341ea4:        3 stat64("/Users/andy/.puppet/modules/mount_providers/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x5E)     = -1 Err#2 
11430/0x341ea4:        2 stat64("/Users/andy/.puppet/modules/testing/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x56)     = -1 Err#2 
11430/0x341ea4:        5 stat64("/var/lib/puppet/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x42)     = -1 Err#2 
11430/0x341ea4:       13 stat64("/Users/andy/work/puppet/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106700, 0x4A)     = 0 0 
11430/0x341ea4:       12 stat64("/Users/andy/work/puppet/lib/puppet/indirector/instrumentation_data/local.rb\0", 0x7FFF67106FE0, 0x4A)     = 0 0

This may cause a significant slowdown for some users, but I don’t see a way around that if we want to load from a bunch of new paths.

#43 Updated by Anonymous over 3 years ago

Merged in commit f6d2505

#44 Updated by Anonymous over 3 years ago

  • Status changed from Code Insufficient to Merged - Pending Release
  • Assignee deleted (Patrick Carlisle)

#45 Updated by Peter Meier over 3 years ago

So some performance optimizations got merged in as well or is this still the same issue as in the comments above?

#46 Updated by Anonymous over 3 years ago

Peter, there hasn’t been anything done at the moment. The stats are really just the result of the increase number of places were we have to load code from. We’ll still need to see the real impact that this ends up having on performance.

#47 Updated by Anonymous over 3 years ago

Turns out that there is a small problem that is triggered on old rubygems (1.6.4 showed the problem) where after asking for the available paths several times it screws up and ends up trying to load a file that doesn’t exist:

  1) Puppet::Util::Autoload when reloading files changes should be seen by changed? on the instance using the short name
     Failure/Error: @autoload.load("myfile")
     Errno::ENOENT:
       No such file or directory - /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/specifications/rake-0.8.7.gemspec
     # /home/hudson/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems.rb:490:in `read'
     # /home/hudson/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems.rb:490:in `each_load_path'
     # /home/hudson/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems.rb:486:in `each'
     # /home/hudson/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems.rb:486:in `each_load_path'
     # /home/hudson/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems.rb:640:in `latest_load_paths'
     # /home/hudson/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems.rb:639:in `each'
     # /home/hudson/.rvm/rubies/ruby-1.8.7-p334/lib/ruby/site_ruby/1.8/rubygems.rb:639:in `latest_load_paths'
     # ./lib/puppet/util/rubygems.rb:45:in `directories'
     # ./lib/puppet/util/autoload.rb:169:in `gem_directories'
     # ./lib/puppet/util/autoload.rb:173:in `search_directories'
     # ./lib/puppet/util/autoload.rb:96:in `get_file'
     # ./lib/puppet/util/autoload.rb:64:in `load_file'
     # ./lib/puppet/util/autoload.rb:208:in `load'
     # ./spec/unit/util/autoload_spec.rb:190
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/example.rb:80:in `instance_eval'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/example.rb:80:in `run'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/example.rb:173:in `with_around_hooks'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/example.rb:77:in `run'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/example_group.rb:355:in `run_examples'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/example_group.rb:351:in `map'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/example_group.rb:351:in `run_examples'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/example_group.rb:337:in `run'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/example_group.rb:338:in `run'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/example_group.rb:338:in `map'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/example_group.rb:338:in `run'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/command_line.rb:28:in `run'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/command_line.rb:28:in `map'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/command_line.rb:28:in `run'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/reporter.rb:34:in `report'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/command_line.rb:25:in `run'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/runner.rb:69:in `run'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/gems/rspec-core-2.9.0/lib/rspec/core/runner.rb:10:in `autorun'
     # /home/hudson/.rvm/gems/ruby-1.8.7-p334@noFeatures/bin/rspec:19

The file that it is trying to load is actually found in /home/hudson/.rvm/gems/ruby-1.8.7-p334@global, which is where it actually loads it from the first few times. The fix is to cache the call to get the paths.

Fix committed in e5d075c

#48 Updated by Matthaus Owens over 3 years ago

  • Status changed from Merged - Pending Release to Closed

Released in Puppet 3.0.0-rc4

Also available in: Atom PDF