Profiles are not inheriting properties of parent profile, profile management has to be improved

[FALLAI-Denis]

Hi,

The extension uses a subfolder in the .vscode folder of the user folder:

This path appears to be hardcoded into the extension as it is not the path we use in our VS Code installation.

Thanks.

[antonkc]

That segment is in fact hard-coded. I haven't seen a variable to obtain the path to the set-up directory. I will check again to solve this problem.

[FALLAI-Denis]

Hi @antonkc,

export async function activate(context: vscode.ExtensionContext) {
    // Extension path
    let extensionPath = context.extensionPath;

• ExtensionContext
• Extension<T>

See also context.asAbsolutePath(AnExtentionResource) as a short hand to obtain path to a resource of the extension.

Afterwards I don't know if it is very healthy to store working files in the extension installation folder... Zowe Explorer 2.x.x did it... With Zowe Explorer 3.x.x, it seems to me that downloaded files are managed in memory.

Regards,

[antonkc]

Actually, I already knew "context.extensionPath". This path is not the same that the one I am searching for. It is precisely because my intent is to separate user files from the one the extension requieres for running. The ".vscode" path is there only to store downloads and other temporal files.

Now that I took more time to check this, I think the problem is exclusive to the profile.

[FALLAI-Denis]

Hi @antonkc,

Do you want to use the .vscode folder of the VS Code workspace? This folder only exists if you are in folder mode, and I don't think it is also a place to use, because it is reserved for the operation of VS Code. Perhaps you should use the temporary folder of the system or the active user, (%temp% on Windows, to be seen for Linux). Another solution would be to provide a parameter in the extension to declare the working folder to use, with a default value, which refers to the previous point.

I asked Copilot who referred me to a node.js module temp which allows you to manage temporary folders and files, depending on the OS used. There is also another node.js module tmp which does the same thing. They also provide tracking and automatic cleaning of temporary files created. By analyzing the code, these modules use os.tmpdir() to obtain the temporary folder of the host system.

And the result for a Windows context:

Regards,

[antonkc]

Thanks for the input @FALLAI-Denis

I still need to check the impact due potential unwanted consequences. But I think there is a solid chance we will switch to the operating system provided temporal folder.

[antonkc]

Greetings @FALLAI-Denis , let's focus in the profile issue in this thread.

We are not able to recreate the error. So we would appreciate a bit of help here. First, have you checked if reloading the profile fixes the problem?

We may find useful information in the output window too:

If both of these fail, I actually already did an adjustement that may fix the problem, but since we are not able to recreate it in the first place, I am not sure if it did anything. My proposition is to give you the vsix before publishing as a last resort.

[FALLAI-Denis]

Hi @antonkc,

I installed the new version 2.2.1:

I switched to English display for screenshots. I restarted VS Code. I reloaded the Zowe profiles using the IBM Z Open Editor command. The Zowe Explorer output shows:

Still the same problem:

But I see in the menu a specific command to associate a profile with z/OS File Editor: If I activate it, it does not offer me profiles present in the zowe project team profiles file that exists in my workspace, but user profiles that exist only in a team profiles file in my personal user folder: Clearly, it only shows profiles that exist in my user folder's team profiles file minus profiles that exist in my workspace's team profiles file...

So actually the z/OS File Editor extension only takes into account user level profiles, and does not take into account project level profiles. And if the new user profiles are hidden by project level profiles they are ignored.

See: How Zowe CLI uses configurations.

Regards.

[FALLAI-Denis]

PS:

I disabled project level team profiles (in workspace)... But z/OS File Editor only sees one more profile:

I disabled all user profiles in my user folder to leave only team profiles at the global level:

Reload VS Code... No improvement...

I disabled all profiles at global and project level... This time z/OS File Editor can't find any profiles...

I only reactivate team profiles at the project level (reload Window). no more errors at Zowe Explorer and IBM Z Open Editor level, but z/OS File Editor does not want my profiles: a protocol is required? Indeed, the protocol is not indicated in the profiles... Note that https is the default value for protocol property:

Adding the protocol: Nice! But if I don't force a profile at the z/OS File Editor level, the file recovery is not correct, the structure of the records is not recognized, and the encoding is still not that of the profile: If I force a profile at the z/OS File Editor level, the structure of the records is recognized, but the encoding is still not that of the profile:

[FALLAI-Denis]

PS 2:

Finally, I reactivated all profiles at the global level (user folder) and at the project level: all z/OSMF profiles that have a protocol are recognized, and those that do not are ignored (but no error message if at least one profile is found with a protocol).

So the problem in identifying profiles is related to the lack of a property at the profile level that has a default value in the schema.

Which was not the subject of this issue which concerns the use of a hardcoded folder to store working files.

[antonkc]

This shall be the thread to discuss the profile problem. Incidentally, you already provided enough information to work with. I just need time to come to a decision of how to handle this since zowe doesn't provide the profiles with the inherited information. At least, in the way that I am handling the profiles. I do not discard taking this upstream if I can articulate a good case.

The path is ancilliary and is a non-problem in this case. I created #7 to talk about it.