Re: [PATCH] Add rubygems updater.

[Ben Woodcroft]

On 02/01/16 04:17, Ludovic Courtès wrote:
> Ben Woodcroft <address@hidden> 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.

ben