Config file: Which format?

[casey]

I'm considering adding a user config file to just. Rust and serde make it so simple to do that it seems like a no brainer.

I'm not entirely sure which format to use. I think reasonable possibilities are TOML, YAML, JSON, and just. I personally find JSON too verbose and fiddly, so I'm going to veto that.

TOML is common in the rust ecosystem and very straightforward, but is slightly verbose. YAML, on the other hand, is a bit less verbose and handles nested keys better, but can be trickier to write. Using a justfile as the config file would allow including recipes, and make configuration on a per-user and per-justfile basis uniform.

How do others feel about this? Add a ❤️for TOML, 🚀 for YAML, and 😄 for just; and add a comment if you have a perspective you'd like to share.

The first config option I'm thinking of supporting is something that turns off line-echoing by default. I've been analyzing all the public justfiles on github, and making recipes quiet, i.e. prefixing them with a @, gets a lot of use. I like echoing lines by default, but it looks like a lot of other people prefer most recipes to be quiet. So, adding a .justrc and making the default configurable seems like a good idea.

(This was first suggested way back in #246 by @Fleshgrinder, but it didn't strike me to add a config option, so users could decide individually.)

Edit: Added just as potential format.

[casey]

Another option is justception: Just's config file IS A JUSTFILE.

By adding a set SETTING = VALUE construct, everything could be configured on a per-user or per-justfile basis. Also, the justrc could contain recipes that would be available to the user in every project.

[runeimp]

I'm a big fan of YAML. I like the idea of using a Justfile as config as well but set SETTING = VALUE is very limited. Even an INI file has sections. I would personally like to see the config in YAML and be able to specify a default Justfile in it for for global recipes.

[runeimp]

Also please consider https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html so I don't have to put yet another hidden config file in my home directory. 👼

[casey]

XDG base directory support is definitely a must have!

[runeimp]

BTW, YAML is a superset of JSON. So if you support reading YAML you get reading JSON for free. Not that I'd ever use JSON personally but for those who like to generate their config files JSON is supported by almost every language in common usage.

[asdf8dfafjk]

https://dystroy.org/blog/hjson-in-broot/ (discussion: https://lobste.rs/s/dn91bz/why_broot_is_switching_from_toml_hjson_for) or https://github.com/vstakhov/libucl

[ngirard]

@passcod adopted KDL as a configuration language for watchexec's incoming developments.

[rutrum]

Personally, I've wanted to use TOML to set variables that are used in my justfiles. This is because my programs often use a toml file for configuration and read from it to run programs. The only way I know to load external variables in just right now is environment variables stored in .env.

In a very hacky manner, I've created my own python script that converts .toml into .env. This comes with severe loss in expressions, opting to use double underscores __ to separate keys of a parent table to a child table. But in my justfile I have recipes like

gen-env:
   python3 toml-to-env.py config.toml > .env
watch:
  watchexec -e toml,py -- just test
test: gen-env
  python3 test.py

This way I'm always rewriting .env when I make any changes to source code or configuration files.

All that's to say, I think the ability to import other configuration files would be helpful, for either variables or configuration options.

And at the end of the day, no matter what solution you pick, there's always a tool that can convert between toml/json/yaml anyway (like yj for example) and users can just do that if they don't like the input format for justfile configs. I'm partial to TOML, obviously.

[asdf8dfafjk]

toml is probably the worst of all solutions, given how fragile arrays are in it. See #395 (comment) for more.

@rutrum

[chevdor]

I understand why people find some cons to Yaml due to the mandatory indentation, however, this IMO the format that makes more sense to users:

• being a superset of json, everythiong required will be possible
• arrays look rather straight forward
• there is good editor support
• no extra " all over the place
• comments are possible
• gives the best "visual" of the config without flattening the arrays like toml does