#variant (2019-06)

FYI:

https://github.com/mumoshu/variant/pull/91 -> @Erik Osterman (Cloud Posse) https://github.com/mumoshu/variant/pull/90

Thanks @tolstikov!

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 go :slightly_smiling_face:

https://github.com/variantdev/mod/blob/master/examples/basic/variant.mod

The source in this example isn’t meaningful but guess what we can achieve with it…

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 .circleci/config.yml, drone.yml, 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