all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Pjotr Prins <pjotr.public12@thebird.nl>
Cc: guix-devel@gnu.org, Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>
Subject: Re: [Orchestration][RFC] A simple draft for channels
Date: Tue, 20 Mar 2018 11:41:33 +0100	[thread overview]
Message-ID: <87r2ofc9lu.fsf@elephly.net> (raw)
In-Reply-To: <20180320070224.GA20987@thebird.nl>


Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Mon, Mar 19, 2018 at 01:04:00PM +0100, Pjotr Prins wrote:
>> Maybe we should start thinking that a channel is simply an
>> architecture dependent Guix 'pack' of substitutes that includes the
>> pre-built Guix git repo. When deployed in a container we can inject
>> the keys. When this works we can design a pack repository, making the
>> channels searchable.
>
> Continuing my line of thought: a binary channel in my mind is now a
> compiled Guix package tree with Guix and possible adaptations (say a
> special package for Ruby). In other words, a special (timed) version
> of Guix sitting in /gnu/store/*named-guix-channel/bin/guix.

What you describe is essentially “guix pull”.  “guix pull” can already
use a different branch or a different repository.

It has at least two problems in this context:

1) it only keeps a link to the “latest” Guix.  There is no way to
   declare the use of a different variant of Guix.

2) it builds everything from source (Ludo’s branch for splitting the
   target of “guix pull” into several derivations addresses this)

Maybe we should address the first problem next and allow for not only
the latest Guix version to be retained.  This is not quite the same as a
regular profile, because these different variants of Guix surely would
provide colliding files.

The guix command would need to be changed to pick “latest” by default,
but use a different variant if specified.

The workflow would be something like that:

    # fetch Guix from somewhere and record as “foobar”
    guix pull --url=https://somewhere foobar

    # use that variant of Guix
    guix --variant=foobar build hello

I don’t think this should be the only mechanism through which people can
provide channels.  I wouldn’t want to have to essentially fork Guix.
For a user this is a problem, too, because channels would no longer be
composable (today I can compose multiple package collections with
GUIX_PACKAGE_PATH).

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

  reply	other threads:[~2018-03-20 10:57 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-19  8:24 [RFC] A simple draft for channels Ricardo Wurmus
2018-01-19  8:55 ` Jelle Licht
2018-01-19 11:30 ` Pjotr Prins
2018-01-19 13:41 ` Ludovic Courtès
2018-01-19 13:56   ` Pjotr Prins
2018-01-23  6:38     ` Ricardo Wurmus
2018-01-23  8:54       ` Pjotr Prins
2018-01-23 23:01         ` Carlo Zancanaro
2018-01-23 16:03   ` myglc2
2018-01-23 16:50     ` ng0
2018-01-24  5:44       ` myglc2
2018-01-24 12:33         ` ng0
2018-01-24 15:04           ` Konrad Hinsen
2018-01-23 20:39     ` Ricardo Wurmus
2018-01-23 20:37   ` Ricardo Wurmus
2018-01-24 12:01     ` Pjotr Prins
2018-01-20  5:45 ` 宋文武
2018-01-24 14:08   ` Ludovic Courtès
2018-01-24 17:55     ` myglc2
2018-01-24 18:20       ` Ricardo Wurmus
2018-01-26 17:23         ` myglc2
2018-01-26 18:53           ` Oleg Pykhalov
2018-03-19 12:46         ` ng0
2018-01-27 12:10 ` Chris Marusich
2018-03-19 12:04   ` [Orchestration][RFC] " Pjotr Prins
2018-03-19 12:36     ` ng0
2018-03-19 18:21     ` myglc2
2018-03-19 18:31       ` Pjotr Prins
2018-03-19 20:18         ` myglc2
2018-03-19 20:29           ` Pjotr Prins
2018-03-20  7:02     ` Pjotr Prins
2018-03-20 10:41       ` Ricardo Wurmus [this message]
2018-03-20 13:10         ` Pjotr Prins
2018-03-20 13:41           ` Ricardo Wurmus

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=87r2ofc9lu.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=guix-devel@gnu.org \
    --cc=pjotr.public12@thebird.nl \
    --cc=ricardo.wurmus@mdc-berlin.de \
    /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.