Zelphir Kaltstahl writes:

> On 10.07.2018 11:50, Alex Sassmannshausen wrote:
>> Hi Zelphir,
>> Just as a heads up — this is perhaps a little tangential.  I created the
>> guile-config package
>> (https://gitlab.com/a-sassmannshausen/guile-config), which builds on
>> getopt-long to provide a (IMHO) richer and more sustainable approach to
>> managing commandline options for a program.
>> Just figured you might be interested to have a look, as you were curious
>> about the subject matter.
>> HTH,
>> Alex
> Hi Alex,
> I took a short look and Guile config seems to do much more than only
> parsing command line arguments. It seems to be a more general thing for
> configuring any kind of program and different kinds of configurations?

Yes, you're right. It tries to automate some aspects of command-line
parsing (adding --help,version,usage automatically, generate short
versions of options).

Then it adds another layer on that commandline parsing interface that is
to do with "persistent commandline arguments", i.e. arguments that can
be set in configuration files.

The library supports configuration files that should be automatically
created (eager) or that can be created explicitly down the line.  It
also supports a hierarchy of configuration files (e.g. first, check the
config file in ~/, then check one in the current directory).

It also implements a clean interface for managing "sub-commands", so you
can define a whole tree of related commands, with the option of
inheriting commandline arguments, and configuration file settings
through that tree of sub-commands (e.g. guix, guix system, guix system
rebuild, would be a command, with 2 subcommands.  The latter may want to
inherit common options from guix system).

Also it implements the notion of a "handler", which can be provided to
parse commandline strings into data types you actually want to use in
your program.  It separates input parsing from your actual program,
which I *really* like.

> I think examples in the readme file for a few things one can do with it
> would be cool. Could you provide some basic example for command line
> arguments with Guile Config? (I am often guilty of not writing any
> readme for my own projects ^^', but I pledge improvement!)

Hah! yeah, that's definitely a weakness of mine too.  The repo contains
a .texi manual, which is pretty comprehensive, but the manual isn't yet
published anywhere… maybe I should look into that.

The repo also contains an example directory, that might help you?

> The ASCII art diagram is nice for getting an overview and I am sure it
> all makes sense when one looks a bit closer and maybe looks into some of
> the code as well. I could not understand, why this tool would itself
> write configuration files after reading configuration files one provides
> for it,

The idea here is that the program writes configuration files if they do
not exist yet, so the user can tweak them, rather than having to write
them from scratch.  Also, just to avoid confusion, the meaning of
configuration here means passing in values to tweak a programs settings
when invoking it, not, like, compilation configuration or some such.

> nor what a codex really is, except that it is some kind of struct.

Yeah, this is really just an implementation detail.  I should probably
hide that.

> Maybe this all has to do with Guix? Do I need Guix for Guile Config or
> is it intended to be used together with that?

You shouldn't need Guix — you should just be able to clone the repo and
update your GUILE_LOAD_PATH, or do the usual autoreconf -vif &&
./configure && make dance if you prefer (I shudder writing that,
personally ;-) )

> I've only once tried to install the Guix OS thingy (Guix SD?). It did
> not boot from USB. I could not install it on my machine and I could
> not find a working tutorial on how to install it. Since then I've not
> tried again, so I have no experience with Guix or the OS at all.

Ah, that's a pity — if it was a while ago, things have dramatically
improved now.  I believe the manual has fairly good instructions for
doing the binary installation of Guix the package manager.

> I am still learning about the "Guile ways" of doing basic things
> (cooking recipe learning style, I guess :D). The two examples I've
> created with getopt-long and SRFI 37 are in my examples repository
> (https://gitlab.com/zelphir-kaltstahl-projects/guile-scheme-tutorials-and-examples/tree/dev/command-line-arguments).
> With the SRFI 37 example I am not sure if the global options hash table
> is a good idea, as I usually try to keep as little global state as
> possible.

Agreed.  You could pass around the resulting configuration object
instead of storing it in a global var if you prefer.  That tends to be
what I do.

> I am trying to figure out all the basic things, so that if some
> programming problem comes up, I could say "Oh, lets do that in Guile
> Scheme.", just as easily, as I could do it with for example
> Python. When I think of something I do in Python and then think: "But
> how would I do it in Guile Scheme?", I feel an urge to be able to.
> Knowing the basics will let me get to the meat of the problem, instead
> of on-the-fly having to improvise many things to get there. If anyone
> wants to, they can use it as tutorials or templates or whatever,
> although I am too lazy currently to make proper tutorials out of
> things.  I try to keep the examples easy to understand for my own good
> too though.

Yeah, I think this is super valuable! Please continue doing this :-)

> Thanks for the hint Alex, great to see the Guile ecosystem growing! I
> often see new release announcements on this mailing list and every piece
> of new tooling or libraries makes it a bit better. Previously having
> practiced some with Racket, I am used to suddenly discovering some
> library that unexpectedly already does what I want in an elegant way. I
> think it would be cool if Guile gets to the same level + more
> discoverable. Especially with stuff like fibers (which is still on my
> learning list) under its belt, it is very powerful. Guile Hall also
> seems to be going in the direction of creating something that can be
> used with package managers or a Guile packages specific manager (?).

Yeah, there seems to be momentum with Guile (and Guix) atm.  Would be
great to see it keep up :-D


> Regards,
> Zelphir

Reply via email to