|
From: | Ben Woodcroft |
Subject: | Re: [PATCH] Add rubygems updater. |
Date: | Sun, 3 Jan 2016 10:50:07 +1000 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
On 03/01/16 06:54, Ludovic Courtès wrote:
I have only been adding these in cases where testing is impossible, but we could make it a wider policy.Ben Woodcroft <address@hidden> skribis: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.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?
We could bake it into the build system, by adding an optional argument #:import so that you could do
(build-system ruby-build-system) (arguments `(#:import "ansi" #:tests? #f)) ; tests require circular dependenciesProbably in that case makes sense to have a new phase 'check-import so that more complex cases can be handled, rather than replacing 'check. There's no way to run this phase with the native-inputs disappeared is there so it more closely mirrors a user's experience?
We could even default this to the expected name of the library guessed from the name of the package when #:import is not given. However, this would unfortunately break packages that have been written outside of Guix, so I imagine you don't feel this is a good idea.
WDYT? Thanks, ben
[Prev in Thread] | Current Thread | [Next in Thread] |