Re: [PATCH] Add rubygems updater.

[ludo@gnu.org (Ludovic Courtès)]

Ben Woodcroft <b.woodcroft@uq.edu.au> skribis:

> On 02/01/16 04:17, Ludovic Courtès wrote:
>> Ben Woodcroft <b.woodcroft@uq.edu.au> skribis:
>>
>>> On 01/01/16 19:28, Pjotr Prins wrote:
>>>> On Fri, Jan 01, 2016 at 06:27:21PM +1000, Ben Woodcroft wrote:
>>>>> It seems there's 30 packages to be updated, out of the 107 in
>>>>> ruby.scm. Going through each of these individually seems a little
>>>>> tedious, can we do them in bulk somehow or do they have to be
>>>>> committed individually? Building and testing all packages that
>>>>> require these packages would be a start - is there any way to list
>>>>> all dependent packages?
>>>>>
>>>>> gnu/packages/ruby.scm:2807:13: ruby-cutest would be upgraded from
>>>>> 1.2.2 to 1.2.3
>>>>> gnu/packages/ruby.scm:333:13: ruby-rspec-mocks would be upgraded
>>>>> from 3.2.1 to 3.4.0
>>>> (etc)
>>>>
>>>> I don't think it is a good idea to automatically update
>>>> packages. Reason being that packages should be updated by someone who
>>>> is actively using that new version. Automated tests are one thing,
>>>> real user feedback another. Not to mention that many gems don't have
>>>> tests ;).
>>> I think we should update the package definitions so that more have
>>> tests, and failing that import the library so we know it can at least
>>> be loaded, like this:
>>>
>>> +     `(#:phases
>>> +       (modify-phases %standard-phases
>>> +         (replace 'check
>>> +           (lambda _
>>> +             (zero? (system* "ruby" "-Ilib" "-r" "ansi")))))))
>> The only case where this would make a difference is for leaf packages,
>> no?  In all the other cases, building dependent packages will ensure
>> that the package at hand works as expected.
> Sure, but even in the case where they aren't leaf packages at least
> the build error gets thrown when building the package at
> fault. There's also the important difference that it makes the
> packager feel less bad about the disappointing lack of tests or the
> necessity of disabling them because of circular dependencies.

Right.  The only downside I can think of is if packagers have to copy
the above 4 lines in each and every package.  Can you think of a way
that would avoid that?

Ludo’.