Krishnan Anantheswaran

since `qbec` doesn't have an opinion on how to create runtime parameters and where environment specific configuration is stored, it cannot reasonably update these. The best it can do is...

Yes and I want to change that. The generated code is too much machinery to get started. I want `qbec init` to produce something like the config documented at https://qbec.io/userguide/usage/runtime-params/#using-qbec-io-env

Unfortunately computed variables are evaluated at startup and added to the bag of variables given to the jsonnet VM. It's not possible with the current design to have a variable...

that said, what you are proposing is a neat idea - let me think about a mechanism to implement it.

the way I was thinking this would work is that we would implement a first-class helm3 data source rather than shoe-horning it into the exec data source.

also pretty sure that you cannot import a binary file like a TGZ file using `importstr` - ultimately this is a json string and needs to be valid UTF8

if imports could be computed all this data source business that qbec has wouldn't exist at all :) These importers were written specifically because computed imports don't work.

The data source design gets around the inability to have a computed import by doing a level of indirection such that `import 'fixed-path'` has a name that refers to a...

thinking out loud, very rough ideas... Currently we have one `exec` data source that is defined as `exec://?configVar=` where the contents of `configVar` tells the system the command to run...

> `importstr 'data://....'` but yeah the approach is hacky but should work OK. well, actually since it is the `helm3` data source implementation that runs helm under the covers etc....