[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#63276: Allow channels to depend on a past Guix revision / private de
From: |
Maxim Cournoyer |
Subject: |
bug#63276: Allow channels to depend on a past Guix revision / private dependencies |
Date: |
Fri, 05 May 2023 10:36:49 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi Simon,
Simon Tournier <zimon.toutoune@gmail.com> writes:
> Hi Maxim,
>
> Well, part of the message is in: :-)
>
> 875y987z1m.fsf@gmail.com">https://issues.guix.gnu.org/msgid/875y987z1m.fsf@gmail.com
Oh, a Mumi reference to a message ID! I didn't know it supported that,
cool!
> 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?
That's the idea I had yes, seeing that my channel won't work with any
newer Guix revision, I thought I should be able to declare that upfront
as a dependency, and have the channels mechanism take care of treating
all things relating to this channel via a Guix inferior. The benefit
above having to explain to users how to do this in a manifest as done in
[0] would be twofold:
1. The channel can simply be added and works out of the box, without
having users go through the hoops of configuring an inferior.
2. 'guix pull', if taught to translate a dependency on a past Guix into
an inferior, could use that at the time it runs ad avoid errors caused
by removed or moved packages in current Guix.
[0] https://gitlab.com/Apteryks/sfl-guix-channel/-/blob/master/README.org
> 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.
Not exactly equivalent to that channel file. In my idea (not thinking
about the technicalities/difficulties yet), the dependency on the Guix
channel would be made private to the package (my translating it to a
Guix inferior as mentioned above), instead of spilling into the global
package namespace (which I agree would be undesirable!).
In other words, declaring a dependency on a prior Guix channel would
cause all derivations for packages in that channel to happen in a
corresponding Guix inferior. Does that make sense?
>
>> 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).
Interesting. So using inferiors inside your channel does work in
general, contrary to experiments made with the sfl-guix-channel in the
other thread?
--
Thanks,
Maxim