Problems with Set after upgrade to RSpec 1.2.9

Testing RSpec
1

It seems RSpec 1.2.9 is be breaking my specs in an interesting way
(both under Ruby 1.8.7 and 1.9.1). The problem may very well be in
my non-standard approach to monkey-patching core/stdlib classes,
but my approach does work with RSpec 1.2.8 and prior, as well as
in different Ruby implementations…

If you checkout my art-decomp project from
GitHub - chastell/art-decomp and you
‘rake spec’ the master branch under Ruby 1.9.1
or the ruby-1.8-compat branch under Ruby 1.8.7
the result should be a short, happily green run
of 114 tests – and it is if you use RSpec 1.2.8.

Unfortunately, with RSpec 1.2.9 I get the two following results (first
Ruby 1.9.1 on master, then Ruby 1.8.7 on the ruby-1.8-compat branch):

shot@devielle:~/PhD/art-decomp$ rake spec
(in /home/shot/PhD/art-decomp)
/home/shot/PhD/art-decomp/lib/set.rb:5:in <class:Set>': undefined method []’ for Set:Class (NoMethodError)
from /home/shot/PhD/art-decomp/lib/set.rb:1:in <top (required)>' from /home/shot/PhD/art-decomp/lib/art-decomp.rb:18:in require’
from /home/shot/PhD/art-decomp/lib/art-decomp.rb:18:in <top (required)>' from /home/shot/PhD/art-decomp/spec/spec_helper.rb:4:in require’
from /home/shot/PhD/art-decomp/spec/spec_helper.rb:4:in <top (required)>' from /home/shot/.gem/ruby/1.9.1/gems/rspec-1.2.9/lib/spec/runner/option_parser.rb:149:in require’
from
/home/shot/.gem/ruby/1.9.1/gems/rspec-1.2.9/lib/spec/runner/option_parser.rb:149:in
block in invoke_requires' from /home/shot/.gem/ruby/1.9.1/gems/rspec-1.2.9/lib/spec/runner/option_parser.rb:148:in each’
from
/home/shot/.gem/ruby/1.9.1/gems/rspec-1.2.9/lib/spec/runner/option_parser.rb:148:in
invoke_requires' from /home/shot/.gem/ruby/1.9.1/gems/rspec-1.2.9/lib/spec/runner/option_parser.rb:104:in block in initialize’
from
/home/shot/.rvm/ruby-1.9.1-p243/lib/ruby/1.9.1/optparse.rb:1271:in
call' from /home/shot/.rvm/ruby-1.9.1-p243/lib/ruby/1.9.1/optparse.rb:1271:in block in parse_in_order’
from
/home/shot/.rvm/ruby-1.9.1-p243/lib/ruby/1.9.1/optparse.rb:1258:in
catch' from /home/shot/.rvm/ruby-1.9.1-p243/lib/ruby/1.9.1/optparse.rb:1258:in parse_in_order’
from
/home/shot/.rvm/ruby-1.9.1-p243/lib/ruby/1.9.1/optparse.rb:1252:in
order!' from /home/shot/.gem/ruby/1.9.1/gems/rspec-1.2.9/lib/spec/runner/option_parser.rb:132:in order!’
from
/home/shot/.gem/ruby/1.9.1/gems/rspec-1.2.9/lib/spec/runner.rb:51:in
options' from /home/shot/.gem/ruby/1.9.1/gems/rspec-1.2.9/lib/spec/runner/command_line.rb:6:in run’
from /home/shot/.gem/ruby/1.9.1/gems/rspec-1.2.9/bin/spec:5:in
`’
rake aborted!
Command /home/shot/.rvm/ruby-1.9.1-p243/bin/ruby -I"lib"
“/home/shot/.gem/ruby/1.9.1/gems/rspec-1.2.9/bin/spec”
“spec/set_spec.rb” “spec/string_spec.rb” “spec/enumerable_spec.rb”
“spec/file_spec.rb” “spec/art-decomp/graph_spec.rb”
“spec/art-decomp/logging_spec.rb” “spec/art-decomp/arch_spec.rb”
“spec/art-decomp/fsm_spec.rb” “spec/art-decomp/sep_spec.rb”
“spec/art-decomp/bipainter_spec.rb” “spec/art-decomp/blanket_spec.rb”
“spec/art-decomp/kiss_spec.rb”
“spec/art-decomp/qv_generator/graph_colouring_spec.rb”
“spec/art-decomp/qv_generator/bipainting_spec.rb”
“spec/art-decomp/qv_generator/graph_merging_spec.rb”
“spec/art-decomp/executable_spec.rb”
“spec/art-decomp/decomposer_spec.rb”
“spec/art-decomp/qu_generator/edge_labels_spec.rb”
“spec/art-decomp/qu_generator/block_table_spec.rb”
“spec/art-decomp/uv_generator/relevance_spec.rb”
“spec/art-decomp/uv_generator/braindead_spec.rb”
“spec/art-decomp/decomposition_spec.rb” “spec/art-decomp/b_spec.rb”
“spec/integer_spec.rb” --options spec/spec.opts failed

(See full trace by running task with --trace)
shot@devielle:~/PhD/art-decomp$

shot@devielle:~/PhD/art-decomp$ rake spec
(in /home/shot/PhD/art-decomp)
./lib/set.rb:5: undefined method []' for Set:Class (NoMethodError) from /home/shot/.rvm/ruby-1.8.7-p174/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in gem_original_require’
from
/home/shot/.rvm/ruby-1.8.7-p174/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
require' from ./lib/art-decomp.rb:39 from /home/shot/.rvm/ruby-1.8.7-p174/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in gem_original_require’
from
/home/shot/.rvm/ruby-1.8.7-p174/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
require' from ./spec/spec_helper.rb:4 from /home/shot/.rvm/ruby-1.8.7-p174/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in gem_original_require’
from
/home/shot/.rvm/ruby-1.8.7-p174/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
require' from /home/shot/.gem/ruby/1.8.7/gems/rspec-1.2.9/lib/spec/runner/option_parser.rb:149:in invoke_requires’
from
/home/shot/.gem/ruby/1.8.7/gems/rspec-1.2.9/lib/spec/runner/option_parser.rb:148:in
each' from /home/shot/.gem/ruby/1.8.7/gems/rspec-1.2.9/lib/spec/runner/option_parser.rb:148:in invoke_requires’
from
/home/shot/.gem/ruby/1.8.7/gems/rspec-1.2.9/lib/spec/runner/option_parser.rb:104:in
initialize' from /home/shot/.rvm/ruby-1.8.7-p174/lib/ruby/1.8/optparse.rb:1267:in call’
from /home/shot/.rvm/ruby-1.8.7-p174/lib/ruby/1.8/optparse.rb:1267:in
parse_in_order' from /home/shot/.rvm/ruby-1.8.7-p174/lib/ruby/1.8/optparse.rb:1254:in catch’
from /home/shot/.rvm/ruby-1.8.7-p174/lib/ruby/1.8/optparse.rb:1254:in
parse_in_order' from /home/shot/.rvm/ruby-1.8.7-p174/lib/ruby/1.8/optparse.rb:1248:in order!’
from
/home/shot/.gem/ruby/1.8.7/gems/rspec-1.2.9/lib/spec/runner/option_parser.rb:132:in
order!' from /home/shot/.gem/ruby/1.8.7/gems/rspec-1.2.9/lib/spec/runner.rb:51:in options’
from
/home/shot/.gem/ruby/1.8.7/gems/rspec-1.2.9/lib/spec/runner/command_line.rb:6:in
`run’
from /home/shot/.gem/ruby/1.8.7/gems/rspec-1.2.9/bin/spec:5
rake aborted!
Command /home/shot/.rvm/ruby-1.8.7-p174/bin/ruby -I"lib"
“/home/shot/.gem/ruby/1.8.7/gems/rspec-1.2.9/bin/spec”
“spec/set_spec.rb” “spec/string_spec.rb” “spec/enumerable_spec.rb”
“spec/file_spec.rb” “spec/art-decomp/graph_spec.rb”
“spec/art-decomp/logging_spec.rb” “spec/art-decomp/arch_spec.rb”
“spec/art-decomp/fsm_spec.rb” “spec/art-decomp/sep_spec.rb”
“spec/art-decomp/bipainter_spec.rb” “spec/art-decomp/blanket_spec.rb”
“spec/art-decomp/kiss_spec.rb”
“spec/art-decomp/qv_generator/graph_colouring_spec.rb”
“spec/art-decomp/qv_generator/bipainting_spec.rb”
“spec/art-decomp/qv_generator/graph_merging_spec.rb”
“spec/art-decomp/executable_spec.rb”
“spec/art-decomp/decomposer_spec.rb”
“spec/art-decomp/qu_generator/edge_labels_spec.rb”
“spec/art-decomp/qu_generator/block_table_spec.rb”
“spec/art-decomp/uv_generator/relevance_spec.rb”
“spec/art-decomp/uv_generator/braindead_spec.rb”
“spec/art-decomp/decomposition_spec.rb” “spec/art-decomp/b_spec.rb”
“spec/integer_spec.rb” --options spec/spec.opts failed

(See full trace by running task with --trace)
shot@devielle:~/PhD/art-decomp$

I guess the problem is my way of monkey-patching the Set class;
I first ‘require 'set’’ to get the stdlib’s Set, and then
‘require_relative 'lib/set’’ to get my patches. But this approach
works in RSpec 1.2.8 and in all other applications of my code…

Any insight on whether I should fix my code or
is this a bug in RSpec would be most appreciated.

— Shot, who’s back to RSpec 1.2.8 for now

2

On Oct 10, 2009, at 5:54 PM, Shot (Piotr S.) wrote:

the result should be a short, happily green run
from /home/shot/PhD/art-decomp/lib/set.rb:1:in <top (required)>' from /home/shot/.gem/ruby/1.9.1/gems/rspec-1.2.9/lib/spec/runner/ 1258:incatch’
from /home/shot/.gem/ruby/1.9.1/gems/rspec-1.2.9/bin/spec:5:in
qv_generator/bipainting_spec.rb" "spec/art-decomp/qv_generator/

rubygems/custom_require.rb:31:in gem_original_require' option_parser.rb:148:ineach’
from /home/shot/.rvm/ruby-1.8.7-p174/lib/ruby/1.8/optparse.rb:
rake aborted!
art-decomp/decomposer_spec.rb" "spec/art-decomp/qu_generator/
I guess the problem is my way of monkey-patching the Set class;
I first ‘require ‘set’’ to get the stdlib’s Set, and then
‘require_relative ‘lib/set’’ to get my patches. But this approach
works in RSpec 1.2.8 and in all other applications of my code…

Any insight on whether I should fix my code or
is this a bug in RSpec would be most appreciated.

Hey Shot -

RSpec 1.2.9 adds ./lib and ./spec (from the project root) to the load
path. So it sounds it’s loading your custom ‘set’ before the one in
stdlib.

I’ve run into load order problems like this before, and found that the
safest bet is to have the extension at a different path than that of
the core lib. So in this case, I’d recommend putting the ‘set’
extensions in ./lib/extensions/set (or something similar - anything
other than ./lib/set), and then require ‘set’ from that file.

WDYT?

David

3

On Sat, Oct 10, 2009 at 10:16 PM, David C. [email protected]
wrote:

‘rake spec’ the master branch under Ruby 1.9.1
/home/shot/PhD/art-decomp/lib/set.rb:5:in <class:Set>': undefined method from block in initialize’
from
“/home/shot/.gem/ruby/1.9.1/gems/rspec-1.2.9/bin/spec” “spec/set_spec.rb”
“spec/art-decomp/qu_generator/block_table_spec.rb”
(in /home/shot/PhD/art-decomp)
gem_original_require' from initialize’
from
“/home/shot/.gem/ruby/1.8.7/gems/rspec-1.2.9/bin/spec” “spec/set_spec.rb”
“spec/art-decomp/qu_generator/block_table_spec.rb”
I first ‘require ‘set’’ to get the stdlib’s Set, and then

I’ve run into load order problems like this before, and found that the
safest bet is to have the extension at a different path than that of the
core lib. So in this case, I’d recommend putting the ‘set’ extensions in
./lib/extensions/set (or something similar - anything other than ./lib/set),
and then require ‘set’ from that file.

WDYT?

FYI - from
http://weblog.rubyonrails.org/2009/9/1/gem-packaging-best-practices:

It may seem harmless to call files whatever you’d like in your package because you are “namespaced” in your own package. But if lib/ is prepended to $LOAD_PATH it will clobber Ruby’s built in erb and set libs. require 'erb' would no longer require Ruby’s builtin erb library, but this package’s version of it.

The safe (and correct) way would be to namespace your files under
another directory. Its conventional to create a folder within lib with
the same name as your gem. Then we would put all our dependency files
under lib/foo/ instead of at lib/ root.

I agree, and I think this applies to extensions to stdlib and core
classes as I mentioned in my previous post.

4

David C.:

RSpec 1.2.9 adds ./lib and ./spec (from the project root) to the load
path. So it sounds it’s loading your custom ‘set’ before the one in
stdlib.

That would explain that backtrace. Thanks for the clarification!

I’ve run into load order problems like this before, and found that
the safest bet is to have the extension at a different path than that
of the core lib. So in this case, I’d recommend putting the ‘set’
extensions in ./lib/extensions/set (or something similar - anything
other than ./lib/set), and then require ‘set’ from that file.

I was waiting a bit to see whether there emerges any common naming of
the directory carrying patches for core/stdlib classes (core? base?
core-ext? stdlib?) before breaking my ‘file path maps 1:1 to class name’
rule. But you’re right that having ‘require 'set’’ and ‘require_relative
'setՉ۪ next to each other and actually wanting them to load two
different files does not feel like following the path of least surprise.

FYI - from http://weblog.rubyonrails.org/2009/9/1/gem-packaging-best-practices:

It may seem harmless to call files whatever you’d like in your package because you are “namespaced” in your own package. But if lib/ is prepended to $LOAD_PATH it will clobber Ruby’s built in erb and set libs. require 'erb' would no longer require Ruby’s builtin erb library, but this package’s version of it.

The safe (and correct) way would be to namespace your files under
another directory. Its conventional to create a folder within lib
with the same name as your gem. Then we would put all our dependency
files under lib/foo/ instead of at lib/ root.

I agree, and I think this applies to extensions to stdlib
and core classes as I mentioned in my previous post.

Ah, right – I actually remembered reading
this somewhere, but forgot the source. Thanks!

— Shot