| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The way in which the require statements for the puppet/interface module
worked caused a dependency loop that could only be resolved by using the
modules and classes in a very specific order. The tests showed this
problem if they were run in a different order:
/export/home/jenkins/workspace/Puppet Specs Solaris (master)/solaris10-i386/solaris10-i386/lib/puppet/interface/action_builder.rb:128: uninitialized constant Puppet::Interface::Action (NameError)
from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require'
from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
from /export/home/jenkins/workspace/Puppet Specs Solaris (master)/solaris10-i386/solaris10-i386/lib/puppet/interface/action_manager.rb:2
from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require'
from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
from /export/home/jenkins/workspace/Puppet Specs Solaris (master)/solaris10-i386/solaris10-i386/lib/puppet/interface.rb:13
from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require'
from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
from /export/home/jenkins/workspace/Puppet Specs Solaris (master)/solaris10-i386/solaris10-i386/lib/puppet/interface/action.rb:1
from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require'
from /opt/csw/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
from /export/home/jenkins/workspace/Puppet Specs Solaris (master)/solaris10-i386/solaris10-i386/spec/unit/interface/action_spec.rb:3
from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/configuration.rb:746:in `load'
from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/configuration.rb:746:in `load_spec_files'
from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/configuration.rb:746:in `map'
from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/configuration.rb:746:in `load_spec_files'
from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/command_line.rb:22:in `run'
from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/runner.rb:69:in `run'
from /opt/csw/lib/ruby/gems/1.8/gems/rspec-core-2.9.0/lib/rspec/core/runner.rb:10:in `autorun'
from /opt/csw/bin/rspec:19
This re-orders the requires so that only the top level module
(Puppet::Interface) requires all of the components that are part of it.
Paired-with: patrick@puppetlabs.com
|
|
Without this patch Ruby 1.9 is still complaining loudly about trying to
parse the spec files. The previous attempt to clean up this problem in
edc3ddf works for Ruby 1.8 but not 1.9.
I'd prefer to remove the shebang lines entirely, but doing so will cause
encoding errors in Ruby 1.9. This patch strives for a happy middle
ground of convincing Ruby it is actually working with Ruby while not
confusing it to think it should exec() to rspec.
This patch is the result of the following command run against the source
tree:
find spec -type f -print0 | \
xargs -0 perl -pl -i -e 's,^\#\!\s?/(.*)rspec,\#! /usr/bin/env ruby,'
|
|
Without this patch some spec files are using `ruby -S rspec` and others
are using `rspec`.
We should standardize on a single form of the interpreter used for spec
files.
`ruby -S rspec` is the best choice because it correctly informs editors
such as Vim with Syntastic that the file is a Ruby file rather than an
Rspec file.
|
|
Add `display_global_options` to Face DSL.
Add `environment`, and `modulepath` as display_global_options for existing
module face.
Add `type` for typed settings.
Add display_global_options to exising help and man faces.
|
|
We accidentally omitted whitespace between multiple options while building the
synopsis. This fixes that, by introducing a breakable space in the right
location.
Additionally, we extract the code that was 99 percent identical from the face
and action synopsis generators, push it down into the documentation module,
and then invoke it from both places.
This eliminates the duplicate code, allowing me to fix that bug once and have
it apply to both parts of the code; this is pretty much assured to be true
any time we change the synopsis generation.
Reviewed-By: Nick Fagerlund <nick.fagerlund@puppetlabs.com>
|
