RFC: support for pluggable evaluators

[alecthomas]

The default is Jsonnet, but it could be a JS interpreter, Starlark, raw JSON, whatever.

[camh-]

On the topic of the change: This seems a reasonable change - I had considered that using a full javascript interpreter may make sense in some use cases and that some of the todo items on the roadmap (#16) might be pushing things too far with jsonnet (state, non-deterministic native functions). I've stuck with jsonnet because I have a soft spot for it (it made my early k8s life much easier allowing me to avoid yaml), but I do recognise its limitations. Turning jig into a more generic dynamic grpc dispatcher is possibly a more valuable tool so I think I'm good with this. I may need to rethink some of my plans in this context though to see if they still make sense.

Some high-level comments on this PR, noting them for current/future consideration:

• I think at some point the JsonnetEvaluator will move to its own package (foxygo.at/jig/serve/evaluators/jsonnet?) to remove the jsonnet dependency from the serve package for users that are not using jsonnet. Happy for that to wait until a second evaluator appears, if it appears in jig.
• Maybe WithEvaluator should not be an option. It makes no sense to have anything other than one evaluator (zero makes no sense. more that one would need an additional discriminator to determine which one to use in which cases), so that could just be a non-option argument to NewServer()
• The evaluator interface of json string in, json string out may turn out to be a bit limiting - we might want to turn these into structs at some point and provide utility functions for specific evaluators to simply marshal/unmarshal json.

Some specific comments on this PR:

• Could you git grep -i jsonnet serve and update the comment that talk about it and make them more generic wrt "evaluator".
• The WithVM option can probably go (if we can notify all current users of it ;-) ), and just have WithEvaluator - that will be necessary anyway if the JsonnetEvaluator moves to its own package.

Thanks for your contribution.

[alecthomas]

The evaluator interface of json string in, json string out may turn out to be a bit limiting - we might want to turn these into structs at some point and provide utility functions for specific evaluators to simply marshal/unmarshal json.

I did wonder about this - there's structure inside the blob already, but it's implicit, so it would be great if it had a concrete type.

• Could you git grep -i jsonnet serve and update the comment that talk about it and make them more generic wrt "evaluator".
• The WithVM option can probably go (if we can notify all current users of it ;-) ), and just have WithEvaluator - that will be necessary anyway if the JsonnetEvaluator moves to its own package.

Sounds good, will do 👍

[alecthomas]

One other thought I had was that at some point we might want to extend the "Evaluator" interface to also support creating "bones", as the bones are currently tied to Jsonnet. I think that's okay to do later though, unless you disagree.

[camh-]

Yeah, bones changes can wait. Current bones output is almost javascript so code could be reused for that.

[juliaogris]

Most of the ideas in this PR where merged in #28 - so I will close it for now.
We've debated a bit weather it would be better to pass structs rather than JSON strings around which lead to questions around Unarey/ClienSteram/ServerStream/Bidi evaluators, but in the end we settled for keeping things simple with JSON strings for now.