Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
(#14149) Reserve the Puppet::Modules namespace #704
Without this patch there is no reserved place for 3rd party modules to
This patch fixes the problem by reserving the Puppet::Modules namespace
It doesn't feel like this is the right direction to me.
It adds extra terms to the namespace, but does nothing to make it harder for code to collide under the hood - you can just as well defined
It also doesn't exempt you from breakage around other changes in Puppet; there are lots of ways other than conflicting names that we can break things for these extensions. They really do need to keep up with changes in the core, rather than hoping that by pushing things off to the side they can stay "working" while the world changes radically around them.
This wouldn't really have helped in the current case, either, since the initial merge was done by taking the existing module and making as few changes as possible to it. There is no reason someone would think that they shouldn't put it under this namespace any more than they would have noticed the conflict when it wasn't present.
@daniel-pittman What is an alternative you suggest?
We're already opening up
Should every 3rd party puppet module define and re-define Puppet::Modules as a module?
@jeffmccune - third party modules have an almost infinitely large space to put their things; everything that doesn't start with "::Puppet" as the top level is entirely available to them. Even inside Puppet they have an almost infinitely large space available too - anything that isn't used. "::Puppet::Hiera", or "::Puppet::RandomStuff" are just as safe as the top level, or something in your namespace.
This doesn't solve anything of value: if "anything goes", third party work can tread on third party work, without any more assurance than we had before.
Ultimately, this isn't a direction I think is of any long term value to the platform. It doesn't address enough to justify the cost, and doesn't actually solve the problem highlighted - just makes it more unlikely.
Much better that third parties are aware of this and build their code outside our namespace, just like every other Ruby project works in the wild.