From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christine Lemmer-Webber Newsgroups: gmane.lisp.guile.user Subject: Re: Newbie thoughts on Guile Hall + Guix Date: Sat, 05 Feb 2022 19:40:35 -0500 Message-ID: <87v8xsq0zl.fsf@dustycloud.org> References: <87iltt846s.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12304"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.10; emacs 27.2 Cc: guile-user To: mikael@djurfeldt.com Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sun Feb 06 01:47:26 2022 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nGViA-00032e-KB for guile-user@m.gmane-mx.org; Sun, 06 Feb 2022 01:47:26 +0100 Original-Received: from localhost ([::1]:58364 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nGVi9-000858-6V for guile-user@m.gmane-mx.org; Sat, 05 Feb 2022 19:47:25 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49156) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGVdf-0007p9-4W for guile-user@gnu.org; Sat, 05 Feb 2022 19:42:55 -0500 Original-Received: from dustycloud.org ([50.116.34.160]:40398) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGVda-0004PP-Bp for guile-user@gnu.org; Sat, 05 Feb 2022 19:42:44 -0500 Original-Received: from chicory (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id 2A98D26617; Sat, 5 Feb 2022 19:42:39 -0500 (EST) In-reply-to: Received-SPF: pass client-ip=50.116.34.160; envelope-from=cwebber@dustycloud.org; helo=dustycloud.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:18002 Archived-At: 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 writes: > It would also be nice if we could have a Guile package repository. > > Den l=C3=B6r 5 feb. 2022 21:11Christine Lemmer-Webber 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