Issue #14149 has been updated by Daniel Pittman.
R.I. Pienaar wrote: > So it seems the desire for a known namespace where ppl can put their own > other classes and such is specifically so that they can get it pluginsynced > out. Sure, and that works correctly today, and will continue to work tomorrow. PluginSync does not impose any limitation on what it will transfer to the client. It just doesn't *load* anything itself - the autoloader does that, and it doesn't care how those files got there. It treats PluginSync and other install sources equally. > To keep your code clean u want some sub classes, modules etc and people tend > to put this in Puppet::Util now but thats in the past caused problems too. > > So I think we do need some known place where arbitrary code can live and we > should cater for that namespace in pluginsync. ...and we absolutely do: if you put content in `::AwesomeSauce`, PluginSync will put it on the client and arrange for it to be available to you. When your code is loaded by Puppet, in one of the defined entry points, it can load your utility code from a distinct namespace. The idea that a magic namespace inside Puppet **that has no behaviour at all** adds value here is, I think, the core of the problem. Everything you want to do should work today. If it doesn't, it is a bug in Puppet. None of it requires this magic namespace. ---------------------------------------- Feature #14149: The Puppet::Modules (or some other namespace) should be reserved for use by modules https://projects.puppetlabs.com/issues/14149#change-64287 Author: Jeff McCune Status: Rejected Priority: Normal Assignee: Category: modules Target version: 2.7.x Affected Puppet version: 2.6.0 Keywords: module namespace constant class modules utility util methods constants Branch: https://github.com/puppetlabs/puppet/pull/704 # Overview # 3rd party modules often need to define their own constants in the form of Ruby module or class objects. Puppet does not provide a safe namespace for this use. As a result, 3rd party applications may inadvertently monkey patch Puppet or Puppet may inadvertently monkey patch 3rd party software. In the worst case, the software breaks if the constants are mutually exclusive, as was the case with this code from the Puppet Module tool and Puppet: puppet-module tool <pre> module Puppet class Module end end </pre> Puppet <pre> module Puppet module Module end end </pre> This will break because Puppet::Module cannot exist as a class and a module at the same time. If it doesn't break entirely, the two pieces of software will monkey patch each other. # Impact Data # All modules that need to define common utility code share this problem. We've largely been ignoring this problem as is evidenced by recent issues with the following pieces of software and their namespace conflicts * Puppet::Module * SemVer * Cloud Provisioner (Puppet 2.7.12 + Cloud Provisioner 1.0.4 installed results in err: no such file to load -- puppet/face/node/classify err: Try 'puppet help help help' for usage) * Registry utility methods * Network Device Support [Puppet::Util::NetworkDevice::F5](https://github.com/puppetlabs/puppetlabs-f5/blob/41732cd725f762cf19d7d1d7cfcfbc12fc68ed20/lib/puppet/util/network_device/f5.rb) * Any module that defines constants inside of the Puppet ruby module. # Initial Proposal # As an initial proposal to put a band aid on the bullet wound we have, we should reserve Puppet::Modules as a namespace for 3rd party modules. Puppet should have a place holder lib/puppet/modules.rb file that defines `Puppet::Modules` as a ruby module and is otherwise an empty object. Puppet modules may then open this object and monkey patch it as they see fit. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
