unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: "Aleix Conchillo Flaqué" <aconchillo@gmail.com>
To: Christine Lemmer-Webber <cwebber@dustycloud.org>
Cc: guile-user <guile-user@gnu.org>
Subject: Re: Newbie thoughts on Guile Hall + Guix
Date: Sat, 5 Feb 2022 20:54:14 -0800	[thread overview]
Message-ID: <CA+XASoU6x170hC2F0E=VxFeeHu7DFGr-OcbbZAfd8jACnU-TRA@mail.gmail.com> (raw)
In-Reply-To: <87v8xsq0zl.fsf@dustycloud.org>

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


  reply	other threads:[~2022-02-06  4:54 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-05 20:01 Newbie thoughts on Guile Hall + Guix Christine Lemmer-Webber
2022-02-05 22:15 ` Mikael Djurfeldt
2022-02-05 23:19   ` Jose Antonio Ortega Ruiz
2022-02-06 14:09     ` Ricardo Wurmus
2022-02-06  0:40   ` Christine Lemmer-Webber
2022-02-06  4:54     ` Aleix Conchillo Flaqué [this message]
2022-02-06 13:14       ` Mikael Djurfeldt
2022-02-06 14:03         ` Ricardo Wurmus
2022-02-06 14:28           ` Vijay Marupudi
2022-02-06 14:53             ` Ognen Duzlevski
2022-02-06 15:13               ` Maxime Devos
2022-02-06 15:29               ` Vijay Marupudi
2022-02-06 21:34                 ` Zelphir Kaltstahl
2022-02-07  2:11                   ` David Pirotte
2022-02-07  2:47                     ` David Pirotte
2022-02-07 19:21                     ` Zelphir Kaltstahl
2022-02-07 22:35                   ` adriano
2022-02-05 22:16 ` Vivien
2022-02-06  2:53 ` Zelphir Kaltstahl
2022-02-06 16:35 ` Olivier Dion via General Guile related discussions
2022-02-06 16:44   ` Vivien Kraus
2022-02-06 22:10     ` Olivier Dion via General Guile related discussions
2022-02-06 16:55   ` Maxime Devos
2022-02-06 22:05     ` Olivier Dion via General Guile related discussions
2022-02-06 22:32       ` Maxime Devos
2022-02-06 23:00         ` Olivier Dion via General Guile related discussions
2022-02-06 21:37   ` Zelphir Kaltstahl
2022-02-06 22:12     ` Olivier Dion via General Guile related discussions
  -- strict thread matches above, loose matches on Subject: below --
2022-02-06 13:40 dsmich
2022-02-08 12:19 Blake Shaw
2022-02-08 19:46 ` Chris Vine
2022-02-09  6:28 ` Catonano
2022-02-08 16:13 Blake Shaw
2022-02-09  3:23 Blake Shaw
2022-02-09 10:30 Blake Shaw
2022-02-09 14:13 ` Olivier Dion via General Guile related discussions
2022-02-09 20:05   ` Aleix Conchillo Flaqué
2022-02-09 20:28     ` Maxime Devos
2022-02-09 21:13       ` Aleix Conchillo Flaqué
2022-02-10 18:03     ` Vivien
2022-02-10 12:42 Blake Shaw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+XASoU6x170hC2F0E=VxFeeHu7DFGr-OcbbZAfd8jACnU-TRA@mail.gmail.com' \
    --to=aconchillo@gmail.com \
    --cc=cwebber@dustycloud.org \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).