[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A simple workflow for adding apps guix
From: |
Marius Bakke |
Subject: |
Re: A simple workflow for adding apps guix |
Date: |
Sun, 16 Apr 2017 20:21:33 +0200 |
User-agent: |
Notmuch/0.24.1 (https://notmuchmail.org) Emacs/25.1.1 (x86_64-unknown-linux-gnu) |
Feng Shu <address@hidden> writes:
> The below is the workflow I used current, any other
> simpler workflow exists? comments are welcome!
Hello! If you intend to submit these packages, I would recommend working
directly from the main git repository rather than messing with
GUIX_PACKAGE_PATH. Have a look at the "Running Guix before it is
installed" section in the manual:
https://www.gnu.org/software/guix/manual/guix.html#Running-Guix-Before-It-Is-Installed
There is a 'pre-inst-env' script that makes testing local changes easy.
Here is my typical workflow (motley gear optional):
# Start with a clean master branch.
$ git checkout master
$ git pull # sometimes "--rebase" or simply `git reset --hard`..
# Create environment with all Guix dependencies.
$ ge guix # "ge" is an alias for `guix environment`...
# If this is a new machine, prepare the sources for this environment.
$ ./bootstrap
$ ./configure --localstatedir=/var
# Now compile everything. This is typically done after each `pull`.
$ make -j10
# Phew! Now let's start working on our package.
$ git checkout -b package-foo
<insert matrix gif>
$ ./pre-inst-env guix build foo # installing works too
# It builds! Let's commit it.
$ git add -p
$ git commit
# D'oh! Something was not right.
$ ./pre-inst-env guix edit foo # I don't actually use this, but..
$ ./pre-inst-env guix build foo
# Great, this looks better.
$ git add -p
$ git commit --amend # or --fixup=<commit> for later rebasing..
<repeat last steps 0-20 times for each patch>
# Allright, now we can submit it!
$ mkdir outgoing # Not really necessary, but easier to "clean".
$ git format-patch --cover-letter -n origin/master -o outgoing/
$ edit outgoing/0000-cover-letter.patch
# Cover letter can be omitted, but is a good way to give some background
# info, raise questions, etc. Now, let's send it to open a bug report.
$ git send-email --to address@hidden outgoing/0000-cover-letter.patch
# Now we have a bug URL! Let's send the remainder there.
$ rm outgoing/0000-cover-letter.patch
$ git send-email --to address@hidden outgoing/*.patch
You can also make ~/.config/guix/latest a soft link to your git checkout
and largely avoid the need for `./pre-inst-env`. I don't actually do
that on my main development machine, since I need the `guix` command to
always work, and my work tree is rarely "sane" :P instead, I manage my
entire profile through `./pre-inst-env` and run `guix pull` once per
week or so. I've been meaning to try git-worktree(1) instead.
Hope it helps! Always interesting to see other workflows :)
signature.asc
Description: PGP signature