Recommended project structure

Recommended project structure

[wolf]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

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).

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?

Thanks,

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Recommended project structure

[Olivier Dion via General Guile related discussions]

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

Re: Recommended project structure

[wolf]

[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]

On 2023-06-08 23:33:47 -0400, Olivier Dion wrote:
> 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.

Ah, thank you for the write up.  It is very useful to know how someone actually
does it in practice.  Especially the ease of using REPL in this setup.

In general like autotools, so I will probably try to incorporate them somehow.

> 
> > 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.

That is pretty embarrassing mistake on my part, the link is:
https://www.erikedrosa.com/2017/10/29/guile-projects-with-autotools.html .

> 
> -- 
> Olivier Dion
> oldiob.dev

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Recommended project structure

[Olivier Dion via General Guile related discussions]

On Fri, 09 Jun 2023, wolf <wolf@wolfsden.cz> wrote:
> On 2023-06-08 23:33:47 -0400, Olivier Dion wrote:
>> On Fri, 09 Jun 2023, wolf <wolf@wolfsden.cz> wrote:

> That is pretty embarrassing mistake on my part, the link is:
> https://www.erikedrosa.com/2017/10/29/guile-projects-with-autotools.html
> .

I had a quick look at it and I would say that this project structure
using autotools is good.

-- 
Olivier Dion
oldiob.dev

Re: Recommended project structure

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]


> > That is pretty embarrassing mistake on my part, the link is:
> > https://www.erikedrosa.com/2017/10/29/guile-projects-with-autotools.html

Very good tutorial and project structure ... which you may 'complete'
looking at some existing project(s) you 'like' ...

Fwiw, guile-hall is another option, excellent as well - though I think
it won't cover everything you need if you have to write part of the
project code in C (hopefully not, but sometimes it is just
'inevitable'):

	https://gitlab.com/a-sassmannshausen/guile-hall/

David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Recommended project structure

[wolf]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On 2023-06-09 16:33:56 -0300, David Pirotte wrote:
> 
> > > That is pretty embarrassing mistake on my part, the link is:
> > > https://www.erikedrosa.com/2017/10/29/guile-projects-with-autotools.html
> 
> Very good tutorial and project structure ... which you may 'complete'
> looking at some existing project(s) you 'like' ...
> 
> Fwiw, guile-hall is another option, excellent as well - though I think
> it won't cover everything you need if you have to write part of the
> project code in C (hopefully not, but sometimes it is just
> 'inevitable'):
> 
> 	https://gitlab.com/a-sassmannshausen/guile-hall/
> 
> David

I will reply just to this single message in order not to spam the list too much,
but I just want to thanks everyone for advises and suggestions. :)

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Recommended project structure

[Thompson, David]

Hi!

On Thu, Jun 8, 2023 at 6:44 PM 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).
>
> 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 recently made a project template repo. It's specialized for making
games with Chickadee but it's mostly boilerplate for making any
project with Guile. It takes care of a basic autotools setup, among
other things. Maybe you'll find it useful.

https://git.dthompson.us/chickadee-game-template.git/tree/?h=main

- Dave

Re: Recommended project structure

[Nala Ginrut]

Hi there!
If you just want to get a quick start, I'd recommend guile-hall. And you
may want to install Guix first.

Best regards.

On Fri, Jun 9, 2023, 06:44 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).
>
> 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?
>
> Thanks,
>
> W.
>
> --
> There are only two hard things in Computer Science:
> cache invalidation, naming things and off-by-one errors.
>