Gammel Holte <[email protected]> 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’.
