added variable should be available in the current process

[Quentin Gaultier]

envman add --key foo --value "bar"
echo $foo

I get a void result;
I was expecting: "bar"

[Viktor Benei]

envman stores the env vars, it does not export them automatically after an add

try:

envman add --key foo --value "bar"
envman run bash -c 'echo $foo'

if you'd have any questions just let us know! ;)

[Quentin Gaultier]

yep, but I was wondering why not exporting it after storing it ?
from the doc :

This is the same as you would manually set all the environments, one by one with export KEY=value (in bash) before calling the command.

[Viktor Benei]

yeah, it might be a bit too bloated, but it's connected to the previous paragraph in the readme, namely:

... and when you call envman run the next time the environments in the .envstore file will be loaded for the command ...
This is the same as you would manually set all the environments, one by one with export KEY=value (in bash) before calling the command.

So something like

# set env
export KEY=value
# run command
command

roughly the same as

# set env
envman add --key KEY --value "value"
# run command
envman run command

Feel free to send a PR for the readme if you have an idea to make this more straightforward! :)

[Viktor Benei]

for:

but I was wondering why not exporting it after storing it ?

answer is the next paragraph:

envman makes it easy to switch between environment sets and to isolate these environment sets from each other - you don't have to unset environments, the specified environment set will only be available for that single run of envman / the command and won't affect subsequent calls of the command or envman.

basically you can have a dir structure like:

.
├── env1
│   └── .envstore.yml
└── env2
    └── .envstore.yml

and if you cd into env1 and envman add an env there, and run an envman run there then only the envs added in that dir will be available for the envman run command. If you switch to env2 dir and envman run there that will have a completely separate, "isolated" set of env vars.

P.S.: it's also possible to just have separate envstore files in the same directory, and switching between the env sets by defining which one to load:

# init two separate env sets
envman --path=./env1.yml init
envman --path=./env2.yml init

# add env to env1
envman --path=./env1.yml add --key KEY1 --value val1
# add env to env2
envman --path=./env2.yml add --key KEY2 --value val2

# run command with env1 env set
envman --path=./env1.yml run COMMAND

[Quentin Gaultier]

understood ! this is very clear !
A possible enhancement would be to add a option to let then added env be available in the current process. It would change the cumbersome:

    BUILD_VERSION=${BUILD_VERSION:-$(resolveNextVersion "branch=$BUILD_BRANCH")}
    envman add --key BUILD_VERSION --value $BUILD_VERSION

into

    envman add --key BUILD_VERSION --value ${BUILD_VERSION:-$(resolveNextVersion "branch=$BUILD_BRANCH")}

[Viktor Benei]

unfortunately that's harder than you'd expect, simply because of how env vars work in shells

there's no simple way of exposing env vars in a cross shell compatible way, and env vars exposed by a (sub)process are NOT available in the parent process - the shell itself is a process too! It's pretty much the same as if you'd start a new bash session from another, set an env var then exit - the env var will no longer be available:

# open clean terminal/command line - most likely it'll be a bash shell session
# now start a new session as child (bash login session):
bash -l
# set env var with export
export KEY=value
# test it - it works here
echo $KEY

# now exit the inner bash shell
exit
# you're back to the outer/parent one; try to print the same env
echo $KEY
# no longer available

[Quentin Gaultier]

Thanks for taking the time to give these nice explanations !

[Viktor Benei]

Any time ;)