Re: Questions about Git and workflow
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.
Re: Questions about Git and workflow
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
> 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
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
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
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.
