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

OpenSubmitted by Jakub Kądziołka.
Details
3 participants
  • Jakub Kądziołka
  • Ludovic Courtès
  • zimoun
Owner
unassigned
Severity
normal
J
J
Jakub Kądziołka wrote on 15 Jun 2020 23:03
(address . guix-patches@gnu.org)
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?


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
L
L
Ludovic Courtès wrote on 17 Jun 2020 11:27
(name . Jakub Kądziołka)(address . kuba@kadziolka.net)(address . 41882@debbugs.gnu.org)
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

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’.
J
J
Jakub Kądziołka wrote on 17 Jun 2020 20:50
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41882@debbugs.gnu.org)
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
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE5Xa/ss9usT31cTO54xWnWEYTFWQFAl7qZfMACgkQ4xWnWEYT
FWRZyQ/+OBPwh3tXi1xn+gKdDif855PkkStNuzjfsbQU9aAqklOCroF1jL3T928d
erTK+HohG6MH3wS/Ced1KZtAGl4USgRbxA1tbimebTZ8tOHM9qR/W8mMMzyWODXh
cJTfSeDc4yEyRui0L9BJS/viJgCll0bSWutMeXfj8RTLLb0tB+X/NzRaAae1Ir3N
WVJ2zb2vTQByrwhQXGXXxYz2ayti6MhXg6ymtjbeVSiIkDj+XGZKuGGARGNhHJ3F
XLMTusC+NDeu1TtoQr27k3cizBG/C1dgNMImtf5a4I/CYZfyO2YO6qUopNhhskFA
hbke9nTX3sp2TSlijQxh5Mx6iH9vNQ6snCowgRyH4E1KHqUa6dy1HiNBWhWtIcik
kO0NoyNT1sxK6BrK/mvknM4agwCUz5otO3Y0JM7zgTpKcCUIu+wCJ0x8G3VbeQvZ
6ttiV0VJ737VcjyAIOsQUEXh5W8393DU5uVt5ShbgyS1ZJhc0F1rzwk4/AbDEWcZ
OaGvqZNW1SZ3E6L+2tDWG0k63OG+C8REeiwJORJJQoWyWBmdYoRrP++hi619S7Ah
h5JA1aZI9AdY8g/0QGFBUQn/8JsxW1hVOJzpVuUaRIrdaSd45hlQfDFuKLBEI1nH
Z3sYmiqnP1R0kMkjFYGd35MiSUatR8KUYaosftZQ7B202z7L+NY=
=UZCt
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 18 Jun 2020 13:59
(name . Jakub Kądziołka)(address . kuba@kadziolka.net)(address . 41882@debbugs.gnu.org)
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’.
J
J
Jakub Kądziołka wrote on 19 Jun 2020 01:52
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41882@debbugs.gnu.org)
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
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE5Xa/ss9usT31cTO54xWnWEYTFWQFAl7r/i0ACgkQ4xWnWEYT
FWT8oRAApXyjfrDbx3zqNYSfeGSSMa8MGDfkU2n9HlRVwkNuWKYLn6jJjRU37qeK
rHo0ovEbQGrElgD45+4GQbZuz35/o8W1p00go2vNMXszl9Ll6UUj6HHKvy0HSyms
4eTps1+3MKIX9mxbD9hXyStHCZaJHnyRGh3b5VwLBuNgiGUrEAB6aU5/YO+3CTks
6mr3rKeXMUPNNhaTIAIWqpDsR1M+F8dHTNp8UVSAcIpz2GfIA83W70+Qs8oCkOxO
9GxJKUoaDZ839qsIu0td6H15hBLkuKIlFwPWkZnyeyf/fGluXcV1J92wRn4TEucl
eQinHa8Dt0doEZ1oAVLK2ZtA5aX7N7uhGzRPKe/ML6TAujZniAFHnTd58PKA4uHU
D0DrgicXFqm9xzH1p98tuKSuabbH1ccKvhEbx8jVwliTL7ZahLdHviiaFo54G8FV
n079xOBplbP24leEaREMRDqft3fVHcUdIC6PsrppJ6840X5Lz0eUtwjOmgmMClWD
mWtkFLu1qKMNdkNODlhj6bcwu58Du95UDNEugYOU1T+SHK1G1XTYWCbwrE0NmrIA
92/207NDap1Kp2dUhaVxdkAJPftdzbKnhDOSwKbTkVHM52Uw5collnnp5u1xQojT
2lTjai6bdh+r62MhlFFhVTziTTSG4PjVc+IKozTPWrm1SQmepwc=
=a92t
-----END PGP SIGNATURE-----


Z
Z
zimoun wrote on 19 Jun 2020 02:19
Guix configuration file?
(address . 41882@debbugs.gnu.org)
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
L
L
Ludovic Courtès wrote on 19 Jun 2020 09:39
(name . zimoun)(address . zimon.toutoune@gmail.com)
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’.
L
L
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
(name . Jakub Kądziołka)(address . kuba@kadziolka.net)(address . 41882@debbugs.gnu.org)
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’.
J
J
Jakub Kądziołka wrote on 19 Jun 2020 14:25
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 41882@debbugs.gnu.org)
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
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE5Xa/ss9usT31cTO54xWnWEYTFWQFAl7srrgACgkQ4xWnWEYT
FWQmLBAAhRDZbCmTArrgtJMVJA5HypHrQ/aMwzLCmkf/x1zGr1l6y/1i+3upAmNA
7q9S7VpYC4ju1CsItKlokkgym+/D3KyVK7Z5iRnDqwfxM+KBCSu3yE2Gr9i5vlE5
O9b08AnPvHsi+8dNCB3rf+b1ZK89GgxeqTg6zcuOKs3+Dn/PCnhvwIFGTbKdSUO0
40e2L91CQds4gcqmqQHwf6G2dLEOBDML5Xefw2fhzM8IevWceRtt38BovtAfyCN+
akeH/ceBk8+liTtt5Cp4tf5T/lc+/kiCxti5awWqa7PHNndx/xn23dPIGxuqEWEn
XhttzOEIJ8I4S/f4az0FVXUrKuSSDsaMwnkWljs4wUPjZoChDHB9gDHw/H+52Rru
LIRHGqufCVmd6xblBOu+IJTeYVgo7BY+K8g7uSdUBQruyXEHaNj720QmJY8xVEI5
mVVxQsriaNvFi7REoj023A8dxDVPEu4kx3Wt69id+2fuL0qFZZ5M1aXUPGQ3mK99
t864n4lEuFSZqoo+B6b0Lhe99wLcUfAEXmkRgEG0rNwV85Ql2zFIlSvt7c/hr3vM
n/PoH8wHTI8meideuvLPdVLUC8o7nS2hN08KdYA+2+m6IEGtReygVzqsLSZztoe9
8sQmitq9OfKAy+8TgiBFKh2cc6cQZdOS9taO9REQDpFpj8h0c2E=
=vDG9
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 19 Jun 2020 22:26
(name . Jakub Kądziołka)(address . kuba@kadziolka.net)(address . 41882@debbugs.gnu.org)
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 email to 41882@debbugs.gnu.org