Open kferrone opened 3 days ago
Hi @kferrone. Thank you for reporting this. We'll take a look and get back to you.
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.
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
).
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 haveAWS_CONFIG_FILE
but I do haveAWS_PROFILE
.In my workspace the
.envrc
does setAWS_CONFIG_FILE
andAWS_PROFILE
.Then I simply run this:
Output in the runme cell. The
AWS_PROFILE
is the value coming from the.bash_profile
and seems to be overwriting the workspace level value. TheAWS_CONFIG_FILE
is the value in the.envrc
because it does not exist in the.bash_profile
. The fact thatAWS_CONFIG_FILE
is actually loaded correctly shows that along the way runme is actually loading the correct environment, and then doing something extra.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 theAWS_CONFIG_FILE
.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.
One note I realized, when I do open a new terminal,
direnv
will run immediately and set all those env vars. It basically runssource .envrc
when youcd
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
and actually print the value in another cell.
But the value doesn't change.
Is there anything I can do here or is this just a bug that needs fixing?