error: failed to load language plugin nodejs #1956
Comments
|
@trondhindenes did you install via curl, brew, or some other means? @ellismg any idea what might be wrong here? |
When My only other suspicion was if you were somehow invoking In addition to understanding how exactly you installed Pulumi, I'd love to know if |
|
ah gotcha. I symlinked the pulumi binary, the doc didn't say anything about other refs / pathing requirements. |
|
I'm having the same issue. I am using pyenv with python 3.6.6 and pulumi 0.15.4 |
|
@ellismg Any idea what might be going on here? |
joeduffy
added
kind/bug
When launching plugins today, `pulumi` looks in two places: 1. It looks to see if the plugin in on the $PATH and if so, uses it. This makes it easy to force a specific version of a resource provider to be used and is what happens at development time (since resource providers make their way onto $PATH via GOBIN). 2. If the above fails, it looks in the "plugin cache" in `~/.pulumi/plugins`. This is the location that `pulumi plugin install` places plugins. Unlike resource provider plugins, we don't yet deliver language plugins via `pulumi plugin install` so the language provider plugins must be on the `$PATH` to be found. This is okay, because when we ship the SDK, we include the executables next to `pulumi` itself. However, if a user chooses to not put `pulumi` on their $PATH, or they do but it is a symlink to the real `pulumi` binary installed somewhere, we'd fail to find the language plugins, since they would not be on the `$PATH` To address this, when probing for language plugins, also consider binaries next to the currently running `pulumi` process. Fixes #1956
When launching plugins today, `pulumi` looks in two places: 1. It looks to see if the plugin in on the $PATH and if so, uses it. This makes it easy to force a specific version of a resource provider to be used and is what happens at development time (since resource providers make their way onto $PATH via GOBIN). 2. If the above fails, it looks in the "plugin cache" in `~/.pulumi/plugins`. This is the location that `pulumi plugin install` places plugins. Unlike resource provider plugins, we don't yet deliver language plugins via `pulumi plugin install` so the language provider plugins must be on the `$PATH` to be found. This is okay, because when we ship the SDK, we include the executables next to `pulumi` itself. However, if a user chooses to not put `pulumi` on their $PATH, or they do but it is a symlink to the real `pulumi` binary installed somewhere, we'd fail to find the language plugins, since they would not be on the `$PATH` To address this, when probing for language plugins, also consider binaries next to the currently running `pulumi` process. Fixes #1956
When launching plugins today, `pulumi` looks in two places: 1. It looks to see if the plugin in on the $PATH and if so, uses it. This makes it easy to force a specific version of a resource provider to be used and is what happens at development time (since resource providers make their way onto $PATH via GOBIN). 2. If the above fails, it looks in the "plugin cache" in `~/.pulumi/plugins`. This is the location that `pulumi plugin install` places plugins. Unlike resource provider plugins, we don't yet deliver language plugins via `pulumi plugin install` so the language provider plugins must be on the `$PATH` to be found. This is okay, because when we ship the SDK, we include the executables next to `pulumi` itself. However, if a user chooses to not put `pulumi` on their $PATH, or they do but it is a symlink to the real `pulumi` binary installed somewhere, we'd fail to find the language plugins, since they would not be on the `$PATH` To address this, when probing for language plugins, also consider binaries next to the currently running `pulumi` process. Fixes #1956
When launching plugins today, `pulumi` looks in two places: 1. It looks to see if the plugin in on the $PATH and if so, uses it. This makes it easy to force a specific version of a resource provider to be used and is what happens at development time (since resource providers make their way onto $PATH via GOBIN). 2. If the above fails, it looks in the "plugin cache" in `~/.pulumi/plugins`. This is the location that `pulumi plugin install` places plugins. Unlike resource provider plugins, we don't yet deliver language plugins via `pulumi plugin install` so the language provider plugins must be on the `$PATH` to be found. This is okay, because when we ship the SDK, we include the executables next to `pulumi` itself. However, if a user chooses to not put `pulumi` on their $PATH, or they do but it is a symlink to the real `pulumi` binary installed somewhere, we'd fail to find the language plugins, since they would not be on the `$PATH` To address this, when probing for language plugins, also consider binaries next to the currently running `pulumi` process. Fixes #1956
When launching plugins today, `pulumi` looks in two places: 1. It looks to see if the plugin in on the $PATH and if so, uses it. This makes it easy to force a specific version of a resource provider to be used and is what happens at development time (since resource providers make their way onto $PATH via GOBIN). 2. If the above fails, it looks in the "plugin cache" in `~/.pulumi/plugins`. This is the location that `pulumi plugin install` places plugins. Unlike resource provider plugins, we don't yet deliver language plugins via `pulumi plugin install` so the language provider plugins must be on the `$PATH` to be found. This is okay, because when we ship the SDK, we include the executables next to `pulumi` itself. However, if a user chooses to not put `pulumi` on their $PATH, or they do but it is a symlink to the real `pulumi` binary installed somewhere, we'd fail to find the language plugins, since they would not be on the `$PATH` To address this, when probing for language plugins, also consider binaries next to the currently running `pulumi` process. Fixes #1956
|
I believe this problem is the absence of a I was receiving this message on Windows (0.16.16), installed via Powershell script, and Linux (0.16.17), installed by unpacking the tarball and adding it to the path manually (CI script). |
|
Just got this same error, running on mac terminal. pulumi up Diagnostics: error: failed to load language plugin nodejs: could not read plugin [/usr/local/bin/pulumi-language-nodejs] stdout: EOF $ which pulumi Not at all clear what to do next. |
|
Hey @dangersorus. Have you come to a solution on this issue? I got exactly the same here and it would be very helpful if you could share that. |
|
It appears that these "failed to load plugin" errors are because dependencies of that plugin can not be found. I was having issues with the node.js version. I ran |
|
Anyone coming across this is in the future who has recently switched from nvm to a native nodejs install. You need to clear you yarn / npm cache and to a yarn / npm install and then the error should be resolved. |
|
I was running into a similar issue: It was working fine until a recent upgrade of pulumi via brew.
Uninstall, |
|
Hi! I have upgraded Pulumi today from 3.17.1 to 3.18.1 and get exactly the same error. Removing executables/reinstalling Pulumi did not help. I still get:
Any other ideas? |
|
I ran into this same error when I created a second stack within a project. The older stack continued to work just fine but something went wrong when I created a second stack and I would receive an error about failing to load the plugin. Running |
Trying the kubernetes "getting started" example. I did "pulumi new", then chose kubernetes-typescript. Didn't modify anything, getting this error whatever I do:
"error: failed to load language plugin nodejs: no language plugin 'nodejs' found in the workspace or on your $PATH"
Nothing else is printed even if setting verbose logging (v=3)
Nodejs: 8.10.0
typescript 3.0.3
pulumi: v0.15.2
The text was updated successfully, but these errors were encountered: