Handle env files from stdin

[kajic]

This adds support for env files on stdin. It allows me to know exactly which variables I'm passing in, instead of passing in the entire environment.

Not sure what to do about env files given a filename, since env files don't have an extension, as such.

Perhaps it would be better to have an option like --context-type=yaml, --context-type=toml, --context-type=env, etc., instead of parsing the extension to determine the type of the given file. Then, wrapped_context::create_context could have a single branch, be it stdin or a file reader.

[chevdor]

Hello @kajic and thank you for the PR!

I understand the idea but I would need more arguments to convince me that the extra deps+code are worth it.
Could you describe a use case where you:

• must have a .env file, not loaded in to the env
• that cannot be a json | toml | yaml
  ?

I do acknoledge that loading the entire env may refrain some use cases although it is very convenient most of the time, in addition to loading the context from a file.

I see options that would require no change, such as:

• load an empty env env -i bash then load the env and let tera use the "full" env (it will then be restricted to your env file)
• simply use another format such as yaml | json | toml.

I agree that being able to force the format may be a good addition in the cases where the context comes without the proper extension but why would that happen in the first place ? And if a yaml comes named as foo.bar (very unlikely though), you could still make a copy with the right extension to allow a run.

Could you tell me more ?

[alerque]

Why can't you just use env --ignore-environment NAME=VALUE ... if you want to pass specific values via the env without passing everything from the env? You should be able to even construct that command from an env file if that's a source you already have such that the env you pas is from your file and not the host at all.

[kajic]

I think some of the workarounds suggested will probably work for my use case. There are many bash tricks I still don’t know and I think you suggested a few for me to try.

However, I also think supporting env files might remove the need for some the other —env options, and reduce code. One could just use printenv and pipe that in. Yeah I could convert an env file to one of the other formats, but one could do the same between yaml and toml, I’m sure :)
I was thinking supporting env files would be in the spirit of your relatively extensive special handling of environment variables, as well as support for various other formats, but it’s alright if that’s not the case.

I mostly suggest removing extension detection to shrink the code down a bit.

Regarding the dependency on dotenvy, it’s not strictly necessary but nice to make the parsing a little more robust. One could also just read the file, ignore comments, split on equals, stripping off comments from the end of each value. But then one doesn’t get env substitution (https://github.com/allan2/dotenvy/blob/master/.env-substitution).

Have a great day!