diff options
author | Sam Thursfield <sam.thursfield@codethink.co.uk> | 2014-11-19 17:05:13 +0000 |
---|---|---|
committer | Sam Thursfield <sam.thursfield@codethink.co.uk> | 2014-11-20 12:49:33 +0000 |
commit | 6ebb2acda528ebd324dd74cb0ab2521f2e4aca6f (patch) | |
tree | 96a68f32cdc0cbec96ecf9a2e050f741c77e994e /README.omnibus | |
parent | a2c496c14ef31c64a8f40083a6aee929ca0ff521 (diff) | |
download | import-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 'README.omnibus')
0 files changed, 0 insertions, 0 deletions