Discuss variant (the “Universal CLI”) https://github.com/mumoshu/variant
Solves #81 Now you can use the Viper-based hide_extra_cmds configuration entity to control if extra commands entries should be hidden from help, like: VARIANT_HIDE_EXTRA_CMDS=true variant
Just reviewed and merged your PRs. Thanks @tolstikov!
I built an another tool called
variantmod envisioning to integrate it into
variant someday, like
vgo integrated to
source in this example isn’t meaningful but guess what we can achieve with it…
no strong reason, but considered
variantdev/mod and realized
variant was already taken and
mumoshu/variantmod seemed a bit verbose!
while i wasn’t happy with
mumoshu/mod because i was planning to integrate it to variant
You can add
variant.mod so that running
mod fetches templates from remote sources and renders config files from it. Imagine building reusable template of
travis.yml, “import”ing one of them with
variant.mod and render it with runtime arguments..
@Erik Osterman (Cloud Posse) Perhaps you’ll be interested
The only type of dependencies is currently
file. But I’m considering to add
module. That is, any
go-getter accessible directory containing
variant.mod can be distributed and reused across your projects.
This avoids copy-pasting various YAML files for e.g. CI across projects. But I think there are more use-cases.
@mumoshu That’s a good idea (and I tried to find something like this only yesterday ).
In fact, I was thinking about it (retrieving and processing external files to produce the configuration & code) for the last couple of years and even implemented some version of this idea with “gomplate” and some other tools to retrieve the templates.
In my opinion, you could follow the Unix philosophy principle “Do One Thing and Do It Well” meaning that you can retrieve the templates by “mod” and use other tools, like “gomplate” to generate the result files from the templates (instead of processing the templates by “mod”).
BTW, how are you going to store the “result” files? Do you want to leave this action for the end-user to perform it manually (git commit?) or provide some functionality for it in the tool as well?
@tolstikov Thanks! I believe I have similar sentiment.
What if variantmod just provide the unified api/config syntax for the job, and used gotemplate as a library under the hood? Would it still follow the unix philosophy?
Results are rendered to the local paths specified by keys of the
files entries. The user would commit the resulting files after manual testing.
For automation, you can later build a CI pipeline to re-render and test the updated files when
variant.mod file changes.
Does it sound good to you?
@mumoshu yes for both statements, it fits my “vision” of this tool
sorry all - I haven’t had a chance yet to get my head into this. @mumoshu codes at the speed of hard to keep up