A simple workflow for adding apps guix

A simple workflow for adding apps guix

[Feng Shu]

The below is the workflow I used current, any other
simpler workflow exists?  comments are welcome!

* I want to add emacs-exwm to emacs.scm

* Fetch newest code
#+BEGIN_EXAMPLE
cd ~/project/guix/  # my guix repo dir
git pull --rebase
#+END_EXAMPLE

* Install newest guix
#+BEGIN_EXAMPLE
guix pull
#+END_EXAMPLE

* Set GUIX_PACKAGE_PATH
#+BEGIN_EXAMPLE
export GUIX_PACKAGE_PATH=${HOME}/guix # I put it to ~/.bashrc :-)
mkdir ~/guix
#+END_EXAMPLE

* Privatize emacs.scm file
#+BEGIN_EXAMPLE
cd ~/guix
mkdir -p gnu/packages
cd gnu/packages
ln -s ~/project/guix/gnu/packages/emacs.scm  # guix repo's emacs.scm file
#+END_EXAMPLE

* Hack -> test -> hack -> test ....

edit ~/project/guix/gnu/packages/emacs.scm
...

Build:   guix build emacs-exwm
Rebuild: guix build emacs-exwm --check
Install: guix package -i emacs-exwm


-- 

Re: A simple workflow for adding apps guix

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2563 bytes --]

Feng Shu <tumashu@163.com> 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 guix-patches@gnu.org 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 NNNNN@debbugs.gnu.org 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 :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re:Re: A simple workflow for adding apps guix

[tumashu]

[-- Attachment #1: Type: text/plain, Size: 2905 bytes --]

Document shows that the following code is needed:  

           sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild

it seem that normal "guix build" will broken when I run the above code and close it.




At 2017-04-17 02:21:33, "Marius Bakke" <mbakke@fastmail.com> wrote:
>Feng Shu <tumashu@163.com> 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 guix-patches@gnu.org 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 NNNNN@debbugs.gnu.org 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 :)

[-- Attachment #2: Type: text/html, Size: 3351 bytes --]

Re: A simple workflow for adding apps guix

[Feng Shu, Marius Bakke]

"Feng Shu" <tumashu@163.com> writes:

The below is my simple workflow, maybe useful :-)

-------------------------------------------------------------------
#+TITLE:  Feng Shu's guix devel workflow

If you just want to add a new guix package or upgrade a exist guix package,
The below workflow may be useful.

If you want to hack guix's other code, I suggest you just leave and read
guix manual :-)


* Fetch guix.git
#+BEGIN_EXAMPLE
cd ~/project
git clone git clone https://git.savannah.gnu.org/guix.git
#+END_EXAMPLE

* Install emacs
#+BEGIN_EXAMPLE
guix package -i emacs
#+END_EXAMPLE

* Install emacs packages
1. guix
2. counsel
3. swiper
4. gitpatch
5. magit

* Config emacs
1. guix-directory is your *guix git repo directory*
2. "~/.config/guix/latest" is the latest guix you have install.
#+BEGIN_SRC emacs-lisp
(use-package guix
  :ensure nil
  :config
  (setq guix-directory "~/project/guix")
  (add-hook 'after-init-hook 'global-guix-prettify-mode)
  (add-hook 'scheme-mode-hook 'guix-devel-mode)
  (with-eval-after-load 'geiser-guile
    ;; NOTE: "~/.config/guix/latest/" is invaild,
    ;; use "~/.config/guix/latest" instead.
    (add-to-list 'geiser-guile-load-path
                 (concat (file-name-directory (locate-library "geiser.el"))
                         "scheme/guile"))
    (add-to-list 'geiser-guile-load-path "~/.config/guix/latest")))
#+END_SRC

* Hack code
I use package emacs-exwm-x as an example:

1. Open "~/project/guix/gnu/packages/emacs.scm" with emacs
2. Hack code
   1.  Type "C-c C-z" (geiser-mode-switch-to-repl), A new guile buffer will open.
   2.  Type "C-c C-z" again, you will switch to emacs.scm file buffer.
   3.  Type "C-c . u" to load guix module (guix-devel-use-module), 1-3 second is need.
   4.  Type "C-s" to search emacs-exwm-x's define-public and jump to it.
   5.  Type "C-c C-c" or "C-M-x" to eval emacs-exwm-x's define-public
   6.  Error is found, eval switch-window's define-public and eval emacs-exwm-x's define-public again.
       For emacs-exwm-x depend switch-window
   7.  Hack emacs-exwm-x's define-public ....
   8.  Type "C-c . d" to download emacs-exwm-x's source and get sha256 string.
       #+BEGIN_EXAMPLE
       (sha256
         (base32
            "1ny13i82fb72917jgl0ndwjg1x6l9f8gfhcx7cwlwhh5saq23mvy"))
       #+END_EXAMPLE
   9.  Hack finished ...
   10. (Importent) Type "C-c C-c" or "C-M-x" to eval emacs-exwm-x's define-public
   11. Type "C-c . b" to build newest emacs-exwm-x :-)
   12. Hack, deal with build problem ...

3. Commit and send-patch
   1. I use counsel-git-log to find a history commit message as commit template :-)
   2. git pull --rebase (make sure the patch we generate can am to guix master)
   3. I use magit-format-patch to generate patch file.
   4. I use gitpatch-mail command to send patch to guix-patches@gnu.org
      it use message-mode or gnus.
      #+BEGIN_SRC emacs-lisp
      (use-package gitpatch
        :bind (("C-c m" . gitpatch-mail))
        :ensure nil
        :config
        (setq gitpatch-mail-function 'gnus-msg-mail)
        (setq gitpatch-mail-attach-patch-key "C-c i")
        (setq gitpatch-mail-database
              '("guix-patches@gnu.org"
                "emms-help@gnu.org"
                "emacs-orgmode@gnu.org"
                "emacs-devel@gnu.org")))
      #+END_SRC

-------------------------------------------------------------------------
> Marius Bakke <mbakke@fastmail.com> writes:
>
> Now, I finally make my guix devel workflow :-)
>
> ----------------------------------------------------------------------
>
> #+TITLE:  Feng Shu's guix devel workflow
>
> If you just want to add a new guix package or upgrade a exist guix package,
> The below workflow may be useful.
>
> If you want to hack guix's other code, I suggest you just leave and read
> guix manual :-)
>
>
> * Fetch guix.git
>
> #+BEGIN_EXAMPLE
> cd ~/project
> git clone git clone https://git.savannah.gnu.org/guix.git
> #+END_EXAMPLE
>
>
> * Install emacs
>
> #+BEGIN_EXAMPLE
> guix package -i emacs
> #+END_EXAMPLE
>
>
> * Install emacs packages
> 1. guix
> 2. counsel
> 3. swiper
> 4. gitpatch
> 5. magit
>
> * Config emacs
> 1. guix-directory is your *guix git repo directory*
> 2. "~/.config/guix/latest" is the latest guix you have install.
>
> #+BEGIN_SRC emacs-lisp
> (use-package guix
>   :ensure nil
>   :config
>   (setq guix-directory "~/project/guix")
>   (add-hook 'after-init-hook 'global-guix-prettify-mode)
>   (add-hook 'scheme-mode-hook 'guix-devel-mode)
>   (with-eval-after-load 'geiser-guile
>     ;; NOTE: "~/.config/guix/latest/" is invaild,
>     ;; use "~/.config/guix/latest" instead.
>     (add-to-list 'geiser-guile-load-path
>                  (concat (file-name-directory (locate-library "geiser.el"))
>                          "scheme/guile"))
>     (add-to-list 'geiser-guile-load-path "~/.config/guix/latest")))
> #+END_SRC
>
>
> * Hack code
> I use package emacs-exwm-x as an example:
>
> 1. Open "~/project/guix/gnu/packages/emacs.scm" with emacs
> 2. Hack code
>    1.  Type "C-c C-z" (geiser-mode-switch-to-repl), A new guile buffer will open.
>    2.  Type "C-c C-z" again, you will switch to emacs.scm file buffer.
>    3.  Type "C-c . u" to load guix module (guix-devel-use-module), 1-3 second is need.
>    4.  Type "C-s" to search emacs-exwm-x's define-public and jump to it.
>    5.  Type "C-c C-c" or "C-M-x" to eval emacs-exwm-x's define-public
>    6.  Error is found, eval switch-window's define-public and eval emacs-exwm-x's define-public again.
>        For emacs-exwm-x depend switch-window
>    7.  Hack emacs-exwm-x's define-public ....
>    8.  Type "C-c . d" to download emacs-exwm-x's source and get sha256 string.
>
>        #+BEGIN_EXAMPLE
>        (sha256
>          (base32
>             "1ny13i82fb72917jgl0ndwjg1x6l9f8gfhcx7cwlwhh5saq23mvy"))
>        #+END_EXAMPLE
>
>    9.  Hack finished ...
>    10. (Importent) Type "C-c C-c" or "C-M-x" to eval emacs-exwm-x's define-public
>    11. Type "C-c . b" to build newest emacs-exwm-x :-)
>    12. Hack, deal with build problem ...
>
> 3. Commit and send-patch
>    1. I use counsel-git-log to find a history commit message as commit template :-)
>    2. I use magit-format-patch to generate patch file.
>    3. I use gitpatch-mail command to send patch to guix-patches@gnu.org
>       it use message-mode or gnus.
>
>       #+BEGIN_SRC emacs-lisp
>       (use-package gitpatch
>         :bind (("C-c m" . gitpatch-mail))
>         :ensure nil
>         :config
>         (setq gitpatch-mail-function 'gnus-msg-mail)
>         (setq gitpatch-mail-attach-patch-key "C-c i")
>         (setq gitpatch-mail-database
>               '("guix-patches@gnu.org"
>                 "emms-help@gnu.org"
>                 "emacs-orgmode@gnu.org"
>                 "emacs-devel@gnu.org")))
>       #+END_SRC
>
> -------------------------------------------------------------------------------
>
>> Feng Shu <tumashu@163.com> 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 guix-patches@gnu.org 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 NNNNN@debbugs.gnu.org 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 :)
>>

-- 

Re: A simple workflow for adding apps guix

[Ricardo Wurmus]

tumashu <tumashu@163.com> writes:

> Document shows that the following code is needed:
>
>            sudo ./pre-inst-env guix-daemon --build-users-group=guixbuild
>
> it seem that normal "guix build" will broken when I run the above code and close it.

If you’re using Guix then the daemon should be running anyway.  This can
be done with the command above, but often people will enable a service
once and then keep it active instead of starting and stopping the daemon
manually.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net