Re: [PATCH] Update Ruby to 2.3.0

[Ben Woodcroft <b.woodcroft@uq.edu.au>]

On 11/01/16 07:14, Ludovic Courtès wrote:
> Ben Woodcroft <b.woodcroft@uq.edu.au> skribis:
>
>>  From 2f26295b5a163cfc5d37332a501dcba5c40fb956 Mon Sep 17 00:00:00 2001
>> From: Ben Woodcroft <donttrustben@gmail.com>
>> Date: Mon, 4 Jan 2016 09:38:42 +1000
>> Subject: [PATCH 5/5] gnu: ruby: Update to 2.3.0.
>>
>> * gnu/packages/ruby.scm (ruby): Update to 2.3.0.
>> [arguments]: Remove bundled libffi.  Use parallel tests.
>> (ruby-2.2): New variable.
> [...]
>
>> +             ;; Remove bundled libffi
>> +             (delete-file-recursively
>> +              (string-append "ext/fiddle/libffi-3.2.1"))
> I should have mentioned it before, but could you move the removal to a
> ‘snippet’ in the origin?
All pushed to core-updates with a snippet and minor formatting changes.
>>  From 015a0e17be804dd7f68f21cde8a878ff353a4a97 Mon Sep 17 00:00:00 2001
>> From: Ben Woodcroft <donttrustben@gmail.com>
>> Date: Fri, 8 Jan 2016 17:29:39 +1000
>> Subject: [PATCH 3/5] ruby: Abstract out path to GEM_HOME.
>>
>> Previously paths to the GEM_HOME of certain Ruby packages were
>> hard-coded, so packages failed to build when Ruby was updated to 2.3.0.
>>
>> * guix/build/ruby-build-system.scm (gem-home): New procedure.
>> * gnu/packages/ruby.scm (ruby-metaclass, ruby-instantiator,
>> ruby-introspection, ruby-mocha, ruby-minitest-tu-shim): Use it.
> LGTM.
>
> However, ultimately, we should pass the Ruby version as a keyword
> parameter on the build side or have a build-side procedure akin to
> ‘get-python-version’ in python-build-system.scm (I’d prefer the former.)
>
> That way, phases could query the version number of the Ruby that’s
> actually used instead of using the version number of whatever variant
> the global ‘ruby’ variable refers to.  This would allow users to simply
> change the “ruby” input of a package and have it automatically work with
> the new package.
>
> Does that make sense?
>
> This can always be done after the ‘core-updates’ merge, no rush.
OK then. I reckon we should provide a procedure to get to the lib/ 
directory as well, based on the upstream name property too. Then we can 
use it for the require test too.

Thanks,
ben