[PATCH] channels: Allow specifying per-channel --allow-downgrades in the channel file

Open

Details

3 participants

Jakub K?dzio?ka
Ludovic Courtès
zimoun

Owner: unassigned

Submitted by: Jakub K?dzio?ka

Severity: normal

Jakub K?dzio?ka wrote on 15 Jun 2020 23:03

Recipients:(address . guix-patches@gnu.org)

Message-ID:20200615210343.18964-1-kuba@kadziolka.net

* guix/channels.scm (<channel>)

[allow-unrelated?, allow-downgrade?]: New fields.

(ensure-forward-channel-update): Handle the fields appropriately.

---

guix/channels.scm | 5 +++++

1 file changed, 5 insertions(+)

Some time ago, guix pull started verifying that the new commit follows

the old commit in the git history. That's good in the common case, but

unfortunately, this broke my workflow [0].

Namely, I maintain a branch of the guix repository on which I

cherry-pick some commits that haven't hit master yet. I rebase it onto

master frequently.

It gets tiring to have to specify --allow-downgrades when pulling, so I

added a way of specifying it in the channels file. As a bonus, it's more

granular.

If this is the right approach, I'll add some docs. Also, is there a test

that exercises this function?

[0]: https://xkcd.com/1172/

Toggle diff (32 lines)diff --git a/guix/channels.scm b/guix/channels.scm
index 84c47fc0d0..17c4f3750c 100644
--- a/guix/channels.scm
+++ b/guix/channels.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2018, 2019, 2020 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2018 Ricardo Wurmus <rekado@elephly.net>
 ;;; Copyright © 2019 Jan (janneke) Nieuwenhuizen <janneke@gnu.org>
+;;; Copyright © 2020 Jakub K?dzio?ka <kuba@kadziolka.net>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -104,6 +105,8 @@
   (url       channel-url)
   (branch    channel-branch (default "master"))
   (commit    channel-commit (default #f))
+  (allow-unrelated? channel-allow-unrelated? (default #f))
+  (allow-downgrade? channel-allow-downgrade? (default #f))
   (location  channel-location
              (default (current-source-location)) (innate)))
 
@@ -245,6 +248,8 @@ This procedure implements a channel update policy meant to be used as a
   (match relation
     ('ancestor #t)
     ('self #t)
+    ((? (const (channel-allow-unrelated? channel)) 'unrelated) #t)
+    ((? (const (channel-allow-downgrade? channel)) 'descendant) #t)
     (_
      (raise (make-compound-condition
              (condition
-- 
2.26.2

Ludovic Courtès wrote on 17 Jun 2020 11:27

Recipients:(name . Jakub K?dzio?ka)(address . kuba@kadziolka.net)(address . 41882@debbugs.gnu.org)

Message-ID:87lfkmrqi7.fsf@gnu.org

Hi Jakub,

Jakub K?dzio?ka <kuba@kadziolka.net> skribis:

Toggle quote (11 lines)> * guix/channels.scm (<channel>)
>   [allow-unrelated?, allow-downgrade?]: New fields.
>   (ensure-forward-channel-update): Handle the fields appropriately.
> ---
>  guix/channels.scm | 5 +++++
>  1 file changed, 5 insertions(+)
>
> Some time ago, guix pull started verifying that the new commit follows
> the old commit in the git history. That's good in the common case, but
> unfortunately, this broke my workflow [0].

:-)

Toggle quote (4 lines)

> Namely, I maintain a branch of the guix repository on which I

> cherry-pick some commits that haven't hit master yet. I rebase it onto

> master frequently.

I see; this is similar to what John reported in

https://issues.guix.gnu.org/41604.

Toggle quote (7 lines)

> It gets tiring to have to specify --allow-downgrades when pulling, so I

> added a way of specifying it in the channels file. As a bonus, it's more

> granular.

> If this is the right approach, I'll add some docs. Also, is there a test

> that exercises this function?

I don’t think “allow-downgrade?” should be a property of <channel>,

because conceptually it’s an unrelated piece of configuration. So I

think it’s configuration that belongs elsewhere, but there’s no

configuration file for ‘guix pull’ etc.

It may be that setting GUIX_BUILD_OPTIONS=--allow-downgrades actually

works, though it’s a bit of a hack.

Thoughts?

Thanks,

Ludo’.

Jakub K?dzio?ka wrote on 17 Jun 2020 20:50

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41882@debbugs.gnu.org)

Message-ID:20200617185027.ze5euqyuoylpewze@gravity

Toggle quote (12 lines)> > It gets tiring to have to specify --allow-downgrades when pulling, so I
> > added a way of specifying it in the channels file. As a bonus, it's more
> > granular.
> >
> > If this is the right approach, I'll add some docs. Also, is there a test
> > that exercises this function?
> 
> I don’t think “allow-downgrade?” should be a property of <channel>,
> because conceptually it’s an unrelated piece of configuration.  So I
> think it’s configuration that belongs elsewhere, but there’s no
> configuration file for ‘guix pull’ etc.

It's a property of the channel that the git repo in question is not
monotonic ;) Also, AFAIU, the channels.scm *is* the configuration file
for guix pull, and it is the primary, if not only use of <channel>.

Regards,
Jakub K?dzio?ka

Ludovic Courtès wrote on 18 Jun 2020 13:59

Recipients:(name . Jakub K?dzio?ka)(address . kuba@kadziolka.net)(address . 41882@debbugs.gnu.org)

Message-ID:874kr8mvow.fsf@gnu.org

Hi,

Jakub K?dzio?ka <kuba@kadziolka.net> skribis:

Toggle quote (15 lines)>> > It gets tiring to have to specify --allow-downgrades when pulling, so I
>> > added a way of specifying it in the channels file. As a bonus, it's more
>> > granular.
>> >
>> > If this is the right approach, I'll add some docs. Also, is there a test
>> > that exercises this function?
>> 
>> I don’t think “allow-downgrade?” should be a property of <channel>,
>> because conceptually it’s an unrelated piece of configuration.  So I
>> think it’s configuration that belongs elsewhere, but there’s no
>> configuration file for ‘guix pull’ etc.
>
> It's a property of the channel that the git repo in question is not
> monotonic ;)

I don’t think we can meaningfully support channels that are rebased all

the time. I agree it’s a use case for some developers, and we need to

accommodate for that, but I wouldn’t want a general mechanism to mark a

channel as non-monotonic.

Toggle quote (3 lines)

> Also, AFAIU, the channels.scm *is* the configuration file for guix

> pull, and it is the primary, if not only use of <channel>.

The <channel> data structure is used by ‘guix pull’, ‘guix

time-machine’, and ‘guix describe’. It’s the primary way to communicate

information about the set of channels being used. So to me it’s very

much orthogonal to whether one wants to allow downgrades, allow

offloading, and enable colored output. :-)

WDYT?

Thanks,

Ludo’.

Jakub K?dzio?ka wrote on 19 Jun 2020 01:52

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41882@debbugs.gnu.org)

Message-ID:20200618235213.utb3sk6la7mmhqsx@gravity

On Wed, Jun 17, 2020 at 11:27:44AM +0200, Ludovic Courtès wrote:

Toggle quote (3 lines)

> It may be that setting GUIX_BUILD_OPTIONS=--allow-downgrades actually

> works, though it’s a bit of a hack.

I have found the time to test this. Unfortunately, while it does make

`guix pull' work, it breaks other commands, such as `guix build'.

I'm not sure what a good solution would be, then. I could make a bash

alias, but that forfeits the per-channel granularity. Of course, this

could be solved by augmenting --allow-downgrades to optionally take as a

parameter a list of channel names, but it's not something people would

use interactively and feels like a workaround for the fact there's no

relevant configuration file this could be in.

Thoughts?

Regards,

Jakub K?dzio?ka

zimoun wrote on 19 Jun 2020 02:19

Guix configuration file?

Recipients:(address . 41882@debbugs.gnu.org)

Message-ID:86v9jnvre0.fsf@gmail.com

Dear,

As well, I am still starting to have some issue with the new machinery

and my workflow is less flowing. :-) For example, I regularly type "guix

pull --commit=<hash> -p /tmp/foo" to test something and now I need more

than sometimes to type "--allow-downgrades". And I have not intensively

used "guix time-machine" since this new machinery but I have the feeling

that "--disable-authentication" will be necessary too in my workflow.

In the light of your message and a previous one by Ludo...

On Fri, 19 Jun 2020 at 01:52, Jakub K?dzio?ka <kuba@kadziolka.net> wrote:

Toggle quote (6 lines)

>> It may be that setting GUIX_BUILD_OPTIONS=--allow-downgrades actually

>> works, though it’s a bit of a hack.

> I have found the time to test this. Unfortunately, while it does make

> `guix pull' work, it breaks other commands, such as `guix build'.

On Wed, 17 Jun 2020 at 11:27, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (5 lines)

> I don’t think “allow-downgrade?” should be a property of <channel>,

> because conceptually it’s an unrelated piece of configuration. So I

> think it’s configuration that belongs elsewhere, but there’s no

> configuration file for ‘guix pull’ etc.

...maybe it is time to have a configuration file for Guix. Something to

specify default options command by command. Or maybe some alias. Maybe

something like ~/.config/guix/config.scm.

WDYT?

All the best,

simon

Ludovic Courtès wrote on 19 Jun 2020 09:39

Recipients:(name . zimoun)(address . zimon.toutoune@gmail.com)

Message-ID:87ftarijxm.fsf@gnu.org

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (4 lines)

> ...maybe it is time to have a configuration file for Guix. Something to

> specify default options command by command. Or maybe some alias. Maybe

> something like ~/.config/guix/config.scm.

Yes, a way to define aliases would be nice, and it would probably help

in a situation like this.

Ludo’.

Ludovic Courtès wrote on 19 Jun 2020 09:52

Re: [bug#41882] [PATCH] channels: Allow specifying per-channel --allow-downgrades in the channel file

Recipients:(name . Jakub K?dzio?ka)(address . kuba@kadziolka.net)(address . 41882@debbugs.gnu.org)

Message-ID:875zbnijax.fsf@gnu.org

Hi,

Jakub K?dzio?ka <kuba@kadziolka.net> skribis:

Toggle quote (7 lines)

> On Wed, Jun 17, 2020 at 11:27:44AM +0200, Ludovic Courtès wrote:

>> It may be that setting GUIX_BUILD_OPTIONS=--allow-downgrades actually

>> works, though it’s a bit of a hack.

> I have found the time to test this. Unfortunately, while it does make

> `guix pull' work, it breaks other commands, such as `guix build'.

Yeah.

Toggle quote (7 lines)

> I'm not sure what a good solution would be, then. I could make a bash

> alias, but that forfeits the per-channel granularity. Of course, this

> could be solved by augmenting --allow-downgrades to optionally take as a

> parameter a list of channel names, but it's not something people would

> use interactively and feels like a workaround for the fact there's no

> relevant configuration file this could be in.

We could have ‘--allow-downgrades’ accept a list of channels, as a first

step, although I find it questionable to add complexity for this use

case.

How would it affect your workflow if you used merges instead of

rebasing? With authentication now in place, you probably have to do

this anyway, or to also disable it.

Thoughts?

Ludo’.

Jakub K?dzio?ka wrote on 19 Jun 2020 14:25

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41882@debbugs.gnu.org)

Message-ID:20200619122528.qt3dkxk5nsu6oasc@gravity

On Fri, Jun 19, 2020 at 09:52:38AM +0200, Ludovic Courtès wrote:

Toggle quote (3 lines)

> How would it affect your workflow if you used merges instead of

> rebasing?

The fundamental difference would be that each merge increases the

complexity of the branch, and as such, has a cost. Sometimes, I get

some merge conflicts; in such a case I want to prepare a new patch that

applies cleanly onto master, such that I can push it easily when the

time is right.

Also, the workflow of rebasing a patchstack allows me to clearly see

which patches are yet to be upstreamed. A history with merges - not so

much.

Toggle quote (3 lines)

> With authentication now in place, you probably have to do

> this anyway, or to also disable it.

I have configured git to sign all my commits, so it re-signs all the
patches I apply each time I rebase. I admit, this only works because I
have access to the repository itself, and as such, my key is authorized.

Regards,
Jakub K?dzio?ka

Ludovic Courtès wrote on 19 Jun 2020 22:26

Recipients:(name . Jakub K?dzio?ka)(address . kuba@kadziolka.net)(address . 41882@debbugs.gnu.org)

Message-ID:87sgeqg5u9.fsf@gnu.org

Hi,

Jakub K?dzio?ka <kuba@kadziolka.net> skribis:

Toggle quote (14 lines)> On Fri, Jun 19, 2020 at 09:52:38AM +0200, Ludovic Courtès wrote:
>> How would it affect your workflow if you used merges instead of
>> rebasing?
>
> The fundamental difference would be that each merge increases the
> complexity of the branch, and as such, has a cost. Sometimes, I get
> some merge conflicts; in such a case I want to prepare a new patch that
> applies cleanly onto master, such that I can push it easily when the
> time is right.
>
> Also, the workflow of rebasing a patchstack allows me to clearly see
> which patches are yet to be upstreamed. A history with merges - not so
> much.

Yeah, agreed.

I do ./pre-inst-env for my local branches but I understand one might

prefer to use ‘guix pull’.

Hmm dunno, I think this needs more thought.

Toggle quote (7 lines)

>> With authentication now in place, you probably have to do

>> this anyway, or to also disable it.

> I have configured git to sign all my commits, so it re-signs all the

> patches I apply each time I rebase. I admit, this only works because I

> have access to the repository itself, and as such, my key is authorized.

OK.

Thanks,

Ludo’.

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 41882@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 41882

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date