| I did not run into any specific problem per se. I more or less stumbled into the namespacing issue as described in PUP-3922 during refactoring of a module.
I have a class that wraps mutliple things together for usability, some of these components are other classes of the module, some are built in a provider type fassion. The resulting construct therefore reads inconsistent and is not easy to maintain, as you have to check what resources/types/classes are provided by puppet directly or the own module or even other modules. Clashing "duplicate" declarations as described in the mentioned issue are another sideeffect of the lack of namespacing. Lets say we have two environments, each loads module A which provides the type and provider "owntype" and uses the type actively. Now we add another module B which also provides "owntype". Due to the way the classes are loaded, Bs "owntype" theoretically might get preverence over As "owntype" in As own implementation (this is the part I havent tested). This could result in different behaviour of the same module that is very hard to debug and possibly impossible to resolve from a users perspective, simply because these modules could be thirdparty and needed by different teams for example. At the same time, I dont think this is a huge problem currently as provider type definitions are "rare" compared to class definitions and the names of the providers in practices mostly are so specific the chance of accidental duplication is near zero. The biggest benefit would probably be consistency.
But it is something that should be kept in mind and possibly changed at some point. If that point is any time soon and if the work needed is worth it, I dont know. |
