Re: Newbie thoughts on Guile Hall + Guix

[Vivien]

Hello Christine, Hall, and the rest of Guile! 

Le samedi 05 février 2022 à 15:01 -0500, Christine Lemmer-Webber a
écrit :
> It's been a while since Guile was my main hacking environment; I've
> been
> returning to it, and one of the nicest things to change about its
> ecosystem is the presence of Guile Hall.

I’m starting to convert my project to hall as well :)

> I really, really like Guile Hall.  A lot!  I think it has room to
> grow
> but it fills a clearly missing piece of the Guile ecosystem while
> doing
> it in the best way possible: making itself explicitly compatible with
> Guix.
> 
> I thought I'd write down some impressions while everything is fresh.

Let me do the same thing.


>  - Its ability to make an autotools-compatible tarball, but without
> me
>    needing to think about autotools at all, is a real delight.

The automake and m4 meta-programming languages are good for what they
do, but if we’re also writing scheme for the build system, it would
become too much.


>  - Its test suite stuff is also really nice.

Using the SRFI 64 API lowers the cost to add tests, which is especially
good for such a dynamic and flexible language as guile.

>  - I found myself surprised that hall.scm is "just data", instead of
>    taking the more guix'y approach of being code that actually builds
> a
>    datastucture.  I'm not sure what the goal of this is; there can be
>    reasons to take that approach but I'm not sure what it is here?
>    My assumption is that the main reason is so that "hall scan" can
>    correctly read and then modify and spit out another file, but I'm
>    not sure.

It was a problem for me too. I wanted to compute the version number
from git describe, and it turns out I couldn’t do that in hall.scm. I
had to create a bootstrap script to generate hall.scm, run hall scan
and then other hall commands (and then autoreconf). This approach is
more functional, because there’s less state (I consider auto-generated
Makefile.am, configure.ac and similar files as state because hall and I
are supposed to edit them). It means I can git-ignore most of the stuff
that hall dist generates.

>  - What I would actually *really* like would be for the Hall package
>    definition structure to be a wrapper *around* the Guix package
>    structure.  Then the guix.scm would be really simple: it could
> just
>    "peel off" the outer struct.  If I wanted to do some smart
>    modifications of things from there maybe I could.  I dunno,
> something
>    like this.

>From what I remember, the guix package data structure is a guix record;
is specific to guix. Hall would need to depend on guix (or, my
preferred solution, guix would use GOOPS classes instead of guix
records for more things, including packages, but we’re not there yet!).

I also have a more dynamic guix.scm (I wouldn’t call it smart though).
It puts the current commit in the store, runs "hall guix" there, loads
the generated guix.scm file, and fixes the package it evaluates to (so
as to use the current commit as a source and add hall as a native-
input, for instance).

Guix shell doesn’t like stuff that’s too smart in guix.scm though,
because of its cache.

> 
>  - "hall scan" is really cool, but I kind of wish I didn't need to
> use
>    it.  I'd rather not keep track of any of this stuff at all.
>    I'd be happy just pointing some code at a directory and say "snarf
>    up all the .scm files you see therein!"

Such a wildcard pattern was heavily discouraged in the past, because
you could forget to distribute some files and there wouldn’t be a good
way to know why the build would fail on someone else’s computer due to
a missing file. Nowadays, we have git (and other version control
systems) and continuous integration, so I don’t see a reason why what
you want would be a problem.

> 
>  - I'm currently writing a manual starting in a .org file that's then
>    converted into a .texi file.  I'd prefer if I could find an
>    entrypoint to insert this into the compilation workflow: a pre-
> step
>    to the docs compilation that generates the .texi file *from* my
>    .org file.

I think it would be easier for hall to support org->texi conversion
natively, so that we could still code without automake knowledge. For
instance, as you must have noticed, implementing the conversion as an
automake rule means that automake will fail because it won’t know
whether the generated file needs version.texi.

>  - On that note, it strikes me that Hall's integration with autotools
>    is great because it means that existing distros don't need to be
>    aware of Guile *or* Guix.  But it also means that Hall probably
> has
>    all of the information that it could do all the steps that
> autoconf
>    and automake do too.  That might be interesting to see that.

You mean that hall could implement all of the autotools features? Even
if we remove C-related features, hoping that we won’t need to write C
code ever again, that’s still a lot to ask for. I’m not sure it would
be pragmatic for hall to try and do that.

>    
> Anyway, just some thoughts.  Making Guile packages is already much
> less
> intimidating now thanks to Hall's work.

I must add, that gettext support is crucial and missing. Fortunately, I
can fix the generated autotools infrastructure in my custom bootstrap
phase but it isn’t pretty: I have to invoke emacs to fix configure.ac
and Makefile.am, for instance. It shouldn’t be too hard for hall to
support gettext: hall already knows the list of source files, so it can
generate POTFILES.in. We would just need to specify the LINGUAS list in
hall.scm and it could do the rest.

As a conclusion, hall fits exactly what I expect it to do, and it’s
almost always a pleasure to work with, but I wish it were more
functional (not keeping hall.scm, configure.ac and Makefile.am as
state) and I think it should support gettext natively.

Vivien