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

[Maxim Cournoyer]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi Simon,
>
> Simon Tournier <zimon.toutoune@gmail.com> writes:
>
>> Hi Maxim,
>>
>> Well, part of the message is in: :-)
>>
>>     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?

The discussion has long died, and so has my original use case, but based
on what you had written I guess it could have been possible to add
code to my channel file so that all packages would have been computed
through an inferior.

I'll close this for now.

-- 
Thanks,
Maxim