[Feature Request]: adding a config file to avoid boilerplate

[AlejandroSuero]

Feature request

Wouldn't it be better for the UX to parse a, for example, YAML file located in, for example, $XDG_CONFIG/scriptisto/config.yml or loading a YAML file for a variable like $SCRIPTISTO_CONFIG, and if not found or defined, use the current way of defining the per-script build_cmd.

Proposal

# path/to/config.yml
lang: "c"
  build_cmd: "clang -O2 {{ script_src }} `pkg-config --libs --cflags glib-2.0`"
lang: "go
  build_cmd: "go build {{ script_src }}"

[!NOTE]

I will use TOML since it differentiates more the blocks like:

[c]
build_cmd = "clang -O2 [$script_src] `pkg-config --libs --cflags glib-2.0`"

When parsing it take the script.{c,go}, substitute it with the script_src (current file from the she-bang call) and add it to build_cmd like -o ./script

[!NOTE]

I am not a Rust developer, so I don't know how complicated or not it is this environment, but starship does it to configure the prompt.

If the current way of doing things is present on the current script.{c,go} use that instead of config.yml so it has a way to change per-script for some corner cases.

[igor-petruk]

I was thinking about this a while ago, but scripts do have different dependencies. Yet I think it is useful for maintaing larger collections of similar scripts. But we need to think of usability and how it fits in the existing tool.

There is a partially similar feature, the scriptisto template command is used to maintain a collection of templates so you can generate new scripts easily. If you do scriptisto template import or ... edit it will result in a file created under ~/.config/scriptisto/templates. They will not be pure build spec config, they will be full scripts. But it is very similar, and therefore introducing a slightly different version of it may not be the best idea. It would be great to reuse it somehow.

For example we could supporte referencing these templates and extracting build spec from them. It is less clean as just configs, but more powerful, as we get two features at the price of one. We can support a shorter comment block like

// scriptisto-begin
// config_from: cpp-glib
// scriptisto-end

Or in the shebang:

#!/usr/bin/env scriptisto cpp-glib

It is probably possible to even detect the default programing language from the file extension, but that's maybe a further extension of this idea. Provided you can go with the options above, it may be unnecessary.

Yeah, extracting a config from a template and ignoring it's body is not super clean, but we do get a lot of power with a very simple implementation. Actually we will support even a third scenario: when you use the default, but for one script you would like to add extra options, then you can turn your template that you use for configs only to a fully materialized script

Thoughts?

[AlejandroSuero]

@igor-petruk I think thats a great idea, I like it. I think the shebang way its better for what I had in mind, but both reduce the boilerplate code, so what you think fits better in the project.