[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 23:03 +0200
(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 followsthe old commit in the git history. That's good in the common case, butunfortunately, this broke my workflow [0].
Namely, I maintain a branch of the guix repository on which Icherry-pick some commits that haven't hit master yet. I rebase it ontomaster frequently.
It gets tiring to have to specify --allow-downgrades when pulling, so Iadded a way of specifying it in the channels file. As a bonus, it's moregranular.
If this is the right approach, I'll add some docs. Also, is there a testthat exercises this function?
[0]: https://xkcd.com/1172/
Toggle diff (32 lines)diff --git a/guix/channels.scm b/guix/channels.scmindex 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 11:27 +0200
(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 inhttps://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 Ithink it’s configuration that belongs elsewhere, but there’s noconfiguration file for ‘guix pull’ etc.
It may be that setting GUIX_BUILD_OPTIONS=--allow-downgrades actuallyworks, though it’s a bit of a hack.
Thoughts?
Thanks,Ludo’.
J
J
Jakub Kądziołka wrote on 17 Jun 20:50 +0200
(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 notmonotonic ;) Also, AFAIU, the channels.scm *is* the configuration filefor guix pull, and it is the primary, if not only use of <channel>.
Regards,Jakub Kądziołka
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE5Xa/ss9usT31cTO54xWnWEYTFWQFAl7qZfMACgkQ4xWnWEYTFWRZyQ/+OBPwh3tXi1xn+gKdDif855PkkStNuzjfsbQU9aAqklOCroF1jL3T928derTK+HohG6MH3wS/Ced1KZtAGl4USgRbxA1tbimebTZ8tOHM9qR/W8mMMzyWODXhcJTfSeDc4yEyRui0L9BJS/viJgCll0bSWutMeXfj8RTLLb0tB+X/NzRaAae1Ir3NWVJ2zb2vTQByrwhQXGXXxYz2ayti6MhXg6ymtjbeVSiIkDj+XGZKuGGARGNhHJ3FXLMTusC+NDeu1TtoQr27k3cizBG/C1dgNMImtf5a4I/CYZfyO2YO6qUopNhhskFAhbke9nTX3sp2TSlijQxh5Mx6iH9vNQ6snCowgRyH4E1KHqUa6dy1HiNBWhWtIcikkO0NoyNT1sxK6BrK/mvknM4agwCUz5otO3Y0JM7zgTpKcCUIu+wCJ0x8G3VbeQvZ6ttiV0VJ737VcjyAIOsQUEXh5W8393DU5uVt5ShbgyS1ZJhc0F1rzwk4/AbDEWcZOaGvqZNW1SZ3E6L+2tDWG0k63OG+C8REeiwJORJJQoWyWBmdYoRrP++hi619S7Ahh5JA1aZI9AdY8g/0QGFBUQn/8JsxW1hVOJzpVuUaRIrdaSd45hlQfDFuKLBEI1nHZ3sYmiqnP1R0kMkjFYGd35MiSUatR8KUYaosftZQ7B202z7L+NY==UZCt-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 18 Jun 13:59 +0200
(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 allthe time. I agree it’s a use case for some developers, and we need toaccommodate for that, but I wouldn’t want a general mechanism to mark achannel 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’, ‘guixtime-machine’, and ‘guix describe’. It’s the primary way to communicateinformation about the set of channels being used. So to me it’s verymuch orthogonal to whether one wants to allow downgrades, allowoffloading, and enable colored output. :-)
WDYT?
Thanks,Ludo’.
J
J
Jakub Kądziołka wrote on 19 Jun 01:52 +0200
(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 bashalias, but that forfeits the per-channel granularity. Of course, thiscould be solved by augmenting --allow-downgrades to optionally take as aparameter a list of channel names, but it's not something people woulduse interactively and feels like a workaround for the fact there's norelevant configuration file this could be in.
Thoughts?
Regards,Jakub Kądziołka
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE5Xa/ss9usT31cTO54xWnWEYTFWQFAl7r/i0ACgkQ4xWnWEYTFWT8oRAApXyjfrDbx3zqNYSfeGSSMa8MGDfkU2n9HlRVwkNuWKYLn6jJjRU37qeKrHo0ovEbQGrElgD45+4GQbZuz35/o8W1p00go2vNMXszl9Ll6UUj6HHKvy0HSyms4eTps1+3MKIX9mxbD9hXyStHCZaJHnyRGh3b5VwLBuNgiGUrEAB6aU5/YO+3CTks6mr3rKeXMUPNNhaTIAIWqpDsR1M+F8dHTNp8UVSAcIpz2GfIA83W70+Qs8oCkOxO9GxJKUoaDZ839qsIu0td6H15hBLkuKIlFwPWkZnyeyf/fGluXcV1J92wRn4TEucleQinHa8Dt0doEZ1oAVLK2ZtA5aX7N7uhGzRPKe/ML6TAujZniAFHnTd58PKA4uHUD0DrgicXFqm9xzH1p98tuKSuabbH1ccKvhEbx8jVwliTL7ZahLdHviiaFo54G8FVn079xOBplbP24leEaREMRDqft3fVHcUdIC6PsrppJ6840X5Lz0eUtwjOmgmMClWDmWtkFLu1qKMNdkNODlhj6bcwu58Du95UDNEugYOU1T+SHK1G1XTYWCbwrE0NmrIA92/207NDap1Kp2dUhaVxdkAJPftdzbKnhDOSwKbTkVHM52Uw5collnnp5u1xQojT2lTjai6bdh+r62MhlFFhVTziTTSG4PjVc+IKozTPWrm1SQmepwc==a92t-----END PGP SIGNATURE-----

Z
Z
zimoun wrote on 19 Jun 02:19 +0200
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 machineryand my workflow is less flowing. :-) For example, I regularly type "guixpull --commit=<hash> -p /tmp/foo" to test something and now I need morethan sometimes to type "--allow-downgrades". And I have not intensivelyused "guix time-machine" since this new machinery but I have the feelingthat "--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 tospecify default options command by command. Or maybe some alias. Maybesomething like ~/.config/guix/config.scm.

WDYT?

All the best,simon
L
L
Ludovic Courtès wrote on 19 Jun 09:39 +0200
(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 helpin a situation like this.
Ludo’.
L
L
Ludovic Courtès wrote on 19 Jun 09:52 +0200
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 firststep, although I find it questionable to add complexity for this usecase.
How would it affect your workflow if you used merges instead ofrebasing? With authentication now in place, you probably have to dothis anyway, or to also disable it.
Thoughts?
Ludo’.
J
J
Jakub Kądziołka wrote on 19 Jun 14:25 +0200
(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 thecomplexity of the branch, and as such, has a cost. Sometimes, I getsome merge conflicts; in such a case I want to prepare a new patch thatapplies cleanly onto master, such that I can push it easily when thetime is right.
Also, the workflow of rebasing a patchstack allows me to clearly seewhich patches are yet to be upstreamed. A history with merges - not somuch.
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 thepatches I apply each time I rebase. I admit, this only works because Ihave access to the repository itself, and as such, my key is authorized.
Regards,Jakub Kądziołka
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE5Xa/ss9usT31cTO54xWnWEYTFWQFAl7srrgACgkQ4xWnWEYTFWQmLBAAhRDZbCmTArrgtJMVJA5HypHrQ/aMwzLCmkf/x1zGr1l6y/1i+3upAmNA7q9S7VpYC4ju1CsItKlokkgym+/D3KyVK7Z5iRnDqwfxM+KBCSu3yE2Gr9i5vlE5O9b08AnPvHsi+8dNCB3rf+b1ZK89GgxeqTg6zcuOKs3+Dn/PCnhvwIFGTbKdSUO040e2L91CQds4gcqmqQHwf6G2dLEOBDML5Xefw2fhzM8IevWceRtt38BovtAfyCN+akeH/ceBk8+liTtt5Cp4tf5T/lc+/kiCxti5awWqa7PHNndx/xn23dPIGxuqEWEnXhttzOEIJ8I4S/f4az0FVXUrKuSSDsaMwnkWljs4wUPjZoChDHB9gDHw/H+52RruLIRHGqufCVmd6xblBOu+IJTeYVgo7BY+K8g7uSdUBQruyXEHaNj720QmJY8xVEI5mVVxQsriaNvFi7REoj023A8dxDVPEu4kx3Wt69id+2fuL0qFZZ5M1aXUPGQ3mK99t864n4lEuFSZqoo+B6b0Lhe99wLcUfAEXmkRgEG0rNwV85Ql2zFIlSvt7c/hr3vMn/PoH8wHTI8meideuvLPdVLUC8o7nS2hN08KdYA+2+m6IEGtReygVzqsLSZztoe98sQmitq9OfKAy+8TgiBFKh2cc6cQZdOS9taO9REQDpFpj8h0c2E==vDG9-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 19 Jun 22:26 +0200
(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 mightprefer 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’.
?