BUILDR-403 describes this issue and includes a patch that introduces a
spec for the current functionality. It's not an ideal unit test as it
may need to go online, but it's the best I could come up with for this
bit of functionality.
The fix is described in the description of the issue.
Pepijn
On 16/3/2010 17:18, Antoine Toulme wrote:
Sure. If you file a bug with a patch, we will try to apply it and work on a
spec.
On Tue, Mar 16, 2010 at 03:44, Pepijn Van Eeckhoudt<
[email protected]> wrote:
When declaring required gems via build.yml buildr claims the gems in
question cannot be located. It seems this is due to use of old rubygems api
in util.rb. Currently at line 129 it uses SourceCacheIndex to find gems.
This reports that it can't find any gems. I inspected the index files that
this command retrieves from the gem servers and this effectively only
contains a single gem.
I then checked the gem query command source code and it turns out there a
newer class, SpecFetcher, is used instead of SourceCacheIndex. A discussion
on the rubygems-developers list (
http://www.mail-archive.com/[email protected]/msg02087.html)
seems to conclude that the SourceCacheIndex stuff should not be used
anymore.
I replaced line 129 with a line I derived from the query command source:
remote = dependencies.map{ |dep| Gem.source_index.search(dep).last ||
Gem::SpecFetcher.fetcher.fetch( dep, true ).map{ |spec, source| spec }.last
}
After this change gem searching and retrieval works correctly.
So, should the gem autoinstallation stuff be updated?
Pepijn
--
Pepijn Van Eeckhoudt - Project Leader
T +32 16 23 95 91
F +32 16 29 34 22 | [email protected]
LUCIAD - high performance visualization
Wetenschapspark Arenberg | Gaston Geenslaan 9
3001 Leuven | Belgium | www.luciad.com
