Introduce feature flags to control experiments

[pivotaljohn]

No description provided.

[cppforlife]

should this be local to the command (aka not global)?

[pivotaljohn]

maybe?

[pivotaljohn]

Can you share more of what you're thinking?

[cppforlife]

typically i try to go with least scope as possible. as soon as you go global scope, there is never certainty of what previous/current code could be influencing things -- e.g. in tests you have to be careful how things get cleaned, in prod code if i configure one instance of ytt library execution would it somehow we affected by some other external code (that might decide to tweak some feature flags possibly for another parallel execution).

[pivotaljohn]

So, that absolutely makes sense for me for a "first class" feature flag.

This is meant to govern experiments. I'm thinking of it as a runtime-checked build flag: that it selects which flavor of executable should be used.

I was really wanting to avoid plumbing through this kind of thing through as it could potentially litter a bunch of unrelated abstractions.

Would this be a job for a Context?

[cppforlife]

I'm thinking of it as a runtime-checked build flag: that it selects which flavor of executable should be used.

with you about the plumbing 👍

may be then the middle ground is:

• only expose read only getter functions from that package so it's not an invitation for flip them during runtime
• have a single function that acts as a setter SetFromEnv() (so that may be ytt when imported as library never interacts with it).
• [nit] rename features to experiments to make terminology more consistent with env var

for example:

experiments.go

var (
  schemaValidationEnabled = false
)
func LoadFromEnv() {
  // do stuff with os.Getenv("YTTEXPERIMENTS")
  // ... schemaValidationEnabled = true
}
func IsSchemaValidationEnabled() bool { return schemaValidationEnabled }

code uses experiments.IsSchemaValidationEnabled()

[pivotaljohn]

[nit] rename features to experiments to make terminology more consistent with env var

Totally agree. AND to not risk confusion with actual feature flags (e.g. --data-values-validation.

...

(so that may be ytt when imported as library never interacts with it).

I was aiming to include those who are programmatically integrating — which motivated exporting Flagset.Enable().
I guess technically, they could also call experiements.EnableFromEnv() if they wanted to... which would just be a more complicated form of the same thing?

... ah, no, I see... since the environment variable would be essentially constant, it approximates what we're going for: a stable value.

Oh, I'm liking this. Because in tests, we can change that value, as desired. ... but in a typical execution environment, it's almost likely static.

Gonna try this out and see.