Re: Blog: Guix packaging tutorial

[Ricardo Wurmus]

Hi Pierre,

> I'd like to post a blog article which would serve as a packaging
> tutorial.

This is an excellent idea!

> --8<---------------cut here---------------start------------->8---
> 0. Introduction
> The perks of Guix, what it means to have a full-fledged programming
> language at hand for package management (e.g. inheritance, en-masse
> modifications).
>
> 1. General
> Go through the various fields of the `package` record.
> GUIX_PACKAGE_PATH, `guix build` and `guix package`.

I have mixed feelings about recommending GUIX_PACKAGE_PATH to new
contributors.  I think that generally it is better to guide them to
working on a git checkout directly, because moving packages from a
separate GUIX_PACKAGE_PATH module to Guix proper isn’t frictionless.

> Where to read about the build systems: Guix source code.

The manual is probably a better place to read about the build systems
(section 4.2 Build systems).

> 2. Trivial build system
> Provide a complete example.

I would skip the trivial build system because it is rather complicated
and may scare readers off.

> 3. GNU build system
> - Provide a complete, argument-free example.
> - Provide a complete example with arguments such as extra configure/make
> flags, some substitution, a snippet, etc.

Sounds good!

> 4. Conclusion
> Further reading, more build systems, tips & tricks.
> Maybe mention a few complex package declarations

Maybe also mention the recursive importers to automate a large part of
the work for packages from Pypi, CRAN, Bioconductor, etc.

> I'm mostly wondering whether the GNU build system should be introduced
> before the trivial build system: it's simpler and would let the user
> have a first package ready within minutes with fewer lines of code to
> understand; conversely, it also means that we would first take some
> black-box systems for granted ("What the hell happens under the hood?",
> might some readers wonder) which would only be explained later.

In my opinion, the power of abstraction over conventional build systems
is very impressive.  Instead of having to write a shell snippet that
does “./configure --prefix=/foo && make && make install” you can lean
back and use “gnu-build-system” instead.

>From there it’s easy to talk about packages that *don’t* use
conventional build systems or that otherwise deviate from conventions,
which is one reason for using modify-phases.

Thanks for your initiative!

--
Ricardo