Provide and API that returns the activate environment variables merged with variables from .env files

[DonJayamanne]

Today the Jupyter extension is planning on using the custom API getActivatedEnvironmentVariables method.
However this has a problem: If we call this API for a global python environment with a .env file in the users folder, then undefined is returned by the Python extension API.

Asks

• Option 1: When calling getActivatedEnvironmentVariables with any python env and with a .env file in user workspace, then always return the environment variable
• Option 2: Have a more stable API than a custom API just for Jupyter
  • Currently there is a separate API getEnvironmentVariables that seems to not take an interpreter as an argument
• Other...

[karrtikr]

getActivatedEnvironmentVariables ideally is only meant to carry the variables required to activate the environment, in which case returning undefined makes sense for global interpreters. However traditionally we return the whole set of variables (not just activation-specific) because we don't see the need to separate the two, based on how getActivatedEnvironmentVariables is currently used.

Does that not work for Jupyter?

Option 2: Have a more stable API than a custom API just for Jupyter

That is what we will go with eventually, we're still in the process of deciding on how to expose environment activation.

[DonJayamanne]

getActivatedEnvironmentVariables ideally is only meant to carry the variables required to activate the environment, in which case returning undefined makes sense for global interpreters. However traditionally we return the whole set of variables (not just activation-specific) because we don't see the need to separate the two, based on how getActivatedEnvironmentVariables is currently used.

Not following you here

Does that not work for Jupyter?

I have described in the issue what is not working, not sure what you mean by this question

[karrtikr]

getActivatedEnvironmentVariables is actually not meant to carry the process environment variables (including .env file), it only guarantees to return the variables needed to activate the environment. So it'll return undefined in case of global interpreters.

Not clear on why Jupyter needs it to return custom env vars as well. We have a separate API for that and merge can be done on Jupyter's end.

[DonJayamanne]

Written above

getActivatedEnvironmentVariables is actually not meant to carry the process environment variables (including .env file), it only guarantees to return the variables needed to activate the environment. So it'll return undefined in case of global interpreters.

Written on #20621 (comment)

Activated environment variables (assuming you get this from the Python extension) already contains both the process env and custom vars as well, as acquiring it requires printing all env vars anyways. So explicit merge with .env file isn't even required.

Both are completely contradicting statements, literally the opposites
Or have I misunderstood your statement.

[karrtikr]

Discussed offline:

• For global interpreters, you're right it does not return any .env variables, consider that the design of the API for now, in that case please merge the custom envs on your end.
• For other environments, we return the merge of .env variables and activated vars. Ideally we should only be returning activated vars. But we noticed we've to later merge .env vars into it anyway so we do not separate it and return both.
• Once we've an official API, we can revisit what exactly should we have the API returned.

Closing this issue for now.

[DonJayamanne]

For global interpreters, you're right it does not return any .env variables, consider that the design of the API for now, in that case please merge the custom envs on your end.

please could you reopen this issue or create a new one
I would like an issue that tracks this original request, as that was required in the previous iteration

[DonJayamanne]

Please feel free to close this in favour of a new issue, Else please could we leave this open

[karrtikr]

Option 2: Have a more stable API than a custom API just for Jupyter

I have created #20678 to track request to provide a more stable API than a custom API just for Jupyter.

I see this as the design of the API rather than a bug. We'll make sure to document in the new API on what is to be expected of the return value.