The Puppet Labs Issue Tracker has Moved:

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using See the following page for information on filing tickets with JIRA:

Bug #14073

puppet apply cannot find types in modules on Windows

Added by Anonymous about 4 years ago. Updated over 3 years ago.

Status:DuplicateStart date:04/18/2012
Priority:NormalDue date:
Assignee:Patrick Carlisle% Done:


Target version:-
Affected Puppet version:2.7.4 Branch:
Keywords:autoloader windows module load_path LOAD_PATH RUBYLIB autoload require bd

We've Moved!

Ticket tracking is now hosted in JIRA:



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.

Actual Behaivor

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 \
Could not autoload Z:/vagrant/modules/mount_providers/lib/puppet/provider/mountpoint/linux.rb: \
  no such file to load -- puppet/type/mountpoint

Expected Behavior

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.

Related issues

Related to Puppet - Bug #12101: Autoloader class should check path with Puppet::Util::abs... Closed 01/23/2012
Related to Puppet - Feature #12126: make autoloader able to reload changed plugins Closed 01/24/2012
Related to Puppet - Bug #14074: libdir setting is honored on the command line but not in ... Closed 04/18/2012
Related to Puppet - Feature #4248: Load "library" plugins that are used by multiple puppet f... Accepted 07/15/2010
Related to Puppet - Bug #3947: puppet executable does not load all ruby files from modul... Duplicate 06/06/2010
Related to Puppet - Bug #16651: Installing the cloud provisioner module breaks the node s... Duplicate 10/01/2012
Related to Puppet - Bug #11930: Must use forward slashes when specifying a local modulepa... Closed 01/12/2012
Duplicates Puppet - Bug #7316: puppet face applications (subcommands) delivered via modu... Closed 05/02/2011


#1 Updated by Anonymous about 4 years ago

  • Affected Puppet version changed from 2.7.14rc1 to 2.7.4

The earliest affected version I found is 2.7.4.

It didn’t work at all before this point, not being able to find any of the types in the module.

#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.

#3 Updated by Patrick Carlisle about 4 years ago

This has never worked on any platform. (#4248, #3947)

I don’t think we intend to support it any time soon.

#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?”


#5 Updated by Patrick Carlisle about 4 years ago

As far as I know you can’t do this in a master/agent set up either.

#6 Updated by Nan Liu over 3 years ago

  • Keywords changed from autoloader windows module load_path LOAD_PATH RUBYLIB autoload require to autoloader windows module load_path LOAD_PATH RUBYLIB autoload require bd

#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.

#8 Updated by Anonymous over 3 years ago

  • Target version deleted (2.7.x)

Also available in: Atom PDF