Re: Newbie thoughts on Guile Hall + Guix

[Mikael Djurfeldt]

I also think that there is a need for something light-weight and cross
platform. I think, e.g., that PyPI is one of the main reasons for the
success of Python and that the lack of something in that direction is
holding Guile back.

Even though Guix is a great project, I can think of many instances where
you would like to use Guile packages but would hesitate to install Guix, or
simply can't.

Maybe it is possible to do it in a way that integrates well with Guix, e.g.
such that the light-weight packages would automatically also be Guix
packages?

I'm not sure that "light-weight" should mean pure scheme, though, since
that would exclude things dependent upon external libraries, like NumPy.
After all, one of the roles of Guile is to be an embedded language. So, the
question is if it would be possible to use aspects of Guix and Hall---to
refactor things, perhaps akin to the peeling off that Christine is talking
about? Maybe with some extra support for the non-Guix case such that the
package would work both within snd outside of Guix? Am I crazy?

Best regards,
Mikael

Den sön 6 feb. 2022 05:54Aleix Conchillo Flaqué <aconchillo@gmail.com>
skrev:

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