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

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

[Jakub Kądziołka]

* 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/

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

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

[Ludovic Courtès]

Hi Jakub,

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

> * 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.

I see; this is similar to what John reported in
<https://issues.guix.gnu.org/41604>.

> 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’.

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

[Jakub Kądziołka]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

> > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ludovic Courtès]

Hi,

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

>> > 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.

> 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’.

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

[Jakub Kądziołka]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

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'.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bug#41882] Guix configuration file?

[zimoun]

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:

>> 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:

> 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

[bug#41882] Guix configuration file?

[Ludovic Courtès]

Hi,

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

> ...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’.

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

[Ludovic Courtès]

Hi,

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

> 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.

> 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’.

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

[Jakub Kądziołka]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]

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.

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ludovic Courtès]

Hi,

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

> 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.

>> 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’.