Issues seen with ConvertV1Profiles.convert() when trying to adopt

[JillieBeanSim]

Describe the bug

While trying to adopt the 8.0.0-next.202405241828 for Zowe Explorer and updating the breaking changes around converting v1 profiles with ConvertV1Profiles.convert() we are seeing that the converted information isn't being written to a file and the schema file isn't being created. Looking over the code it seems it should be handled. I tested this on macOS and Windows with same result. I also see that the handler is handling the removal of the SCS plugin, but the delete method it relys on is not public for extenders. I agree with it not being public but if that's the case should the ConvertV1Profiles.convert() handle this check and delete if needed for extenders.

Expected and actual results

Details about the behavior:

1. API used: ConvertV1Profiles.convert()
2. Expected results: Config file created at global level with the converted v1 profiles along with schema file
3. Actual results: success message but files not created
4. Applicable log files:

Describe your environment

Additional context

[github-actions[bot]]

Thank you for creating a bug report. We will investigate the bug and evaluate its impact on the product. If you haven't already, please ensure you have provided steps to reproduce the bug and as much context as possible.

[gejohnston]

We have no immediate answer regarding this failure. Places to start investigating include:

• Maybe ConvertV1Profiles relies on some item initialized by Imperative.init (which is called by Zowe CLI), but is not initialized by ConfigUtils.initImpUtils (which is called by ZE). We are investigating that possibility.

• Perhaps in your ZE debug/test environment you had the environment variable for your Zowe home directory pointed to somewhere other than your $HOME/.zowe directory. The successful return indicates that ConvertV1Profiles thought it wrote some files. Can you double-check the possibility that they were written to another location?

Regarding your question about uninstalling the old SCS plugin, either I misunderstand your question, or there is some confusion about terminology. There are two separate actions “delete” old V1 profiles from disk, and “uninstall” the old SCS plugin. Your logic can decide whether to do one action, both actions, or neither action.

A private function named ConvertV1Profiles.deleteV1Profiles() deletes old V1 profiles from disk. A caller of ConvertV1Profiles.convert() specifies whether or not to delete the old V1 profiles by passing the optional parameter convertOpts.deleteV1Profs = true. So, this action can be done by ConvertV1Profiles.convert as you choose. This gives you option of asking the user whether they want to delete their old V1 profiles or not, before you call ConvertV1Profiles.convert.

A function named uninstall (from within imperative) does the actual uninstall of the SCS plugin. I think that this is the function that you were referring to about being private. Because uninstall() is exported, I thought it would be available to you. My mistake. The imperative index.ts files to not make the uninstall function externally accessible. The ConvertV1Profiles.convert function cannot call this function for you, because unavoidable circular dependencies occur when I originally attempted that.

In retrospect, we probably should not make that uninstall function externally available. That would enable any plugin or extender to uninstall any plugin, which is inappropriate and probably dangerous. I think we should create a new function named UninstallObsoleteScsPlugin(). We can make that function externally available. The CLI command handler would be modified to call that new function. ZE could also call that new function. If I have interpreted this part of your issue correctly, I think this would be our best approach. Unless you see a problem with this approach, we will pursue it after we determine why new zowe.config.json and zowe.scheme.json files are not being created for you.

[gejohnston]

We were able to place a temporary hack into a local copy of Zowe CLI, which can be quickly rebuilt to initialize with either the CLI’s Imperative.init() function or with the ZE-focused ProfileInfo initialization. When initialized with ProfileInfo, the CLI reproduces the problem of not creating the new Zowe config files. The ConvertV1Profiles.convert function does report errors within the object that it returns. That message is:

Could not locate the specified module through requiring directly, nor through searching the directories above null.
'require()' error message: Cannot find module 'package.json’

Our approach will be to initialize additional required information within ProfileInfo, so that ZE has a workable environment. The good news is that we have a workable test-bed to make changes and debug in CLI with an environment similar to ZE.