Installing the same plugin twice leads to a failed install. #100
Comments
ghost
added
bug
|
After review, I found that doing the install from a .tgz of the cics plugin did not yield this error unless I installed cics from a registry and then installed from the tgz. If I installed the tgz and then reinstall the tgz, no error. |
|
I tried to fix this error but there are not much research for this. It seems it is not able to delete existing plugin because it is linked to brightside. Here is similar issue npm/npm#9680 |
|
Updating a only just does an npm install but doesn't let you specify the version or a package file. I think this behavior was different at one point in time and I think update needs reworked in plugins. With that in mind, the only path forward for users installing plugins is to currently uninstall and then install them to get around this error. However, once we make changes to refactor uninstall to use the npm apis, I fear that you will run into the situation where npm refuses to uninstall the package since it thinks it isn't under npm's control. This means to install an update to a plugin, a user must go into the I believe this must be addressed before we can even consider releasing Imperative 2.0.0 as a supported release. |
|
I agree, it should be researched. Maybe @plavjanik could look at this before we go for 2.0.0 release. |
|
I think I've cracked the case on this one, turns out we can revisit the api changes and put execSync back in kind of like this. const npmPath = path.join(__dirname, "../../../../../../node_modules/npm");
console.log(npmPath);
const pipe = ["pipe", "pipe", process.stderr];
const installCommand = require("child_process").execSync(`"${process.execPath}" "${npmPath}" install "${npmPackage}" --prefix "${PMFConstants.instance.PLUGIN_INSTALL_LOCATION}" ` +
`-g --registry "${registry}"`, {
cwd: PMFConstants.instance.PMF_ROOT,
stdio: pipe
});
console.log(installCommand);This works for both an I also did some playing around and found that any cli that bundles us needs node-gyp stuff to be installed (at least with the current calls to the npm api, that may change). We can do this by adding this line to the package.json: So that the pkg tool can inherit the things we need. Then we could also say that an imperative cli can be packaged using pkg as the preferred tool. |
|
the command fails for me and it seems process.execPath is using global node from program files, is it the same for you ? |
|
process.execPath will use the exe that spawned the process. When using a cli installed through npm, this will be the node.exe process that was used to spawn the code. When using a packaged cli it resolves to the executable package. So if I have cli.exe, the spawn sync command would look a bit like this: So in quick research this appears to use the node executable within the packaged application. I could give my methodology a shot in an environment where node doesn't exist just to be sure. |
|
Also note that the command might fail depending on where you put the code. This code was for the install.ts file. If placed somewhere else you may need to update the path to the node_modules folder. |
|
@AHumanFromCA could you please try it in environment where node doesn't exist, soon I will refactor uninstall, I would use this approach if it works. Thanks |
|
Also, during that refactoring I would also refactor install and update |
|
Sounds good, I will try to do that today or tomorrow. |
|
@nurra01 would this suffice for the test you want. Since I need node to build everything, I plan on keeping node installed on my system. So to test, I plan to:
Would that suffice? |
|
@AHumanFromCA yes, this should be sufficient. |
|
I added a line to output the command that gets executed so we can be sure. Output for npm installed packageOutput for executable (with no access to node)As you can see it works in both environments in exactly the same manner. |
|
@AHumanFromCA good, it should be much better than using api functions. I think we could try it also on empty environment, to be 100% sure, we have few virtual machines, I will try it tomorrow. Thanks |
I ran a plugin install from zowe-cli using the same plugin twice.
First Run
Second Run
As you can see, the second install failed because npm thinks that the plugin installed folder is actually a npm package. I had concerns about this message while reviewing #75, but perhaps it is crucial to remove this message in order for npm to recognize as a global package install.
I had a mention of this in #99, indicating that there is a difference between doing
npm i -g --prefix "~/.zowe/plugins" some-packageand what we thought was the same thing using the apis.The text was updated successfully, but these errors were encountered: