Re: Recommended project structure

[Olivier Dion]

On Fri, 09 Jun 2023, wolf <wolf@wolfsden.cz> wrote:
> Greetings,
>
> I am starting a small, personal project and I want to write it in GNU Guile,
> since I really like it so far.  However, since one of the major goals is for
> this to be a learning experience and doing it "the right way", I wanted to ask
> about recommended/standard project structure for Guile projects.  I found
> this[0] tutorial, but it is from 2017, which is quite some time back (I feel
> old).

Actually, what I like about Guile, there is no "the right way" like in
Python.  Whatever is best for the developers is the right way, not some
weird standard made by people with their view of the world.

Anyhow, if you're looking for a common structure, it is actually
simple.  The root of your project acts like a load path.  So say you
have two modules.  (foo) and (foo fuz), then you will have foo.scm for
(foo) and foo/fuz.scm for (foo fuz).

If you don't like having source files in the root directory
(i.e. foo.scm), then simply consider a sub-directory of your project as
the load path for Guile.  For example you could have everything under
src/.  Therefore, src/foo.scm for (foo) and src/foo/fuz.scm for (foo
fuz).  However, this kind of break the magic for me.

Following this, you can then easily configure Geiser in Emacs to add
the root of your project (or sub-directory) to Guile load path.
Everything is natural that way.

What is nice about this structure is that you can have helper modules
that are not meant for user.  I have for example a scripts/, tests/ and
tools/ directories in my projects.  That way I can start a REPL and
use-module my tools/ (debugging, plotting, etc.) or execute a scripts/
(running tests, benchmarks, etc.).  Everything can be done in the REPL!

Note that this structure require a little more work when you're doing
out of tree build, e.g. with autotools.  But for a small Guile project,
that should not be a problem.

> So I wanted to ask, does the tutorial describe best practices even in 2023?  
> If
> not, what would be a good reading on this topic?

I do not see any link in your message so I can not say.

-- 
Olivier Dion
oldiob.dev