Support environment variables (kedro run --env)

[noklam]

In kedro, we have the concept of "Environment" which is determined at runtime (default with base). The current extension always assume base and does not have a way to take this runtime information.

Todo:

• [x] https://github.com/kedro-org/vscode-kedro/pull/31
• [x] #30
• [x] #29

[noklam]

@astrojuanlu make a point here we should change it to base_env according to settings.py if possible. https://github.com/kedro-org/vscode-kedro/pull/21#discussion_r1636928715

[noklam]

https://github.com/microsoft/vscode-python/wiki/Python-Environment-APIs

Other than settings, I am looking at if it's possible to make use of .env, which is support natively by VSCode's Python extension. This is by default on. The Python extension has these environment variables already, so the task is figure out whether it is possible to access these information from their API and pass to the LSP.

[noklam]

On a second thought, I decide not to make dotenv loaded by the extension. This has side-effect to an actual Kedro project. i.e. if .env set KEDRO_ENV=prod, a kedro run will run the prod environment instead of base.

[noklam]

29 solves this partially, there is a 2nd part of adding a command to support this.

[noklam]

Move this from description to comment as many things has changed.

A few approaches in mind:

1. Using VSCode's settings

Pro:

• Feasible, we already have a few configurations that consumes by the Language Server

Con:

• Bad UX, how often someone go to change VSCode settings.json? (not more than once for the same plugin usually)

2. Some kind of menu clicking experience, i.e. right click on the folder and "select as environment" (not sure how feasible yet)

Inspiration from PyCharm, user can run a package without installing it (Pycharm add it to sys.path secretly through an UI click), which sometimes backfire as many people don't understand the concept when they move out from PyCharm.

Pro:

• Intuitive, easy to change when have multiple project

Con:

• Feasibility less clear, need further exploration.

(it's feasiblity to add new button, the screenshot show another plugin added new things to the menu)

Con:

• If you work with multi-project, you need to change frequently. We currently don't support easy switch for multi-project anyway, it assume you open a VSCode workspace at the root level of a Kedro project.

3. KEDRO_ENVIRONMENT, make use of this existing env variable.

Pro:

• Clever solution, reuse something exist already

Con:

• May interact with the actual project, as KEDRO_ENVIRONMENT do changes runtime behavior.