On Thu, Sep 13, 2018 at 01:53:16PM +0200, Ricardo Wurmus wrote:
> > 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.
Yes, the GUIX_PACKAGE_PATH serves a different purpose. Main thing you
want to capture is package definitions and perhaps the workflow of
submitting a patch.
> 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.
And it is less specialized. Hard coding configure options is the road
to madness - at least where it comes to targetting multiple outputs.
That is where packaging systems like conda fall short.
> 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.
A second advanced hacking tutorial could discuss more advanced
features.
Pj.
