Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=646836 --- Comment #13 from Mohammed Morsi <mmorsi@xxxxxxxxxx> 2011-01-25 12:51:25 EST --- Hey Jozef, Vit thanks for the work on this so far. Is this package under official review, Jozef why did you flag fedora-review for a package you submitted? I can do the official review if noone else claimed it yet. Regardless, I spent some time looking into the vendor'd thor issue, and luckily I think there is a way we can get around this. We might not need to though, as it seems removing the vendor directory will not affect the bundler runtime, just the test suite. Problems just running the test suite in the spec aren't blockers, as functionality can be independently verified on release / updates. I've verified thor is loaded correctly when bundler is used via an rpm install with the vendor directory removed, and that rails 3 builds and works fine ontop of it. In any case the issue when running the spec suite after removing the vendor directory occurs because bundler foobars the ruby load_path and the rubygem load process in order to do its thing. Thus in lib/bundler/gem_helper.rb and lib/bundler/cli.rb, the "require 'thor'" relies on the vendor directory added to the load path and fails. The thing when running the spec suite, rspec is loaded successfully. It is able to because the rspec library itself modifies the load path (at least rspec 2 does), appending the /usr/lib/ruby/gems/1.8/gems/rspec-* directories. So to get thor to load correctly in this situation, we need to modify the load path as well. So before the "require 'thor'" in cli.rb and gem_helper.rb, comment out the bit adding the vendor directory and add $:.unshift "/usr/lib/ruby/gems/1.8/gems/thor-0.14.6/lib" Now obviously this isn't an optimal solution (or even an acceptable one) due to the inclusion of the hard coded path. We can get some support from ruby itself to replace some of the fixed components, for example the Config::CONFIG hash (available via the 'rbconfig' module) can be leveraged to give us some of the ruby installation directories, and perhaps we can use rpm itself to give us the thor install location. We can't use Gem.path though as bundler overwrites that during the setup process. Regardless, I've verified the spec suite and the package itself is working against the rubygem-thor package in Fedora (with the vendor directory removed). There are two errors (468 successes) in the test suite, but these also occur when the vendorized thor directory is used (we might be able to patch the spec suite to fix those two tests). Thus as you said, this non-inclusion of the test suite is not a blocker. I will officially review this package soon if noone else has claimed it first. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review