Open AlejandroSuero opened 3 weeks ago
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?
@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.
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 aYAML
file for a variable like$SCRIPTISTO_CONFIG
, and if not found or defined, use the current way of defining the per-scriptbuild_cmd
.Proposal
When parsing it take the
script.{c,go}
, substitute it with thescript_src
(current file from the she-bang call) and add it tobuild_cmd
like-o ./script
If the current way of doing things is present on the current
script.{c,go}
use that instead ofconfig.yml
so it has a way to change per-script for some corner cases.