A standard for how command line tools should do configs

[dinkelspiel]

Gleam libraries currently have a lot of different ways to handle their configuration. I think gleam as a language should come to a consensus on how libraries should handle configs and keep it that way so any time any one wants to asks for how to configs we can point to it and say, this is how you do it.

My proposal which i know is controversial with Lpil is to handle configs in the gleam.toml it is a file that every gleam projects includes and already contains configuration for the language therefor I believe it is perfect.

[config.my_library]
color = "#FFF"

I believe reserving the config.[package] "namespace" for libraries will create a neat and tidy configuration structure for gleam going forward. I am open to change however I just want Gleam to get ahead of this before we a get a javascript like solution where everyone uses different languages and naming schemes.

[lpil]

Libraries should accept configuration by passing arguments into functions. Global state is an anti-pattern that makes libraries overly rigid and hard to work with.

[dinkelspiel]

If I use my latest library lucide_lustre as an example. You add an icon by doing gleam run -m lucide_lustre/add [icon_name]. For the sake of completeness you are able to change the output module for the icons from lucide_lustre.gleam to something else. Is your proposal that every time an icon is added the custom output module should be provided as an optional argument in the cli?

Currently you can both do an optional argument and a static config in gleam.toml if the user preffers it. Imagine if someone else enters my project and adds an icon without the custom option module, it would break the project structure and it would not be ideal. A static config fixes this by having the library be configured for the projects needs in all environments.

[lpil]

Ah, you mean command line tools and not libraries! Having some agreement sounds like a good idea. The first step would be to come up with a series of different options and weigh up their pros and cons.

[dinkelspiel]

I'd want to reignite this discussion with a few options that have come to mind

First we have my personal favorite which is prefixing with config

[config.my_cli]

this is concice and shows that it configs a cli tool.

Otherwise we have two that are prefixing with library or cli instead of config. Both of these however don't feel, to me, that they address the issue of config.

[cli.my_cli]
[library.my_cli]

Therefor i'd wager for a standardization of a config prefix to become the standard prefix for gleam cli's that require config in gleam.toml.

[lpil]

Config doesn't make sense to me as the entire file is also config. It would need to be something else if we are to have this feature.

[silby]

In pyproject.toml the namespace for this is tool.*