Re: Optional runtime dependencies in Guix

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

宋文武 <iyzsong@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Gammel Holte <gammel.holte@gmail.com> skribis:
>>
>>> For example, consider samtools, a package I use daily and that was recently
>>> committed to Guix:
>>>
>>> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bioinformatics.scm#n139
>>>
>>> It forces me to install python. In contrast, consider Arch AUR's package:
>>>
>>> https://aur.archlinux.org/packages/samtools/
>>
>> From looking at the page above, it seems that it would be feasible to
>> simply move varfilter.py to a different output.  That way, users would
>> be able to install the default output (which doesn’t depend on Python),
>> or the “python” output.  Ricardo, WDYT?
> Move it to a different output should work, but the 'python' output
> doesn't make much sense to me compare to 'doc', 'bin' and 'debug'.

Yeah, but I don’t see anything against using “python” as an output name.

> Note that 'python' is not a build dependency of 'samtools', so we
> can only patch '#!/usr/bin/env' but not 'python' for varfilter.py.
> Then we should give recommends or suggests, user need it could
> install python manually.

Right, that’s probably even simpler.

>>> An extreme example of this is weechat:
>>>
>>> http://lists.gnu.org/archive/html/guix-devel/2014-09/msg00229.html
>>>
>>> Compare with:
>>>
>>> https://www.archlinux.org/packages/extra/i686/weechat/
>>>
>>> Guix version forces the user to install all interpreters for running
>>> user-defined scripts to extend Weechat. These are quite many: lua, perl,
>>> python, ruby, tcl (and guile).
>>
>> Yes, I hadn’t noticed this and I agree this is problematic.
>>
>> Kevin, any idea on how to split things?
> This is total different, those plugins must live in $out/lib/plugins
> to work (can't move to seperated outputs).

OK.  This could be relaxed using an environment variable (say
LTDL_LIBRARY_PATH, if Weechat uses libltdl.)

> Keep in mind that interpreters are both build and runtime dependencies
> of weechat, the nature way is making them optional when building:
>
>   (define-public (%weechat #:key (python? #t)
>                                  (guile?  #t)
>                                 ...
>     (package
>       (inputs
>       `(("python" ,(if python? python #nil))
>         ("guile"  ,(if guile?  guile  #nil))
>     ...
>        
>
>   (define-public weechat (%weechat)) ; our default version
>
> Then user can install the customized version with:
>   $ guix package -e '((@ (gnu packages weechat) %weechat) #:python? #f)'

Yes, but it’s not very convenient.

To begin with, we could have a “weechat” package with a “reasonable”
option set:

  (define weechat
    (make-weechat "weechat"))

And possibly another variant with, say, all the options enabled:

  (define weechat-full
    (make-weechat "weechat-full" #:python? #t #:lua? #t))

This should satisfy most users and would be easily usable.  This is
already done for a few packages, notably Emacs and PETSc.  And then
demanding users can do as you suggest.

WDYT?


A long term possibility would be to officially support something like
Gentoo’s “USE” flags.  These would be declared as part of the package,
and the build process would take them into account somehow:

  (define weechat
    (package
      ...
      (inputs `(,@(if (package-option weechat 'guile)
                      `(("guile" ,guile))
                      '())
                ...))
      (arguments
        `(#:configure-flags ,(if (package-option weechat 'guile)
                                 '("--with-guile")
                                 '())))
      (options (list (option-specification
                       (name 'guile)
                       (description "Whether to support Guile plug-ins.")
                       (default #t))))))

And then:

  $ guix package --show-options weechat
  ...

  $ guix package -i weechat -o guile

How does that sound?

Thanks,
Ludo’.