Re: Newbie thoughts on Guile Hall + Guix

[Mikael Djurfeldt <mikael@djurfeldt.com>]

It would also be nice if we could have a Guile package repository.

Den lör 5 feb. 2022 21:11Christine Lemmer-Webber <cwebber@dustycloud.org>
skrev:

> 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
>
>