Hi Simon, Simon Tournier <zimon.touto...@gmail.com> writes:
> Hi Maxim, > > Well, part of the message is in: :-) > > https://issues.guix.gnu.org/msgid/875y987z1m....@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.courno...@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
