Re: Newbie thoughts on Guile Hall + Guix

[Zelphir Kaltstahl]

On 2/5/22 21:01, Christine Lemmer-Webber wrote:
> Hello!
>
> 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 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.
>
>   - Its ability to make an autotools-compatible tarball, but without me
>     needing to think about autotools at all, is a real delight.
>
>   - Its test suite stuff is also really nice.
>
>   - 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.
>
>   - 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.
>
>   - "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!"
>
>   - 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.
>   
>   - 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.
>     
> Anyway, just some thoughts.  Making Guile packages is already much less
> intimidating now thanks to Hall's work.  Thank you for it!
>
>   - Christine

For what it is worth: You do not need to use Hall, if you do not need to run 
tests, when installing via Guix or similar things. If you are fine with running 
tests before publishing a version of a package to Guix, then you only need Guix 
and a package definition. No autotools.

I found all the stuff that is generated by Hall a bit worrying. Lots of 
autotools appearing in my repository, which I do not fully understand. Being 
forced to use hall scan and so on. Too much magic behind the scenes. Packaging 
should be so simple, that I can still easily understand all the things in my 
repository, without studying autotools for a week, searching for archaic 
variable names and what they to and how everything works. I am not a huge fan of 
the JS ecosystem at all, but if we look at the NPM world, there is only one file 
that needs to exist, the package.json, and already you have a valid package. Why 
can it not be the same simplicity for Guile? And if Guix really requires there 
to be a `make` `make check` or whatever, then where is the guide, that tells me 
how to hand-craft the Makefile, so that everything works and I don't need extra 
tooling to generate files.

I want to be able to edit the guix package definition, point it to the tests 
directory, and be done with it. When I use Hall, then I have yet another tool in 
the workflow. Again more commands and things to keep in mind. I want less tools 
and simplicity. I don't run autotools for running my tests locally, so there is 
no theoretical need for that. The maximum I do it a very simple Makefile, which 
provides me with a `make test` to run tests or `make` to run the program. It is 
just that from the Guix side of things, something would have to be done to be 
able to invoke tests properly, without a `make test` command being available, 
but knowing where the tests are. They could be declared in the package 
definition for example. Why do I need any autotools stuff? Just make Guix call 
my SRFI-64 tests.

This is why I decided to not use Hall for guile-fslib. I did not like the 
complexity of having all the autotools stuff in my repo, which I don't even 
fully understand, just for it becoming a package. Even if I don't need to 
manually touch any of those files. I can run tests on my machine before sending 
in a patch for a new version and that will be fine.

Hall is probably a great thing, if you have a package, that is not pure Guile, 
so that one has to do other things than simply running a Guile command to run 
the tests, perhaps to generate documentation or other files. For pure Guile 
packages, I still need to see or learn about a good reason to add the complexity 
of it to a repository.

Best regards,
Zelphir

--
repositories: https://notabug.org/ZelphirKaltstahl