[Top][All Lists]

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

Re: Optional runtime dependencies in Guix

From: 宋文武
Subject: Re: Optional runtime dependencies in Guix
Date: Mon, 12 Jan 2015 21:11:36 +0800
User-agent: Notmuch/0.18.1 ( Emacs/24.4.1 (x86_64-unknown-linux-gnu)

Ludovic Courtès <address@hidden> writes:

> Gammel Holte <address@hidden> skribis:
>> For example, consider samtools, a package I use daily and that was recently
>> committed to Guix:
>> It forces me to install python. In contrast, consider Arch AUR's package:
> From looking at the page above, it seems that it would be feasible to
> simply move 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'.

Note that 'python' is not a build dependency of 'samtools', so we
can only patch '#!/usr/bin/env' but not 'python' for
Then we should give recommends or suggests, user need it could
install python manually.
>> An extreme example of this is weechat:
>> Compare with:
>> 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).
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)
      `(("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)'
> 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’.

reply via email to

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