Vscode-extension-for-zowe: Research: How can Zowe Explorer handle context (projects/folders) in VS Code

[zdmullen]

Is your feature request related to a problem? Please describe.

As a developer, I want an understanding of how Zowe Explorer can figure out and work with the particular context a user has in VS Code i.e. a particular workspace, folder, or project open in the file explorer. This will be important in working with uploading configuration files as described in issue #1181 .

Describe the solution you'd like

Research and plan for how Zowe Explorer can identify these contexts.

Describe alternatives you've considered

Additional context

[katelynienaber]

In VSCode docs, _"A workspace is the representation of the folder that has been opened."_

We can get workspace state from an ExtensionContext object. We/I should experiment with what this gives us.

VSCode doesn't have an event for workspace selection...I can't set an event listener to fire whenever the workspace changes. So I guess we would need to check the workspace state on every action requiring validation...maybe someone has a better idea?

But VSCode _can_ let us know when a workspace has been opened/closed. See event onDidChangeWorkspaceFolders...So we could keep an array of all the workspaces currently open.

[VitGottwald]

To my knowledge we currently do not support multi-root workspaces. So I would start with what we have - a single root workspace - a workspace containing a single root folder.

As @katelynienaber said , we can read the location of the workspace root folder from a VSCode API and it plays a role similar to _current working directory_ in shell. I would expect the imperative SDK to give us some way to pass the current folder location either directly as an argument when we call it, or indirectly though an environment variable.

Imperative would then do a lookup for the proper zowe.config.json and respond back.

Let's call this the first requirement:

1. ZOWE Config File Lookup

[VitGottwald]

Currently ZOWE Explorer can create, update and read profiles. We need to find out what API we will be given to do these operations with the new team profile. ZOWE Explorer itself is primarily concerned with z/OSMF profiles and recently with base profiles. But it reexports the profile API to its extenders and they may be concerned with other type of profiles (FTP for example).

2. Create, Update, and Read Profiles API

[VitGottwald]

Currently ZOWE Explorer stores all of its configuration in _global_ VSCode settings, the same way CLI used to store all its profiles in a _global_ folder (.zowe/profile folder in user's home directory).

With the new team configuration file zowe.config.json/zowe.user.json profiles can now be defined per project. We need a similar approach for storing ZOWE Explorer Configuration (e.g. what profiles to use for displaying datasets in the tree view for the current project).

3. Where To Store ZOWE Explorer Project Level Configuration

• The first location that comes to mind to store project scoped configuration is the local VSCode settings.vscode/settings.json. However, this file is often times checked into source control because it contains various definitions that a team wants to share, like the names of VSCode plugins to install.
• Since ZOWE Config has a _user_ version that is intended to be gitignored (zowe.user.json), it presents an interesting alternative to VSCode settings. It would allow us to have a _single configuration strategy_ across the CLI and VSCode extensions.
• In case we could not use zowe.user.json then the last option seems to be to come up with our own configuration file to store project level data. In this case we would be duplicating some of the effort of the CLI squad has done. We might be also confusing our users why they should care about two different configuration files.

[VitGottwald]

There is also additional information that might be useful to be shared across the CLI and ZOWE Explorer, like the dataset templates that @katelynienaber has demonstrated recently. For this information the zowe.user.json would seem to be an ideal location.

4. How To Share Configuration Created in ZOWE Explorer with ZOWE CLI

[VitGottwald]

The CLI team will present us with a proposal for the API they intend for accessing the new config file at tomorrow's extended standup. This will give us the opportunity to have a discussion and share our requirements and feedback as well.

The proposed API is here.

[venkatzhub]

@VitGottwald - re: Multi-root workspaces, our intent is to support it, so the statement you made above - is that because we have not tested it? Re: design aspects, I believe we need to take into account the multi-root workspaces as well.

[jellypuno]

1. Where To Store ZOWE Explorer Project Level Configuration

We currently do not have plans to create a Zowe Explorer Project Level Configuration. Unless there's a request from extenders which I am not aware of. But for our current goal for this PI, this is not part of our priority.

[VitGottwald]

@venkatzhub it is not clear to me what it would mean _to support a multi-root workspace_ in the context of ZOWE Explorer. Let's create a separate issue to track that.

[VitGottwald]

Created an issue for tracking multi-root workspaces https://github.com/zowe/vscode-extension-for-zowe/issues/1226

[venkatzhub]

I think you wanted to reference https://github.com/zowe/vscode-extension-for-zowe/issues/1226?

[VitGottwald]

1. Where To Store ZOWE Explorer Project Level Configuration

We currently do not have plans to create a Zowe Explorer Project Level Configuration. Unless there's a request from extenders which I am not aware of. But for our current goal for this PI, this is not part of our priority.

I agree we do not plan to implement this now. But as part of the discussion, we should get a clear picture of what the strategy for handling this will be. If we keep everything in global vscode settings we will run into the typical

_global vs local_ issue:

1. User creates a folder and puts in zowe.config.json with profiles for project A (e.g. master the mainframe)
2. The user opens ZOWE Explorer and selects some of the profiles for use in ZOWE Explorer and we save the information to global vscode settings
3. The user creates another folder and puts in zowe.config.json with profiles for project B (e.g. a work related project)
4. The use opens ZOWE Explorer and gets an error that the currently selected profiles (from project A) do not exist
5. The user adds profiles from project B to dataset tree and we save them to global settings, overwriting what was there from project A
6. The user needs to go back to project A, closes ZE, reopens ZE in project A and gets an error about missing profiles from project B

Every time the user changes a project, they will be faced with errors about non-existent profiles and will have to set up their dataset/uss/jobs trees again

[jellypuno]

@VitGottwald Understood. And this is a viable candidate for our next steps after the implementation of the Beta Version. Let's open a different issue for this topic and create a separate discussion.

[VitGottwald]

After having read through the initial part of the design document, it seems that the intention with the new zowe config is to provide only _read_ API. I think this is presents an issue for our vscode extensions and I documented it here.