[ANN] Guile Hall Release (v0.1.1)

[Alex Sassmannshausen]

Hello,

It is with great trepidation and joy that I finally release Hall to the
world.

You can get it with Guix after pulling the latest version with
$ guix package -i guile-hall

Otherwise you can get the code from
https://gitlab.com/a-sassmannshausen/guile-hall/, and build (hopefully)
using the traditional
$ autoreconf -vif && ./configure && make
dance.

What is Guile Hall?

From the README:

Hall is a command-line application and a set of Guile libraries that
allow you to quickly create and publish Guile projects. It allows you
to transparently support the GNU build system, manage a project
hierarchy & provides tight coupling to Guix.

It's fundamental aim is to provide a black box that just works (tm)
for you so you distribute, manage & create guile projects.

Currently I use it to manage my other published project, guile-config,
as well as some unpublished libraries, that I'll hopefully be able to
publish soon-ish.

This project is part of my overall goal of creating user-friendly basic
tooling & libraries for Guile to encourage newbies to start building
with Guile.

Feedback, thoughts or discussion very welcome!

Best wishes,

Alex

PS: I fully expect something to go wrong when the first person tries to
install / use it. Please let me know! :D

[Ludovic Courtès]

Hello Alex,

Post by Alex Sassmannshausen
Otherwise you can get the code from
https://gitlab.com/a-sassmannshausen/guile-hall/, and build (hopefully)
using the traditional
$ autoreconf -vif && ./configure && make
dance.
What is Guile Hall?
Hall is a command-line application and a set of Guile libraries that
allow you to quickly create and publish Guile projects. It allows you
to transparently support the GNU build system, manage a project
hierarchy & provides tight coupling to Guix.

This looks really great! There’s this longstanding issue with
distributing Guile code, and this seems to be a good approach.

In particular, that it’s not a Guix-only solution, while at the same
time offering Guix support is really a wise choice.

I think we should advertise it widely, it’ll be immensely helpful to
newcomers. When the manual is more complete ;-), we could refer to it
from guile.texi, too.

I wonder if it would be useful to have a “standalone” mode, where Hall
would rely neither on Autoconf/Automake nor on Guix to do basic things
like building code. It might help newcomers. You wouldn’t want to
reimplement everything though, so I don’t know if this is a viable
approach. Thoughts?

Thank you!

Ludo’.

[Alex Sassmannshausen]

Hi Ludo,

Post by Ludovic Courtès
Hello Alex,

Post by Alex Sassmannshausen
Otherwise you can get the code from
https://gitlab.com/a-sassmannshausen/guile-hall/, and build (hopefully)
using the traditional
$ autoreconf -vif && ./configure && make
dance.
What is Guile Hall?
Hall is a command-line application and a set of Guile libraries that
allow you to quickly create and publish Guile projects. It allows you
to transparently support the GNU build system, manage a project
hierarchy & provides tight coupling to Guix.

This looks really great! There’s this longstanding issue with
distributing Guile code, and this seems to be a good approach.
In particular, that it’s not a Guix-only solution, while at the same
time offering Guix support is really a wise choice.

Thanks for your kind and thoughtful notes :-)

Post by Ludovic Courtès
I think we should advertise it widely, it’ll be immensely helpful to
newcomers. When the manual is more complete ;-), we could refer to it
from guile.texi, too.

That would be wonderful — I'm particularly interested in hearing from
relative newcomers as to the user journey and/or ease of use!

I anticipate I'll be adding a manual for the next release or so, but I
want to see how the project performs in my own world, and in public for
a while first. It may need some re-architecturing!

Post by Ludovic Courtès
I wonder if it would be useful to have a “standalone” mode, where Hall
would rely neither on Autoconf/Automake nor on Guix to do basic things
like building code. It might help newcomers. You wouldn’t want to
reimplement everything though, so I don’t know if this is a viable
approach. Thoughts?

Interesting idea. When you say building code, do you mean literally
compiling a project within the project folder & perhaps generating a
wrapper script that might update GUILE_LOAD_{COMPILED_}PATH à la
pre-inst-env, or do you mean some form of installer?

My thinking guiding the project so far is that I think Guix is the
de-facto Guile package manager, and as such I want to encourage an easy
user-journey for people towards using/contributing to it. But if we can
offer a fully stand-alone "run your self-contained Guile project with no
dependencies" workflow, which offers a user journey to autotools/guix
distribution without the user having to do any additional work, then
that might certainly be interesting!

Post by Ludovic Courtès
Thank you!
Ludo’.

Thank you for your comments!

Alex

[Ludovic Courtès]

Heya,

Post by Alex Sassmannshausen

Post by Ludovic Courtès
I wonder if it would be useful to have a “standalone” mode, where Hall
would rely neither on Autoconf/Automake nor on Guix to do basic things
like building code. It might help newcomers. You wouldn’t want to
reimplement everything though, so I don’t know if this is a viable
approach. Thoughts?

Interesting idea. When you say building code, do you mean literally
compiling a project within the project folder & perhaps generating a
wrapper script that might update GUILE_LOAD_{COMPILED_}PATH à la
pre-inst-env, or do you mean some form of installer?

I’m thinking of a “hall build” command that would build Scheme files and
produce a wrapper script, and optionally “hall install” as well.

It’s interesting only if it can be done without reimplementing too much
of the Autoconf/Automake or Guix logic, I suppose.

Thanks,
Ludo’.

[alex sassmannshausen]

Post by Ludovic Courtès
Heya,

Post by Alex Sassmannshausen

Post by Ludovic Courtès
I wonder if it would be useful to have a “standalone” mode, where Hall
would rely neither on Autoconf/Automake nor on Guix to do basic things
like building code. It might help newcomers. You wouldn’t want to
reimplement everything though, so I don’t know if this is a viable
approach. Thoughts?

Interesting idea. When you say building code, do you mean literally
compiling a project within the project folder & perhaps generating a
wrapper script that might update GUILE_LOAD_{COMPILED_}PATH à la
pre-inst-env, or do you mean some form of installer?

I’m thinking of a “hall build” command that would build Scheme files and
produce a wrapper script, and optionally “hall install” as well.
It’s interesting only if it can be done without reimplementing too much
of the Autoconf/Automake or Guix logic, I suppose.

Agreed. I do think having some easy way of "running" your project would be
cool.

Thanks for your thoughts!

Alex

[Arne Babenhauserheide]

Gesendet: Dienstag, 03. Juli 2018 um 09:03 Uhr
Betreff: Re: [ANN] Guile Hall Release (v0.1.1)

Post by Ludovic Courtès
Heya,

Post by Alex Sassmannshausen

Post by Ludovic Courtès
I wonder if it would be useful to have a “standalone” mode, where Hall
would rely neither on Autoconf/Automake nor on Guix to do basic things
like building code. It might help newcomers. You wouldn’t want to
reimplement everything though, so I don’t know if this is a viable
approach. Thoughts?

Interesting idea. When you say building code, do you mean literally
compiling a project within the project folder & perhaps generating a
wrapper script that might update GUILE_LOAD_{COMPILED_}PATH à la
pre-inst-env, or do you mean some form of installer?

I’m thinking of a “hall build” command that would build Scheme files and
produce a wrapper script, and optionally “hall install” as well.
It’s interesting only if it can be done without reimplementing too much
of the Autoconf/Automake or Guix logic, I suppose.

Agreed. I do think having some easy way of "running" your project would be
cool.
Thanks for your thoughts!

A while ago I started a project which simply sets up autotools:

https://bitbucket.org/ArneBab/conf/src/default/

conf - Initialize modern autotools projects
Inspired by Mozilla Cargo ( http://doc.crates.io/guide.html ) but without the NIH and currently more limited in scope.
See NEWS for user-visible changes. See ChangeLog or the history for detailed changes.

Going that way allows re-using all the features of autotools by providing simple templates for common setups — and a starting point for more complex ones.

Then hall build can simply be a wrapper for ./bootstrap.sh && ./configure && make

Best wishes,
Arne

[alex sassmannshausen]

Hey Arne,

Post by Ludovic Courtès

Gesendet: Dienstag, 03. Juli 2018 um 09:03 Uhr
Betreff: Re: [ANN] Guile Hall Release (v0.1.1)

Post by Ludovic Courtès
Heya,

Post by Alex Sassmannshausen

Post by Ludovic Courtès
I wonder if it would be useful to have a “standalone” mode, where

Hall

Post by Ludovic Courtès

Post by Alex Sassmannshausen

Post by Ludovic Courtès
would rely neither on Autoconf/Automake nor on Guix to do basic

things

Post by Ludovic Courtès

Post by Alex Sassmannshausen

Post by Ludovic Courtès
like building code. It might help newcomers. You wouldn’t want to
reimplement everything though, so I don’t know if this is a viable
approach. Thoughts?

Interesting idea. When you say building code, do you mean literally
compiling a project within the project folder & perhaps generating a
wrapper script that might update GUILE_LOAD_{COMPILED_}PATH à la
pre-inst-env, or do you mean some form of installer?

I’m thinking of a “hall build” command that would build Scheme files

and

Post by Ludovic Courtès
produce a wrapper script, and optionally “hall install” as well.
It’s interesting only if it can be done without reimplementing too much
of the Autoconf/Automake or Guix logic, I suppose.

Agreed. I do think having some easy way of "running" your project would

be

cool.
Thanks for your thoughts!

https://bitbucket.org/ArneBab/conf/src/default/

conf - Initialize modern autotools projects
Inspired by Mozilla Cargo ( http://doc.crates.io/guide.html ) but

without the NIH and currently more limited in scope.

See NEWS for user-visible changes. See ChangeLog or the history for

detailed changes.
Going that way allows re-using all the features of autotools by providing
simple templates for common setups — and a starting point for more complex
ones.

From this description, it sounds fairly close to what hall does too! Sounds
like there's some overlap here :)

Then hall build can simply be a wrapper for ./bootstrap.sh && ./configure

Post by Ludovic Courtès
&& make

Right, that could indeed already be the implementation of hall build
actually. Thanks for that idea!


Alex

Best wishes,

Post by Ludovic Courtès
Arne

[Arne Babenhauserheide]

Post by alex sassmannshausen
Hey Arne,

Post by Ludovic Courtès

Gesendet: Dienstag, 03. Juli 2018 um 09:03 Uhr
Betreff: Re: [ANN] Guile Hall Release (v0.1.1)

Heya,

Post by Alex Sassmannshausen

I wonder if it would be useful to have a “standalone” mode, where

Hall

Post by Alex Sassmannshausen

would rely neither on Autoconf/Automake nor on Guix to do basic

things

Post by Alex Sassmannshausen

like building code. It might help newcomers. You wouldn’t want to
reimplement everything though, so I don’t know if this is a viable
approach. Thoughts?

Interesting idea. When you say building code, do you mean literally
compiling a project within the project folder & perhaps generating a
wrapper script that might update GUILE_LOAD_{COMPILED_}PATH à la
pre-inst-env, or do you mean some form of installer?

I’m thinking of a “hall build” command that would build Scheme files

and

produce a wrapper script, and optionally “hall install” as well.
It’s interesting only if it can be done without reimplementing too much
of the Autoconf/Automake or Guix logic, I suppose.

Agreed. I do think having some easy way of "running" your project would

be

cool.
Thanks for your thoughts!

https://bitbucket.org/ArneBab/conf/src/default/

conf - Initialize modern autotools projects
Inspired by Mozilla Cargo ( http://doc.crates.io/guide.html ) but

without the NIH and currently more limited in scope.

See NEWS for user-visible changes. See ChangeLog or the history for

detailed changes.
Going that way allows re-using all the features of autotools by providing
simple templates for common setups — and a starting point for more complex

From this description, it sounds fairly close to what hall does too! Sounds
like there's some overlap here :)

Good ideas seldomly come alone, yet only those keep going which are
pushed forward by their creators — kudos for doing what I didn’t manage to!

Post by alex sassmannshausen
Then hall build can simply be a wrapper for ./bootstrap.sh && ./configure

Post by Ludovic Courtès
&& make

Right, that could indeed already be the implementation of hall build
actually. Thanks for that idea!

Feel free to adopt it!

For Guile there’s already a nice autotools setup by Erik Edrosa¹² which
you could start from. I’ve been planning to adopt it into conf for half
a year now, but always got occupied by other stuff.

And once the autotools stuff is in place, packaging for Guix is just a
matter of designating a download location.

Best wishes,
Arne

¹: https://erikedrosa.com/2017/10/29/guile-projects-with-autotools.html
²: http://www.draketo.de/proj/with-guise-and-guile/guile-projects-with-autotools.html

[Amirouche Boubekki]

Post by Alex Sassmannshausen
Hello,
It is with great trepidation and joy that I finally release Hall to the
world.
You can get it with Guix after pulling the latest version with
$ guix package -i guile-hall
Otherwise you can get the code from
https://gitlab.com/a-sassmannshausen/guile-hall/, and build (hopefully)
using the traditional

This is nicely put. I will try to use to port the work I've done in chez
and compare both approaches or maybe bundle guile-web with it.

Do you recommend rebasing a project that has already autotools support
to use hall?

Thanks for sharing!

[Alex Sassmannshausen]

Hi Amirouche,

Post by Amirouche Boubekki

Post by Alex Sassmannshausen
Hello,
It is with great trepidation and joy that I finally release Hall to the
world.
You can get it with Guix after pulling the latest version with
$ guix package -i guile-hall
Otherwise you can get the code from
https://gitlab.com/a-sassmannshausen/guile-hall/, and build (hopefully)
using the traditional

This is nicely put. I will try to use to port the work I've done in chez
and compare both approaches or maybe bundle guile-web with it.
Do you recommend rebasing a project that has already autotools support
to use hall?

It depends…

On the one hand, if:
- you are comfortable with autotools
- your project includes non-guile modules that need to be installed
- your project has a complicated project hierarchy

Then it might not be worth using Hall. In the last case you might still
use Hall to generate Guix files, but to be honest, that doesn't gain you
much.

On the other hand, if:
- your autotools-fu is cargo-culty (like mine is)
- your project is Guile only
- you find the steps of maintaining the autotools infrastructure and
rolling releases a pain

Then you might well benefit from switching to Hall.

It is definitely possible to use hand-written configure.ac files &
Makefile.am files with Hall: it simply does not touch those files. On
the other hand, one of the nice things about Hall is that you can
regenerate a lot of the "infrastructure" files easily (autotools, basic
documentation, guix), and that feature obviously becomes more attractive
if you fully convert to the Hall way.

In any case, if you do want to give it a go, you probably want to use
$ hall init --convert [project-name] --author=$author

It will output the files to be generated, have a look whether that seems
sensible, then run with the --execute flag to create the files.

Then open the generated hall.scm file and try to map your project
folder-hierarchy to the files section.

Alternatively you could give
$ hall scan
a shot. It will try to generate a new hall.scm file on the basis of
your project hierarchy — bit it may fail to do so.

You can then run with --execute if you actually want to update your
hall.scm file.

I would suggest, play around. Though you'll probably find it way more
satisfying to use from the get go in a new project as you get the
expected user journey.

Post by Amirouche Boubekki
Thanks for sharing!

My pleasure :)

Alex