Re: Optional runtime dependencies in Guix

[Ludovic Courtès]

Gammel Holte <address@hidden> 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?

> 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?

As I wrote before, there’s no one-size-fits-all recipe to address the
problem, just a couple of usable patterns (basically separate outputs or
separate packages.)  So we need to address this mostly on a case-by-case
basis, and also probably clarify this in the packaging guidelines.

Thanks,
Ludo’.