Extraction with --extract
brandonkal opened this issue · 8 comments
Additional possibilities:
- Go templates
- Lua
- Rego
- YAML
Regarding YAML, that one is tricky because it could represent any data.
I don't know why, but the large majority of Kubernetes blog posts are a bunch of "now paste this block of YAML into kubectl apply"
Because mask already handles parsing the markdown, it would be useful to have mask extract those strings. For example something like the following would be useful:
mask --extract deployment document.md | kapp apply -a demo -f- -y
The same could be useful for docker-compose.yml examples, CI config, and even viewing the contents of a runnable target.
Perhaps a general extraction tool would be better suited as another project (especially for documents that don't follow the structure of a maskfile). Still, having the ability to view the code of a target before running a task would be a useful feature from the terminal.
You could also even support Go code blocks with https://github.com/containous/yaegi
Hmmm... I'm actually confused about what is being requested here. I think there's two parts....
Extraction
Embedding config like yaml or other templating languages into maskfile codeblocks doesn't really make sense, in my opinion, for mask. Embedding config inside a maskfile seems much more troublesome then just keeping them as config files stored in your project (e.g. docker-compose.yml).
Mask being a task runner isn't really the right tool for this job, if the job is colocation of configuration.
and other languages
- Go templates
- Lua
- Rego
You could also even support Go code blocks
Not sure what "Go templates" means exactly... their templating language? And Rego, not sure what this is either.
As for Lua and Golang codeblocks... i'm not sure. Mask's goal as a task runner is to focus on calling scripts as fast as possible, and dynamic/interpreted/JIT scripting runtimes align much better.
Golang issue #15540 suggests that go run can't compile a string from standard input and never will. Regarding Lua, i'm not sure if it can either.
All currently supported runtimes allow for running a raw source string and don't require creating a temporary file or directory to do a build in first. I think keeping it this way makes sense.
Yes. Regarding extraction, I wasn't intending to move all my config files into markdown blocks. I was thinking primarily about extracting from the markdown contents of others. But as I hinted, this probably makes more sense a distinct tool. Though I do believe just being able to print the contents of already supported code blocks would be useful.
By Go templates, yes I mean their templating language with taking flags as parameters.
Regarding Go, JIT compilation is very fast with the yaegi interpreter so it would be an interesting trick though I agree dedicated dynamic runtimes generally make more sense for such one-off scripts.
I'm thinking about just making extract be a global flag as it would be quite useful to quickly preview what actions will be taken before running a command.
The syntax would be:
mask --extract subcommand subcommand
It would then pipe to bat --plain --language ${executor_language} and fall back on cat if bat is unavailable.
I don't mind you adding the --extract option to print out the script block contents to stdout, but not piping to cat/bat.
Issue is that I don't want to start calling/piping to other utils. Instead, I would recommend people to make a bash alias that does something like
cask='mask --extract $1 | bat --plain --language $2'
and call it like cask cmd subcmd js. Obviously not as ergonomic for you... but piping to other utils from within mask feels weird to me.
What should the flag be called? --extract or --print? I'm fine with either.. but i figure there's a more common name for this maybe.
--print does sound a bit nicer but to me the flag sounds like it would print the whole markdown block. Maybe --preview? I'm fine with any. I'll have to think about this.
The trouble with the bash alias is that
- You lose command completion
- You likely don't know the language beforehand
I suppose you could add another global flag to solve (2) but that feels inefficient.
vask='mask --extract $1 | bat --plain --language $(mask --executor-language $1)'
On thinking about it, --print sounds best and is slightly shorter. It will be tricky to implement as all args will have to be made optional if the flag is specified.
Closing this since it seems your inkjet project has that already.