Re: Newbie thoughts on Guile Hall + Guix

[Aleix Conchillo Flaqué]

I will have to disagree on this one. Not about Guix being great :-). I
believe a simple, lightweight, integrated and cross platform package
manager for Guile would be fantastic.

For reasons that don't matter right now I have been using macOS for the
past two years and I wish I had a package manager. Since I didn't have one
I created Guile Homebrew which I'm probably the only one using. However, I
would love to have something like other languages have as jao and Zelphir
suggest. It is true that Guix would solve the reproducibility issue, but
installing Guix and having a completely separate system of libraries just
to write some project is overkill, at least for me. Maybe it makes sense
for some specific projects but for most of the things that people work on I
would say it probably doesn't. Plus, it doesn't work on macOS but that's
another story.

Speaking about package managers for Guile, some might remember about
Guildhall (https://github.com/ijp/guildhall), maybe it's waiting there for
someone to pick it up.

Aleix

On Sat, Feb 5, 2022 at 4:47 PM Christine Lemmer-Webber <
cwebber@dustycloud.org> wrote:

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