The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Warn when multiple versions of the same module are available in the modulepath
|Status:||Needs Decision||Start date:|
|Assignee:||eric sorenson||% Done:|
|Affected Puppet version:||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
The module tool tries to prevent multiple versions of the same module from being installed. But there are lots of ways that you can end up in that state, such as by installing a module using a specific modulepath (puppet module install —modulepath dirA)
Then if the master is configured to use multiple modulepaths, modulepath=dirA:dirB, you can easily end up with multiple versions of the same module. This can cause unexpected breakage if the version in dirA is incompatible with respect to the one in dirB, especially when the module, e.g. stdlib, is a dependency shared by multiple modules.. See #18525.
One simple thing to assist debugging this situation would be to issue a warning on the master if there are multiple versions of the same module accessible in its modulepath.
#1 Updated by Roger Kennedy almost 3 years ago
- Status changed from Unreviewed to Needs Decision
I have verified that this is true, however the behavior does not surprise me. The semantic of
modulepath is the same as
PATH in *NIX systems: when looking for a thing, check the PATH in order and use the first thing found.
There is nothing in
--debug on master or agent to indicate where in the modulepath a module was found. However, I think the real issue is #12173. If you could reliably distinguish between different versions of modules, having a “first one found wins” model becomes less problematic.
It may still be prudent to enhance
withpath to provide a “fully-qualified” path including the modules directory used. This could also be useful debugging environments, as a site with multiple/complex environments is probably using custom modulepaths for the environments.
#2 Updated by Ryan Coleman almost 3 years ago
- Assignee set to eric sorenson
The Puppet Module Tool does have a
list action that will give you information about all the modules it finds in the modulepath(s) configured in puppet.conf and allows you to specify a list of modulepaths that you wish to inspect. While obviously this doesn’t provide pro-active warnings, it is a built in tool that can help an administrator determine what’s installed.
I think this ticket ought to be closed. Passing to eric0 for review.