all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: "(" <paren@disroot.org>, guix-devel@gnu.org
Subject: Re: [RFC] package-with-features
Date: Fri, 25 Nov 2022 10:07:05 +0100	[thread overview]
Message-ID: <86bkovcshy.fsf@gmail.com> (raw)
In-Reply-To: <COKT41BWKD44.2C7MYSK8P9MIE@guix-framework>

Hi,

On Thu, 24 Nov 2022 at 20:26, "(" <paren@disroot.org> wrote:

> This comment by oriansj on IRC:
>
>   <oriansj> I am thinking in terms of gentoo builds and making
>   it easy to avoid some packages from being downloaded or built
>   like pulseaudio (I like alsa better) and trim down the dependencies
>   to only those that are absolutely directly required.
>
> made me wonder how we could incorporate such a feature into
> Guix.

Maybe, you could be interested by past discussions:

Parameterized packages (May 2019)
id:87woitz1xx.fsf@gnu.org
https://yhetil.org/guix/87woitz1xx.fsf@gnu.org/

A plan for parameterized packages (Nov 2020)
id:87eeku8trb.fsf@gnu.org
https://yhetil.org/guix/87eeku8trb.fsf@gnu.org


> # Unanswered Questions
>
> - Should CI try to build at least some non-default feature permutations?
>   (Probably not.)

From my understanding, one of the issue of the unmanageable number of
combinations.  Well, I am doubtful we (the project) would be able to
guarantee that this feature combination builds or even works.

Maybe Mathieu or Chris can comment about the CI, but to my knowledge,
the build farms are already quite busy.  Without speaking it would
require to store such resulting substitutes; which means less space for
others and so a poorer experience with “guix time-machine“ for older
Guix revisions.


> - Might there be a better syntax for features in package specs?

Maybe, the ’outputs’ mechanism could be used.  The TODO list file in the
Guix repository contains:

--8<---------------cut here---------------start------------->8---
** extend ‘propagated-build-inputs’ with support for multiple outputs

#+BEGIN_SRC scheme
  (outputs '("out" "include"))
  (propagated-build-inputs
    `(((("i1" ,p1 "o1")
        ("i2" ,p2))
       => "include")
      ("i3" ,p3)))
#+END_SRC
--8<---------------cut here---------------end--------------->8---

where the idea seems to have conditional inputs depending on the
outputs.  Somehow, this mechanism would ease to build feature variants.


Cheers,
simon


  reply	other threads:[~2022-11-25  9:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-24 20:26 [RFC] package-with-features (
2022-11-25  9:07 ` zimoun [this message]
2022-11-26 11:06   ` Ludovic Courtès
2022-11-26 11:11 ` (

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86bkovcshy.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=paren@disroot.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.