Issue #14149 has been updated by Andrew Parker.
Jeff and I just talked about this. Daniel is right that his doesn't solve the problem of people having safe sandboxes where their code cannot interfere with the code of other modules. However, it can be used to setup a convention whereby a well-behaved module has a known place that it can put things and no problems will arise *if they follow the convention*. The thing that bugs me about this convention as it stands, is that it places more code under the puppet namespace. I suggest that instead of Puppet::Modules we have PuppetX, which is a convention that I have seen used for extension code in other systems. The convention would then be that if you are writing a module called mysql you place your code (except for types, providers. and functions) under PuppetX::Mysql. If it was done this way, then there would be no need to reserve anything in the puppet codebase and this would be a thing of just publishing a convention that module authors should use and we should promote. ---------------------------------------- Feature #14149: The Puppet::Modules (or some other namespace) should be reserved for use by modules https://projects.puppetlabs.com/issues/14149#change-65063 Author: Jeff McCune Status: Needs More Information Priority: Normal Assignee: Jeff McCune 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.
