added variable should be available in the current process about envman HOT 8 CLOSED

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! ;)

from envman.

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.

from envman.

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! :)

from envman.

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

from envman.

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")}

from envman.

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

from envman.

Thanks for taking the time to give these nice explanations !

from envman.

Any time ;)

from envman.