Re: [ANN] Guile Hall 0.3.0 released

[Nala Ginrut <nalaginrut@gmail.com>]

Thanks for the work!
I'd like to use it in my next project, and introduce it in my new book.

Best regards.


On Sat, May 16, 2020, 23:42 Alex Sassmannshausen <
alex.sassmannshausen@gmail.com> wrote:

> Hello,
>
> I have the pleasure to announce that I have today released Guile Hall
> 0.3.0.
>
> You can get a tarball (that requires autoreconf) at
> https://gitlab.com/a-sassmannshausen/guile-hall/-/releases.
>
> You can also install it with the latest Guix (from a3dfe05285):
> $ guix install guile-hall
>
> You can check the source code, and report issues at
> https://gitlab.com/a-sassmannshausen/guile-hall/.
>
> I would like to thank the following people, who have all contributed
> issues, thougts or code.
>
>     Stephen Scheck <singularsyntax@gmail.com>
>     Jose A. Ortega Ruiz <jao@gnu.org>
>     Jack Hill <jackhill@jackhill.us>
>     Adriano Peluso <catonano@gmail.com>
>
> Release notes below, under * Changes in 0.3 (since 0.2.1).
>
> * From the README file
>
> Hall aims to provide a black box that "just works" (tm), so that you
> can create, develop, build & distribute Guile projects.
>
> With Hall you will be able to:
> - Manage a Guile project hierarchy from one project spec file.
> - Transparently support the GNU build system for maximum portability.
> - Leverage tight coupling to Guix for reliability & confidence.
> - Profit.
>
> This README is all written documentation that currently exists.  The
> project must be considered Alpha software at this stage.
>
> Nonetheless, all commands and arguments are documented, and passing
> the -h flag to any command or sub-command should provide you with some
> guidance.  In addition all procedures in the codebase are documented
> with docstrings.
>
> * Changes in 0.3 (since 0.2.1)
>
> ** Allow adding single files to hall.scm using `hall scan'
>
>    `hall scan' now accepts two optional arguments so that you can quickly
> add
>    individual files to your hall.scm file, even if your project state is
>    dirty.  This is an alternative to running the full auto-magic `hall
> scan'
>    command.
>
> ** Emit user friendly error messages for common failures
>
>    Hitherto we simply used `throw' to error out of unexpected situations.
>    This would happen even in the case of user error or predictable
> situations.
>
>    I consider the codebase solid enough to emit more user-friendly error
>    messages in predictable situations.
>
> ** Allow use of fully-fledged regexp to --skip files
>
>    The `scan' and `clean' subcommands accept a --skip keyword to exclude
>    specific (classes of) files from their operation.  So far they had to be
>    precise files.  The --skip keyword now expects Guile style regex pattern
>    strings for increased flexibility.
>
> ** Add a notes system for giving advice to the user
>
>    Hall aims to understand your project and the files it contains, even if
> it
>    does not fully support your use case.  To this end, its architecture
>    creates a representation of your project in the hall.scm file.
>
>    Hall now has a facility for emitting useful commentary when creating or
>    manipulating this representation.
>
>    A current case in point at present is that we understand that Guile
>    projects may include C files — but Hall does not support them in its
> build
>    infrastructure.  So we want to allow & support users who include C
> files,
>    but we want to warn them about Hall's short-comings in this area.
>
> ** Change the filetype architecture
>
>    So far, filetype registration code was spread out over the codebase.
> From
>    this version we support a simple <filetype> interface.  Supported
> filetypes
>    are declared in /hall/spec.scm.
>
>    Supporting more filetypes is as easy as adding a simple declaration
> there.
>
>    This sets up a further development allowing individual projects to
> specify
>    filetypes above and beyond Hall's built-in filetypes.
>
> ** Support XML, C, .log, .trs, .tex, & emacs autosave/backup files
>
>    A simple development thanks to the above.
>
> ** Add a default .gitignore file
>
>    Hall has strong opinions about development, primarily to stop new
>    developers from having to make bewildering choices.  Currently it pushes
>    strong git & guix integration, as well as a specific documentation and
>    folder structure.  As such we now add a standard .gitignore file that
>    should cover the vast majority of use cases.
>
>