I think that this should go in rspec-puppet since it is core to custom functions and types functioning in many cases. Also, users may, or may not, be using the other testing components.
Thanks, Trevor On Tue, Dec 2, 2014 at 2:13 AM, Josh Cooper <j...@puppetlabs.com> wrote: > > > On Mon, Dec 1, 2014 at 11:44 AM, Trevor Vaughan <tvaug...@onyxpoint.com> > wrote: > >> Well that makes a ridiculous amount of sense. >> >> Thanks for posting, I'll check it out tomorrow. >> >> Trevor >> >> On Mon, Dec 1, 2014 at 4:20 AM, Gavin Williams <fatmc...@gmail.com> >> wrote: >> >>> The code I've added to work-around the Puppet issue is here[1]. >>> >> >>> HTH. >>> >>> Gav >>> >>> [1]https://gist.github.com/fatmcgav/aa7295798502d660c6a3 >>> >> > Thanks Gavin for posting that, and for the ticket and PR. I think your > "work-around" is really the right thing to be doing. > > Puppet's autoloader has a fatal flaw that causes a host of issues where > code cannot be loaded. See the linked issues in > https://projects.puppetlabs.com/issues/7316 > > A good example is the case where you have a module defining a new type in > lib/puppet/type/foo.rb: > > require 'puppet/type/bar' > > Puppet::Type.newtype(:foo) do > end > > And the `foo` type requires helper code `bar` from within the same (or > different) module. The problem with puppet's autoloader is that it only > participates in the loading of `foo`, but is "out of the loop" when `foo` > requires `bar`. As a result we have the autoloader loading `foo`, but Ruby > loading `bar`. What could possibly go wrong? > > 1. Well, the autoloader searches the current environment's modulepath to > load `foo`, but Ruby only knows about $LOAD_PATH. As a result, modules > often fail to load their helper code[1], or the module works around it by > using the absolute path to the helper code[2], or it tries to rescue > LoadError and do something "smart"[3]. This is a terrible pattern. > > 2. The autoloader uses `Kernel.load` to load `foo`[4], but Ruby requires > `bar`. If the class has already been required, the former will reload the > class, whereas the latter will not. In long running processes, e.g. master, > it is possible for the autoloader to reload a new version of a function, > but never reload the helper code that the function relies on[5]. So you > have a new version of `foo` running with an old version of `bar`, leading > to nearly impossible to debug scenarios, e.g. NoMethodErrors that magically > disappear when you restart the master[6]. > > 3. Historically, the Puppet[:libdir] setting has allowed multiple > directories to be added to the autoloader's search path, but it has no > effect on Ruby's $LOAD_PATH. While this "works" in some cases, e.g when > using puppet as a library or rspec tests[7], it would fail hard if you ever > tried to run `puppet apply` with that setting[8]. > > 4. To solve https://projects.puppetlabs.com/issues/7316, Andy and I took > the approach that puppet (the application) should be responsible for > setting up the ruby $LOAD_PATH[9], and puppet (the library) should just use > the current $LOAD_PATH. > > I think we should do something similar for the rspec-puppet case, where > the thing that runs the tests is responsible for updating the $LOAD_PATH to > include module specific paths. But this raises a few questions: > > Does this belong in rspec-puppet, puppetlabs_spec_helper, or puppet's own > testing methods (lib/puppet/test/helper.rb)? > > What environment/modulepath should be used, especially once legacy > environment support is removed[10]? > > Josh > > [1] https://tickets.puppetlabs.com/browse/PUP-3336 > [2] > https://github.com/puppetlabs/puppetlabs-mysql/blob/master/lib/puppet/provider/mysql_database/mysql.rb#L1 > [3] > https://github.com/puppetlabs/puppetlabs-registry/blob/master/lib/puppet/provider/registry_key/registry.rb#L2-L12 > <https://github.com/puppetlabs/puppetlabs-registry/blob/master/lib/puppet/provider/registry_key/registry.rb#L2-L12> > [4] > https://github.com/puppetlabs/puppet/blob/3.7.3/lib/puppet/util/autoload.rb#L62 > [5] https://tickets.puppetlabs.com/browse/PUP-1033 > [6] https://tickets.puppetlabs.com/browse/PUP-2380 > [7] > https://github.com/rodjek/rspec-puppet/blob/master/lib/rspec-puppet/support.rb#L140 > [8] > https://tickets.puppetlabs.com/browse/PUP-3336?focusedCommentId=114681&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-114681 > [9] > https://github.com/puppetlabs/puppet/blob/3.7.3/lib/puppet/util/command_line.rb#L135-L141 > [10] https://tickets.puppetlabs.com/browse/PUP-3268 > > -- > Josh Cooper > Developer, Puppet Labs > > *Join us at **PuppetConf 2015, October 5-9 in Portland, OR - * > http://2015.puppetconf.com. > *Register early to save 40%!* > > -- > 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 puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CA%2Bu97u%3DaUST95KmRF-E4wx43q3wMfsK8SNvXTEY4U9aHsYe_EA%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-dev/CA%2Bu97u%3DaUST95KmRF-E4wx43q3wMfsK8SNvXTEY4U9aHsYe_EA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXJ0%2B1ZzPahqG4%2Bqtzcr1ams31fVoA%3D4Z3jDLAxjwUq4Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
