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: Newbie thoughts on Guile Hall + Guix Date: Sat, 05 Feb 2022 15:01:14 -0500 Message-ID: <87iltt846s.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40142"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.10; emacs 27.2 To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sat Feb 05 21:11:19 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 1nGROx-000AJZ-C0 for guile-user@m.gmane-mx.org; Sat, 05 Feb 2022 21:11:19 +0100 Original-Received: from localhost ([::1]:56170 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nGROv-0006f0-K1 for guile-user@m.gmane-mx.org; Sat, 05 Feb 2022 15:11:17 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:42326) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGROc-0006eq-N0 for guile-user@gnu.org; Sat, 05 Feb 2022 15:10:58 -0500 Original-Received: from dustycloud.org ([50.116.34.160]:40396) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGROZ-0001bn-BU for guile-user@gnu.org; Sat, 05 Feb 2022 15:10:58 -0500 Original-Received: from chicory (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id 59C5426617 for ; Sat, 5 Feb 2022 15:10:53 -0500 (EST) 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:17998 Archived-At: 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