Re: Newbie thoughts on Guile Hall + Guix

[Christine Lemmer-Webber <cwebber@dustycloud.org>]

IMO, we have, that, and it is Guix.  I'm actually quite happy about
that.  :)

Specific-language-package-repos have caused a lot of the mess we're
currently in; in an unexpected way, it's hurt user freedom a lot,
because mixing these is so hard that software which might be otherwise
reproducible and usable by everyone becomes only deployable by "expert"
devops teams deploying ad-hoc container black boxes who are themselves
very overloaded and have a hard time keeping on top of what's going on.

Guix is great.  I'd love Guix to become the universal package repository
for all FOSS languages. :)

 - Christine

Mikael Djurfeldt <mikael@djurfeldt.com> writes:

> 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