Skip to content

Change default configuration values to not load envFile #25184

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

soceanainn
Copy link

Proposed Change

Default to not loading any .env file instead of checking for and loading one at the workspace root if present. This is a potential breaking change for any developers implicitly relying on the current default value of "${workspaceFolder}/.env".

Why

vscode-python implements it's own version of dotenv support based on https://github.com/motdotla/dotenv (implementation references this in comments in multiple places).

This implementation is incompatible with the python-dotenv library, namely that python-dotenv supports multiline quoted values, but vscode-python does not. Inline comments are also not supported by vscode-python (see #23799).

We repeatedly run into this issue at my company, where VsCode is loading incomplete strings into env vars, making it impossible for python-dotenv to load them correctly afterwards (since python-dotenv won't overwrite already set variables to support easier overwriting for tests, etc).

In general I think that it is very unexpected that the vscode-python extension will load .env files using a different and incompatible implementation to the Python dotenv libraries. I think this is evidenced by various issues, such as #23575.

Long term, even if there is a goal to support automatic .env file loading within VsCode itself, IMO it makes more sense for this to be supported in VsCode itself or via a dedicated extension. Having a custom implementation embedded in the Python extension is almost certainly wrong, and disabling this by default is almost certainly a good start to eventually being able to sunset this logic in this extension.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant