Questions about Git and workflow

Questions about Git and workflow

[HiPhish]

Hello everyone,

I am trying to get more serious about Guix, and I have a few questions about 
how to develop Guix and the associated Git workflow. The manual in chapter 14.1 
(Building from Git) explains most things pretty well.

My first question is regarding `guix git authenticate`. The first time I ran it 
after a `git clone ...` and `guix environment guix` I got an error saying that 
the `keyring` branch cannot be found. So I did a `git checkout --track origin/
keyring`, but I got a different error instead:

    $ guix git authenticate 9edb3f66fd807b096b48283debdcddccfea34bad "BBB0 
2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"
    Authenticating commits 9edb3f6 to ec32c85 (3 new commits)...
    guix git: error: commit ec32c8591eb111023db514800145532a1e454125 not 
signed by an authorized key: F5DA 2032 4B87 3D0B 7A38  7672 0DB0 FF88 4F55 
6D79

Finally I did a `git pull` on both the `keyring` and the `master` branch and 
the check passed.

So my first question is: did I do it correctly? If not, what is the correct 
workflow?

My second question is regarding the `.po` files which get changed during the 
build process. Git shows me a number of language-specific files as modified, even 
though I never touched them by hand. Should those changes be commited? Should 
I include them when I send a patch? Why are they even version-controlled if 
they get changed automatically?

My last question is about the local state directory. The manual says the pass 
my current local state directory (by default `/var`) to `./configure`, but then 
my store gets mutated. I would prefer not to store my weird experiments where 
my day-to-day packages lie. I know I can revert at any time, but I'd rather 
not. I instead created `./var` and passed `$(pwd)/var` to `./configure`. The 
question is, is this the way to go? When I tried building a package (`/pre-
inst-env guix install go-github-com-junegunn-fzf`) Guix complained that there 
was no deamon running, so do I need a second shell running the deamon (`sudo -
E ./pre-inst-env guix-daemon --build-users-group=guixbuild`) as well?

Thank you in advance.

Re: Questions about Git and workflow

[Leo Famulari]

On Tue, Aug 18, 2020 at 08:38:39PM +0200, HiPhish wrote:
> My first question is regarding `guix git authenticate`. The first time I ran it 
> after a `git clone ...` and `guix environment guix` I got an error saying that 
> the `keyring` branch cannot be found. So I did a `git checkout --track origin/
> keyring`, but I got a different error instead:
> 
>     $ guix git authenticate 9edb3f66fd807b096b48283debdcddccfea34bad "BBB0 
> 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"
>     Authenticating commits 9edb3f6 to ec32c85 (3 new commits)...
>     guix git: error: commit ec32c8591eb111023db514800145532a1e454125 not 
> signed by an authorized key: F5DA 2032 4B87 3D0B 7A38  7672 0DB0 FF88 4F55 
> 6D79
> 
> Finally I did a `git pull` on both the `keyring` and the `master` branch and 
> the check passed.
> 
> So my first question is: did I do it correctly? If not, what is the correct 
> workflow?

It sounds like you did it correctly. After bringing the 'keyring' branch
up to date, the authentication succeeded. If you want to explore more,
compare the keyring branch before and after you updated it.

> My second question is regarding the `.po` files which get changed during the 
> build process. Git shows me a number of language-specific files as modified, even 
> though I never touched them by hand. Should those changes be commited? Should 
> I include them when I send a patch? Why are they even version-controlled if 
> they get changed automatically?

I ignore these changes. When they occur I do `git checkout po` to erase
them. I don't really know what's "correct" here but we can expect some
minor annoyances like this in the development environment.

> My last question is about the local state directory. The manual says the pass 
> my current local state directory (by default `/var`) to `./configure`, but then 
> my store gets mutated. I would prefer not to store my weird experiments where 
> my day-to-day packages lie. I know I can revert at any time, but I'd rather 
> not. I instead created `./var` and passed `$(pwd)/var` to `./configure`. The 
> question is, is this the way to go? When I tried building a package (`/pre-
> inst-env guix install go-github-com-junegunn-fzf`) Guix complained that there 
> was no deamon running, so do I need a second shell running the deamon (`sudo -
> E ./pre-inst-env guix-daemon --build-users-group=guixbuild`) as well?

I recommend not using a different local state directory. There should
not be any negative (or even observable) effects of your experimental
artifacts being in /gnu/store. I haven't tried managing multiple stores
but I assume you'd need to run a separate daemon for each, configured
for the correct directories.

Re: Questions about Git and workflow

[Joshua Branson]

You might be interested in my video where I contribute a tiny patch to
the guix cookbook.  I'm sure that my workflow could use some
improvement, but you might find some ideas here:

https://video.hardlimit.com/videos/watch/3c1df4c5-392a-44a9-b615-bab533a66231

--
Joshua Branson
Sent from Emacs and Gnus

Re: Questions about Git and workflow

[HiPhish]

On Tuesday, 18 August 2020 22:33:53 CEST Leo Famulari wrote:
> I recommend not using a different local state directory. There should
> not be any negative (or even observable) effects of your experimental
> artifacts being in /gnu/store. I haven't tried managing multiple stores
> but I assume you'd need to run a separate daemon for each, configured
> for the correct directories.

OK, I'll try that. My main concern was with packages I actually want to run. 
For example, last time I wanted to update the Neovim version, so I changed the 
definition and installed Neovim in order to try it out a bit. But doing so 
replaced my previous Neovim installation. I know the old one was still in the 
store, but if I had borked the update I would have had the problem that my 
text editor, which is what I use to edit Guile scripts, was messed up.

It's not a major problem, but still an annoyance. Perhaps instead of `install` 
I should have done `environment --ad-hoc`.

Re: Questions about Git and workflow

[Ekaitz Zarraga]

> I should have done `environment --ad-hoc`.

If it helps: that's exactly what I do.
Thanks for bringing the question btw. I was worried about my workflow being correct and it happens to be!

Re: Questions about Git and workflow

[Leo Famulari]

On Fri, Aug 21, 2020 at 10:51:29PM +0200, HiPhish wrote:
> OK, I'll try that. My main concern was with packages I actually want to run. 
> For example, last time I wanted to update the Neovim version, so I changed the 
> definition and installed Neovim in order to try it out a bit. But doing so 
> replaced my previous Neovim installation. I know the old one was still in the 
> store, but if I had borked the update I would have had the problem that my 
> text editor, which is what I use to edit Guile scripts, was messed up.
> 
> It's not a major problem, but still an annoyance. Perhaps instead of `install` 
> I should have done `environment --ad-hoc`.

If your text editor was broken, you could use `guix package --roll-back`
to go back to the working version.

If you needed to go back a few times, you could use `guix package
--list-generations` and `guix package --switch-generation=N`.

If you knew the editor was broken, but wanted to update everything else,
you could do `guix package --upgrade=. --do-not-upgrade=neovim`. Since
those arguments accept regular expressions, the dot "." means
"everything".

I do agree that `guix environment --ad-hoc` is often more convenient
while experimenting.

In general, it's a goal of Guix that broken updates should be easy to
recover from.

I hope that helps!

Re: Questions about Git and workflow

[HiPhish]

On Friday, 21 August 2020 22:59:32 CEST Ekaitz Zarraga wrote:
> Thanks for bringing the question btw. I was worried about my workflow being
> correct and it happens to be!

Yeah, I wouldn't be surprised if there are more people who would like to 
contribute, but then stumble on these minor irregularities and just give up. I 
had contributed a few patches in the past, but each time it felt like stepping 
on eggshells to me. It would be nice if one of the maintainers could have 
chimed in.