On 7 Jun 2011, at 00:12, Daniel Pittman <dan...@puppetlabs.com> wrote:
> On Mon, Jun 6, 2011 at 15:43, Daniel Pittman <dan...@puppetlabs.com> wrote: >> On Mon, Jun 6, 2011 at 13:57, R.I.Pienaar <r...@devco.net> wrote: >> >>>> So, add that comment and I am happy to see this go in. Throw my >>>> reviewed-by on the change and you can go ahead and merge it into >>>> master. (I think you have the commit rights already, but if not I >>>> will chase Zach to get them for you.) >>>> >>>> Thanks for writing this, and I think it is a great thing to have >>>> added to the system. > […] >> For now, though, I will get that merged in the next few minutes. > > 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. My main reason for going down this road is cos pluginsync is all or nothing. I want to extend the master but the nodes as the nodes won't have the dependencies to run a specific function for example. Something to keep in mind if we are going to rethink how this stuff works. And so there is a class of extension that the current systems dont cater for. See my usual complaints about adding P::Util classes for example > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
