Environmonet Variables Different than vscode terminal

[kferrone]

I'm having a strange issue with environment variables being different in the runme dev cells versus the vscode terminal. I am using a tool called direnv which loads a .envrc file in the workspace. Vscode handles the env very well. Runme on the other hand is clearly loading the environment differently somehow and creating different results.

Here is how I can tell.
In my .bash_profile I don't have AWS_CONFIG_FILE but I do have AWS_PROFILE.

export AWS_PROFILE="global-profile"

In my workspace the .envrc does set AWS_CONFIG_FILE and AWS_PROFILE.

export AWS_CONFIG_FILE="/the/workspace/aws/config"
export AWS_PROFILE="workspace-profile"

Then I simply run this:

echo $AWS_CONFIG_FILE
echo $AWS_PROFILE

Output in the runme cell. TheAWS_PROFILE is the value coming from the .bash_profile and seems to be overwriting the workspace level value. The AWS_CONFIG_FILE is the value in the .envrc because it does not exist in the .bash_profile. The fact that AWS_CONFIG_FILE is actually loaded correctly shows that along the way runme is actually loading the correct environment, and then doing something extra.

/the/workspace/aws/config
global-profile

Here is the correct output if I just copy paste from the readme into the terminal. Notice the AWS_PROFILE is now the correct value originating in the workspace directories .envrc and actually exists in the AWS_CONFIG_FILE.

/the/workspace/aws/config
workspace-profile

I used the runme feature to open the same command in a terminal and have confirmed the same as above in a terminal spawned by runme. The terminal did show off the following extensions to the terminal but all the terminals showed the same including working ones.

# Terminal Environment Changes

## Extension: stateful.runme

- `PATH=/Users/me/.vscode/extensions/stateful.runme-3.10.0-darwin-arm64/bin:${env:PATH}`

One note I realized, when I do open a new terminal, direnv will run immediately and set all those env vars. It basically runs source .envrc when you cd into a directory with a .envrc. Either way though, runme is actually reading all the variables set within .envrc and loaded by direnv, it's just overwriting them with anything set within my .bash_profile, this is backwards.

Last note on this issue, I figured I would be able to do this in one cell

export AWS_PROFILE=foobar

and actually print the value in another cell.

echo $AWS_PROFILE

But the value doesn't change.

Is there anything I can do here or is this just a bug that needs fixing?

[sourishkrout]

Hi @kferrone. Thank you for reporting this. We'll take a look and get back to you.

[sourishkrout]

Skip ahead of the direnv stuff. The short answer is that Runme ignores subsequent values because the ENV store already has a value for AWS_PROFILE, which is why it will ignore subsequent values by default (cell's promptEnv=auto).

The reason is that docs often come with invalid placeholder values, e.g., AWS_PROFILE=[your-profile], and Runme will, by default, put a higher value on .env or profile-loaded ENV values if present.

While this is unintuitive for "Shell-Scripters," it's not a bug; it's a feature. The short-term workaround would be to set the respective cells' prompt mode to Always as per the screenshot below. However, this will ask you to enter the respective value.

Now, not everyone is using Runme in this "docs-first" scenario. We are working on an additional mode, let's say shell, that, when set, will overwrite values in subsequent order and provide a setting to set the default behavior according to users' needs. We expect this new mode to be available in the next few weeks. I will respond to the direnv aspects separately.

[sourishkrout]

In the interim, another workaround I thought of is to wrap the value into a shell expression that Runme will always "run" at face value. This should do the trick until we solve this at the core.

export MY_NAME="$(echo -n 'Sebastian')"

https://gist.github.com/sourishkrout/1420466907cf9e595a167617cc92e5f1#file-source-01jdqjrsbn90mcyng50vnh4sey-md (I have a .env with MY_NAME=Luna).

[sourishkrout]

One note I realized, when I do open a new terminal, direnv will run immediately and set all those env vars. It basically runs source .envrc when you cd into a directory with a .envrc. Either way though, runme is actually reading all the variables set within .envrc and loaded by direnv, it's just overwriting them with anything set within my .bash_profile, this is backwards.

Regarding direnv, @kferrone: Based on how Runme's implementation to seed the environment currently works, your observations make sense to me. Supporting direnv is high up on the Runme roadmap, whether that means "fixing the order" or integrating it more natively is TBD.

Is the absence of Runme <> direnv blocking you from using Runme? I'd love to help you get unblocked in the interim.