Introduce Status bar

[noklam]

Status bar:

• Add Icon & Status Bar
• Reuse the existing command logic

See the gif below:

1. By default it will show base (it respects the settings.json as well, not shown in GIF)
2. When click, user can select the environment

Testing

Use the built version to test which requires the develop setup or the uploaded version

1. Download it and right click in VSCode (Install Extension VSIX)

[noklam]

Having issue to extract the default settings (base), the icon: {env} only show up after 1. Execute the command 2. Clicking the status bar and choose env

[noklam]

I think after this I want to release 0.1.0 and use 0.1.0 for the recording. @astrojuanlu

[astrojuanlu]

How can we test this locally @noklam ? 😃

Most importantly, what's the effect of changing the environment this way? Will my subsequent kedro run commands have an implicit --env <env>?

[astrojuanlu]

Will try to follow https://github.com/kedro-org/vscode-kedro/pull/31#issuecomment-2190925564

[noklam]

@astrojuanlu I uploaded a build version (see the description), which you can right-click to install and test it.

It won't affect subsequent Kedro run, as these are done in the extension side in a separate process. This is 1 of the 3 ways to change configuration resolution (i.e. Go to definition, hover etc).

[astrojuanlu]

Gave it a quick run, some ideas:

• Is there a notion of developer versions for VS Code extensions? 5 minutes from now I won't remember if I have the true 0.0.3 or the wip 0.0.3 😬 something like 0.0.3+3b9579f25 (or whatever scheme is supported) would be nice
• I get then that switching the environment only affects the navigation powered by LSP, correct?
• It's unclear what environment is this changing. Right now in Kedro there's a combination of base_env + default_run_env, therefore if I don't change anything, things are routed to local, and if not found, to base. Here, however, looks like the extension can only lookup 1 environment, and that's what this selector tweaks. Am I right?

[noklam]

• Is there a notion of developer versions for VS Code extensions? 5 minutes from now I won't remember if I have the true 0.0.3 or the wip 0.0.3 😬 something like 0.0.3+3b9579f25 (or whatever scheme is supported) would be nice

Let me check, we don't have an automated flow for build/publish yet otherwise it will be handy to have something like a nightly build.

• I get then that switching the environment only affects the navigation powered by LSP, correct?

Yes, navigation, hover, auto-completion that requires loading Kedro class will be affected.

• It's unclear what environment is this changing. Right now in Kedro there's a combination of base_env + default_run_env, therefore if I don't change anything, things are routed to local, and if not found, to base. Here, however, looks like the extension can only lookup 1 environment, and that's what this selector tweaks. Am I right?

True. There are some feature inconsistency, so we need to know which feature we are talking about. For example:

• Auto-completion/Hovers actually create a Kedro object, so it respect the same mechanism (understand base + local)
• Find reference (config -> pipeline). This is environment-agnostic
• Go to definition. This is implemented independently in vscode-kedro

For this discussion, we focus on Go to definition.

1. The 0.0.1 version always assume things coming from conf/base
2. 0.1.0. We added a lot more, it respect settings.py, and now provide multiple options to change the "env". However, it still only have a single environment.
3. (Not implemented) - Ultimately it should be able to resolve config at file level. That is for params:abc, we can point to exactly which file it's coming from i.e. nok/project/conf/local:11-22.

To your question, default_run_env is ignored currently. We could have an intermediate workaround (through it is unlikely part of the solution of 3.)

[noklam]

To your question, default_run_env is ignored currently. We could have an intermediate workaround (through it is unlikely part of the solution of 3.)

In fact this should be an easy fix, for now we can make LSP always start searching from default_run_env (default: local), if there is nothing found then proceed to base_env (default: base)`. I will take a stab tomorrow.

[noklam]

^ In fact the notion of kedro run --env is always changing the "base_env". You cannot change the default_run_env with runtime parameters, the only way to do this is to update settings.py, which is uncommon (most Kedro have the default as local).

[astrojuanlu]

Interesting, thanks a lot for the explanation. Could we change the env selection dialog then, so it says "base environment"? So it's more similar to what kedro run --env does.

[noklam]

• 38

[noklam]