bug#63276: Allow channels to depend on a past Guix revision / private dependencies

[Simon Tournier <zimon.toutoune@gmail.com>]

Hi Maxim,

Well, part of the message is in: :-)

    https://issues.guix.gnu.org/msgid/875y987z1m.fsf@gmail.com

On Thu, 04 May 2023 at 11:52, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> It seems a valid use case to have a channel that depends on an old Guix
> version.  Should this be supported?
>
> If I could for example use the following channel dependency file at the
> level of the channel in a .guix-channel, to depend on an older Guix
> revision:
>
> --8<---------------cut here---------------start------------->8---
> (channel
>  (version 0)
>  (dependencies
>   (channel
>    (inherit %default-guix-channel)
>    (commit "9ed65e6af77893b658a7159b091b5002892c2f95"))))
> --8<---------------cut here---------------end--------------->8---

You want complete channel depends on a previous Guix, right?

Somehow, it would become equivalent to this channels.scm

        (list (channel
                (name 'guix)
                (url "https://git.savannah.gnu.org/git/guix.git")
                (branch "master")
                (commit
                  "9ed65e6af77893b658a7159b091b5002892c2f95"))
              (channel
                (name 'sfl)
                (url "file:///tmp/sfl-guix-channel")
                (branch "master"))))

and then run “guix pull && guix build sflvault-client” or:

    guix time-machine -C channels.scm -- shell sflvault-client


Well, I do not know if it is desirable.  Most of the time, I only want
one specific package from one specific Guix revision.


> As a workaround, I can define a 'python-pycryto*' in the channel itself,
> although that's kind of silly because it can only be used with a Guix
> inferior pegged to commit 9ed65e6af77893b658a7159b091b5002892c2f95,
> which does contain 'python-pycryto'.

Well, I do not know if we are using the time-travel the same way. :-)

Considering this:

        (define-public foo
          (package
            (name "foo")
            (inputs
             (list bar)
             (list baz))))

Most of the time, I want to build ’foo’ using a recent Guix but that
recent Guix removed ’bar’ so I want to pick it up from an inferior.
And let say I want ’baz’ from another Guix revision because some
specific version of ’baz’ is required for building ’foo’.

Basically, I am tempted to define the symbol ’bar’ and ’baz’ in my
channel and bind them to some inferior packages (here from 2 Guix
revisions).

Well, the number of inferiors should not be too much.  And it requires
some care about the propagated inputs.


Cheers,
simon