puppetlabs/puppet — pull request #1656 by jpartlow (2013-05-20 19:22:45+00:00)
Title: (maint) More specific require for windows/package

PR1655 added "require 'puppet/type/package'" to fix a load order issue.
But this change is more general than what is needed, and we had not
tracked down exactly what was occurring.

I spent a little time running down the load order issue for
puppet/provider/package/windows/package. An example of the mystery
effect being that prior to PR#1655 the following sequence would pass:

bundle exec rspec spec/unit/provider/package/rpm_spec.rb
spec/unit/provider/package/windows/package_spec.rb

while the reverse order would fail:

bundle exec rspec spec/unit/provider/package/windows/package_spec.rb
spec/unit/provider/package/rpm_spec.rb

The reason for it is confusing, but turns out to be not very mysterious
or magical at least.

The summary is that because this was written as follows:

lib/puppet/provider/package/windows/package.rb
---
1 require 'puppet/util/windows'
2
3 class Puppet::Provider::Package::Windows

Puppet::Provider::Package is assumed, but not required. Since
Puppet::Provider is loaded as a result of the base require 'puppet', and
since it includes Puppet::Util, which has a Puppet::Util::Package, if
nothing else has explicitly created Puppet::Provider::Package, we
end up declaring the Windows class on Puppet::Util::Package and hiding
reference errors which should otherwise pop up here.

Requiring 'puppet/type/package' does end up also requiring
'puppet/provider/package' as part of type's autoloading magic, but this
patch more specifically and clearly fixes the issue by requiring
'puppet/provider/package'.

Consistency of namespacing and class loading is a deeper issue.