Can environment variables be reset within a session?

[jlewi]

My expectation is that I could set and export an environment variable multiple times. However, this doesn't appear to be the case.
It looks like I can only set an environment variable once per session.

Is this working as intended?

Here's a video
https://github.com/user-attachments/assets/32a39863-1b7f-48e5-9264-2269e7e62e7d

[sourishkrout]

Could you please share the raw markdown, @jlewi? I can only be 100% sure by checking the cell settings in your specific file.

What's likely going on is that promptEnv is set to auto (default), which won't set/ask for a new value every time: https://docs.runme.dev/#generic-docs-using-prompts. To get the desired behavior, you'd have to switch it to no, which will always use the new values in the cell. You can use the caret on the ▶️ button to pick "Execute and always prompt for input" to modify values if they have already been set.

PS: The new beard 🧔‍♂️ looks good 👌

[jlewi]

Here you go.
test.md
I have prompt for exported env set to no.

If I set to "Yes". Then when I execute the cell it prompts me and I can override the value.

To get the desired behavior, you'd have to switch it to no, which will always use the new values in the cell.

I don't think that's what's happening. It looks like even when its set to no; the value doesn't get reset when executing the cell. It looks like the value only gets set the first time the cell is executed in the session.

RunMe-EnvironmentVariables-.mp4

[sourishkrout]

Thanks for the clarification, @jlewi. The issue I'm seeing is that the promptEnv=no semantics works as Runme defines it. However, it's not how you'd expect it. We've defined them based on previous user requirements, specifically users who are running both CLI & extension use cases.

I do see a valid point for your use-case/scenario, though. You basically just want it to "work like shell". I'd suggest we introduce a fourth mode to the existing yes, no, and auto (default), called shell which will in essence just skip the entire managed env store prompting logic and just do what shell does. While we're at it, we could introduce it as a top-level frontmatter attribute so it's easy to overwrite the default across a document.

Should be able to turn this around fairly quickly since it's basically noop for Runme's "program resolver". Wdyt @jlewi? We'll also make the docs more specific.

PS: Working on the rollout of runnerv2 where v2 will take v2alpha1's place. They are the same but the alpha label is no longer warranted. v2alpha1 will disappear from the selection in coming patch releases.

[jlewi]

Thanks. So to summarize the intended semantics are

• promptEnv=Yes - Always prompt the user to override the environment variable every time the cell is executed
• promptEnv = No - Never prompt the user to override the environment variable ; but only set the environment variable the first time the cell is executed
• promptEnv = Auto - Prompt the user the first time the cell is executed and then always use that value.

Adding a 4th option "shell" to behave like the shell would be great for my purposes.

Out of curiousity, do you have an example of when you'd want the "no" semantics? What would be a situation where you would i) change the value in a cell and ii) reexecute the cell but want the original value of the variable to preserved.

Thinking out loud:

Did you consider other UXs to allow users to easily set parameters in their notebooks without saving them?
The "input" popup doesn't seem as nice to me as using a code cell

• Its much smaller
• You need to serially set environment variables.
• If you make a mistake, I'm not sure how go back and easily correct them.

Did you consider letting users edit code cells and then not persisting those changes? So in the example where you have a code cell with

export PROJECT=[your project]
export CLUSTER_ZONE=[zone]
``

I'd just edit that cell to set the PROJECT and CLUSTER_ZONE and then execute the cell. The changes however wouldn't be persisted on save.

There's a couple downsides I could see to this approach

* It could be akward to "freeze" and "unfreeze" a cell to make permanent changes
* What would be the use case for persisting some changes but not others? Why not just completely discard all you changes to the notebbok?

[sourishkrout]

Thanks. So to summarize the intended semantics are

• promptEnv=Yes - Always prompt the user to override the environment variable every time the cell is executed
• promptEnv = No - Never prompt the user to override the environment variable ; but only set the environment variable the first time the cell is executed
• promptEnv = Auto - Prompt the user the first time the cell is executed and then always use that value.

Correct. However, for No, it will even skip the prompt if a value was assigned via .env, or .env.local, etc resolution. One design goal of Runme is to play well as part of markdown docs tracked inside a repo, e.g., describing a "solution". This is beneficial for consumers of pre-built notebooks where you need config/credentials to make them work. In fact, we are working on a sophisticated resolution mechanism to expand beyond what .env.* does.

If I had to categorize Runme users, that's most of the user base. I see you in the programmatic Jupyter-style bracket (I wonder if that's fair; feel free to disagree).

Out of curiousity, do you have an example of when you'd want the "no" semantics? What would be a situation where you would i) change the value in a cell and ii) reexecute the cell but want the original value of the variable to preserved.

As mentioned above, it's when teams share notebooks in repositories colocated with code or IaC. The author isn't always the same as the consumer and maintenance might be shared.

Adding a 4th option "shell" to behave like the shell would be great for my purposes.

I slept on this and now realize that my suggestion to have a 4th "shell" option is flawed. I realized that No not asking again is primarily rooted in the idea that some ENV vars might be resolved from a config/secrets store (lots of docs just have dummy values with valid syntax). Resolution is orthogonal to prompting. I could see us introducing a separate frontmatter switch that disables resolution that allows for Yes, No, Auto where the latter will disable resolution if no resolution is available. E.g., if no .env* are present. First making the simple off switch for resolution available should be a quick turnaround.

Thinking out loud

I love your suggestions and the discussion here. Balancing generic sharable notebooks with the "will just work" properties is far from complete. I also see how different mechanisms aren't mutually exclusive. I need to noodle on this more. However, it shouldn't stop us from unblocking what you want to do.

[jlewi]

if a value was assigned via .env, or .env.local, etc resolution
That's a great feature.

If I had to categorize Runme users, that's most of the user base. I see you in the programmatic Jupyter-style bracket (I wonder if that's fair; feel free to disagree).

I have both use cases

1. Running checked in docs as recipes
2. Using RunMe as a replacement for the shell and to create notes about what I'm doing

Or put another way

1. Cells are authored once but executed many times by many people
2. Cells are authored and executed once

Right now my use tilts more to #2 because I'm working mostly on my own.

In the case of #1, I often find myself wanting to make ephemeral edits or insert "ephemeral cells" that are only for me.
As a concrete example, whenever I need to run the vscode-runme tests I open contributing.md and execute the cells. But I usually don't want to run the E2E tests so I edit the cells to delete test:e2e.

Or when dealing with this issue dependency issue I added a cell with the commands.

rm -rf node_modules
npm cache clean --force
npm install --include=dev

This is a bit of a digression and roundabout way of saying

• I agree with you on the need to split authorship across document creator and document executor
• I think this applies to more than just environment variables