summaryrefslogtreecommitdiff
path: root/baserockimport/exts/rubygems.to_chunk
diff options
context:
space:
mode:
authorSam Thursfield <sam.thursfield@codethink.co.uk>2014-11-19 17:05:13 +0000
committerSam Thursfield <sam.thursfield@codethink.co.uk>2014-11-20 12:49:33 +0000
commit6ebb2acda528ebd324dd74cb0ab2521f2e4aca6f (patch)
tree96a68f32cdc0cbec96ecf9a2e050f741c77e994e /baserockimport/exts/rubygems.to_chunk
parenta2c496c14ef31c64a8f40083a6aee929ca0ff521 (diff)
downloadimport-6ebb2acda528ebd324dd74cb0ab2521f2e4aca6f.tar.gz
Fix rubygems.to_chunk failing when run inside `bundle exec`
By calling Bundler::Dsl.gemspec without specifying :path, this tool was causing the Bundler::Source::Path instance for the target .gemspec to be for path '.', which is relative path that is only valid inside one Dir.chdir block. It seems that all the Bundler resolution code runs inside that block and so there should be no problem, but unless we specify an absolute path for the gemspec then errors like this sometimes appear: /usr/lib/ruby/gems/2.0.0/gems/bundler-1.7.6/lib/bundler/resolver.rb:357:in `resolve': Could not find gem 'ffi-yajl (>= 0) ruby' in source at .. (Bundler::GemNotFound) Source does not contain any versions of 'ffi-yajl (>= 0) ruby' This normally happens when an Omnibus import chains to rubygems.to_chunk for a RubyGem component. The path is clearly valid at the time Bundler::Dsl.gemspec is called (otherwise it'd raise a Bundler::InvalidOption exception at the time) but not valid later (hence the error). Note that the second '.' in that error message is a full stop and not part of the path!
Diffstat (limited to 'baserockimport/exts/rubygems.to_chunk')
0 files changed, 0 insertions, 0 deletions