Environment variables need to be managed

[ericobi]

Background & motivation

When we have multiple containers in an enclave, each container needs a lot of variables.

Some of them are constant, and some of them are not constant.

If we are using args for that purpose, main starlark file looks so messy.

Desired behaviour

I want kurtosis natively support a predefined environment variable management file;

Nodejs is using .env file.

The best one is to copy that .env file from the project and paste that into kurtosis project and then I am using the same name in starlark script.

Will be much easier.

How important is this to you?

Nice to have; this feature would make using Kurtosis more enjoyable.

[mieubrisse]

Hey @ericobi , thanks for filing this and so sorry for the delayed response here - we're still figuring out our Github notifications! Could you give me an example .env file of what you're thinking? I'm particularly curious about:

• Do you expect to define all the .env variables for the environment in a single place?
• How would you expect to modify environment variables?

Thanks again for filing this!

[ericobi]

We are using args.json file for custom env variables..

{
  "name": "mongodb",
  "image": "mongo:latest",
  "root_user": "root",
  "root_rpassword": "password",
  "user": "novu",
  "password": "novu",
  "dbname": "novu-db",
  "env_vars": {}
}

It is not a smart idea to cat args every time but instead we could use .env file like in node.js based projects. The other benefit is that those are already familiar with devs, like .env, .env.prod, .env.staging and can easily manage different stages.

[ericobi]

maybe we can use kurtosis.yml to define env variables???

[mieubrisse]

Hey @ericobi ! I want to make sure we're digging to the root of the problem, since the problem we've seen with environment variables in the past are:

1. there's no nesting (so if you wanted to model an object structure with an array like in YAML, you'd have to do something like PARENT_PROPERTY_0_CHILD_PROPERTY)
2. there's no scoping - it's just a gigantic bag of variables that gets passed to everything. For example, this is Novu's .env file for Docker Compose: https://github.com/novuhq/novu/blob/next/docker/.env.example Novu had to add comments to explain which variables are relevant to what (whereas, via parameters, the usefulness can be traced simply by following the code)

So for example, if we had a large Prod definition, we'd end up with a very large .env file and it wouldn't be clear which envvars are getting used where. Which isn't to say that we should be ignoring the simplicity of how envvars are defined!

Reading back through your original definition, I'm wondering if the envvars themselves can't be moved to parameters. That way, it's not env_vars as a key, but more granular things like password, dbname, etc.

It would be really helpful if you can give me an example of your usecase today where you're hitting this envvar problem!