#variant - March 2019

regarding https://github.com/mumoshu/variant/issues/51

it is helpful to include single tasks, but if I want to include a bunch of tasks with a single statement, what are the options (I didn’t check all the tests & code)?

@mumoshu

found this one - https://github.com/mumoshu/variant/issues/52 🙂 seems like this is it

nope, that’s only for config files in fact

just import in the main file works OK:

...
import: variant_lib.yaml
...

good stuff! 🙂

awesome to see you figured out about that!
yes, import can be used for importing both single task or a set of tasks :)

also - if you encouter any difficulty on writing your variant command, pls feel free to share an example code!

thanks! I believe this tool is going to save a lot of time for a lot of people! 😃

I’m still going to figure out the differences between “inputs”, “options” & “parameters” 🙂

those are interchangeable, and parameters is the latest and recommended syntax!
the former two will be eventually removed

I see, thanks for the explanation!

is there any specific reason to separate config file & main Variantfile or config could be included in Variantfile file (as an option)?

@Alexander Tolstikov you’re not using the #! mode?

to me this is the ideal invocation

then the . configs are quite nice

@Erik Osterman (Cloud Posse) probably my question was not clear 🙂

I’ve meant that I like the idea to keep everything related to Variant in a single file (including environment specific config files, a main config file, etc) for some specific projects, where some other people will participate (it can be Variantfile or !# file, etc).

It will be probably easier for these people to adopt to the new workflow (with Variant) when everything is in the one place (file).

Also, it will reduce “invasion” (only one new file instead of 2-3 files) to other people’s projects (where I only setup the CICD for example).

Please let me know if I’m not clear! 🙂

Personally, the Variantfile approach was less appealing than writing a cli with variant

for example, we write our cli called kopsctl using the variant DSL

and then as a cli tool, I want the configuration separate. that logical separation IMO makes it more manageable than keeping it all in the same script.

yes, it makes total sense in this context

but, I still can see some cases where Variantfile would be more appealing to some people

as for me only, I prefer the CLI approach as well

ok, 😃

but still like to have some options 🙂

thanks for sharing your vision!

@Tim Malone has joined the channel

Yeah both use-cases make sense to me! From the author's perspective, I'd say Variantfile is an alternative to putting Makefile in your project root. It isn't intended to be reused by any other projects

./yourcmd way, like kopsctl, should be used whenever it is being reused in any way, like (1) imported from another variant command via import: or (2) as a single executable binary

Btw, for the latter, you can go build your variant command like explained in https://github.com/mumoshu/variant#releasing-a-variant-made-command, or in a bit more sophisticated way https://github.com/mumoshu/variant/blob/master/examples/hello/hack/generate-maingo-struct#L1-L15.

This plus variant!

I have thought about how we could do this with geodesic

So you can just run it with out even Docker installed

Remember the problem you we’re trying to solve about installing all the deps of variant

In this model, you would have a dockerfile of deps, a variant entry point, and a compiled container exe

that sounds very interesting 🙂

fyi: if you don't want the dependency to the bash installed on your machine: https://github.com/progrium/go-basher

Dude! That’s awesome

I think that’s a step in the right direction

Hello guys,
I wonder is it possible to pass the parent task parameter as an argument to the child?

oh shh, sorry it worked when quoting opt1: '{{ get "test_param" }}'. @mumoshu great tool btw, thank you.

I've been playing with variant and in my case I feel like I'm missing toObject template helper. Does anyone now how to treat the output of a task as an object? Is it possible in variant?

@ldlework has joined the channel

set the channel topic: https://github.com/mumoshu/variant

@loren has joined the channel

chmod +x ./myfirstcommand ?

@Joe Presley has joined the channel

@oscarsullivan_old Try running any
of the defined tasks by specifying the name like ./myfirstcommand foo!

I guess - you'd expected to see the command's help when it was run without any args, right?
I think it's currently failing, by design, because you have no root with script defined. I can make variant just print the help instead, though.

@mumoshu I think printing help would make sense in this case

alright. will address it soon. thx!