guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add rubygems updater.


From: Ben Woodcroft
Subject: Re: [PATCH] Add rubygems updater.
Date: Tue, 5 Jan 2016 23:57:47 +1000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0



On 04/01/16 00:06, Ludovic Courtès wrote:
Ben Woodcroft <address@hidden> skribis:

On 03/01/16 06:54, Ludovic Courtès wrote:
Ben Woodcroft <address@hidden> skribis:

On 02/01/16 04:17, Ludovic Courtès wrote:
Ben Woodcroft <address@hidden> skribis:
[...]

+     `(#: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?
I have only been adding these in cases where testing is impossible,
but we could make it a wider policy.

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 dependencies
The problem is that the “-Ilib” in the command above cannot be guessed,
can it?
My understanding is that the the "-Ilib" is almost invariant because putting imported code in the lib subdirectory is a convention that most gems adhere to. In those cases where it fails, the 'check-import phase can be replaced or removed.

[..]
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.
We could choose the package name as a default value, but often that’s
not going to work, notably because of the “ruby-” prefix.

WDYT?
Removing the "ruby-" from the package name sounds like a reasonable default, but won't work every time because some imports use underscores where some use dashes e.g. "minitest-pretty_diff".

I'm keen to make sure you understand what I'm attempting to say though. By "default" I mean when the #:import flag is missing from arguments, "ruby -Ilib -r <guessed_package_name>" will be run. So if I have previously packaged a rubygem outside Guix and it is working fine, implementing the default might break my package making me unhappy. If you instead interpreted "default" as the guessed value that "guix import" generates, then that is less likely to end in unhappiness.

WDYT?

Thanks,
ben



reply via email to

[Prev in Thread] Current Thread [Next in Thread]