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:
puppet apply cannot find types in modules on Windows
|Assignee:||Patrick Carlisle||% Done:|
|Affected Puppet version:||2.7.4||Branch:|
|Keywords:||autoloader windows module load_path LOAD_PATH RUBYLIB autoload require bd|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
With Puppet 2.7.x (3a4ac604c85952511fd45c2f0699ce956eda3773) and master (b02aa930a03a282588e81f65e14f47a138a4b9f0) Puppet is not able to find custom types and providers located in a module.
This appears to be a regression.
With the mount_providers module installed in the module path, there is an error because the type uses a require statement and the $LOAD_PATH is not correct:
Z:\vagrant\modules>puppet describe --modulepath=Z:/vagrant/modules mounttab Could not run: Could not autoload \ Z:/vagrant/modules/mount_providers/lib/puppet/type/mountpoint.rb: Could not autoload Z:/vagrant/modules/mount_providers/lib/puppet/provider/mountpoint/linux.rb: \ no such file to load -- puppet/type/mountpoint
The custom type in the mount providers module should be able to require additional files with the $LOAD_PATH modified to include the lib directory of the module from the module path.
Steps to reproduce¶
Install Puppet 2.7.13 from our MSI.
Modify environment.bat to use PUPPET_DIR and FACTER_DIR pointing at your Git working copies.
Install the mount_providers module somewhere.
Use puppet describe —modulepath=Z:/path/to/modules mountpoint
See the exception raised.
This happens on both 2.7.x and master.
#2 Updated by Anonymous about 4 years ago
- Status changed from Unreviewed to Investigating
- Assignee changed from Anonymous to Patrick Carlisle
So, the desired behaviour is that the agent and apply always pluginsync, which means that all library code included on the module path winds up in the Ruby load_path on the agent. This, obviously, only applies to Master where we have worked on that – and if that fails, is a separate bug.
Patrick, can you confirm my understanding and, if this highlights an actual bug, create a new ticket to track that?
For 2.7, this isn’t going to be fixed. It is also the case that we cannot, within the bounds of reason, support this in a real and useful fashion on the master. There is no way to have multiple versions of the support code loaded in a single Ruby process, so you will always get the “pick a random environment and use only that” version of the support code when you are on a master with environments enabled.
In that world, I wonder if the better strategy might be to avoid the support code entirely for now? For Waldorf we may have a better story about this, and possibly even inside Telly, but … not yet.
#4 Updated by Anonymous about 4 years ago
On Tuesday, April 24, 2012, wrote:
Issue #14073 has been updated by Patrick Carlisle.
This has never worked on any platform.
OK that just means the bug isn’t a regression, right?
4248¶ <#136e5bc49e374d74_4248> 3947¶ <#136e5bc49e374d74_3947>
I don’t think we intend to support it any time soon.
I certainly intend to support it. You agree it’s a bug, right? We say we support modules with puppet apply…
Puppet apply should work just as well as puppet agent and if it doesn’t we should fix it.
Or are we just using different semantics around the word “support?”
#7 Updated by Josh Cooper over 3 years ago
- Status changed from Investigating to Duplicate
This issue has two parts. The ability for
puppet apply to autoload a module, and have that module require utility code. This will be fixed in #7316.
The second part is autoloading modules on Windows. In 2.7.x, you used to have to specify the module path using forward slashes (#11930). This was fixed in 2.7.x in f9a6337 . Then improvements were made to the autoloader in 3.0.0 to canonicalize paths on Windows correctly in de8ade81a.
Since this issue is about autoloaded modules requiring utility code, I am closing this as a duplicate of #7316.