https://pulumi.com logo
Title
a

adamant-father-26302

01/31/2023, 5:25 PM
whats the prefered way to get the same versions of pulumi plugins across different machines?
a

ambitious-alligator-62127

01/31/2023, 5:31 PM
At my company, we are coding in python and using poetry to manage our dependencies. Seems to work well.
e

echoing-dinner-19531

01/31/2023, 6:04 PM
Yup same SDK version = same plugin version
a

adamant-father-26302

01/31/2023, 6:04 PM
āÆ cat go.mod|grep kubernetes
        <http://github.com/pulumi/pulumi-kubernetes/sdk/v3|github.com/pulumi/pulumi-kubernetes/sdk/v3> v3.22.1

āÆ pulumi plugin ls|grep kubernetes
kubernetes                resource  3.19.2        78 MB   8 months ago   45 minutes ago
kubernetes                resource  3.19.0        77 MB   8 months ago   45 minutes ago
kubernetes                resource  3.18.2        77 MB   9 months ago   45 minutes ago
kubernetes                resource  3.17.0        77 MB   10 months ago  45 minutes ago
it seems to skew here
e

echoing-dinner-19531

01/31/2023, 6:05 PM
When an SDK sends a resource registration to the engine it includes what version of the plugin to use to handle that resource, it should not be possible to get version skew in what's used. What's installed doesn't really matter, that's just a cache of download binaries.
a

adamant-father-26302

01/31/2023, 6:07 PM
i noticed because when the same code ran in our CI, it wanted to change :
(thats from pulumi preview --refresh)
but when i run pulumi preview --refresh locally it does not want to change that
e

echoing-dinner-19531

01/31/2023, 6:08 PM
That's probably SDK drift, are you sure local and CI are both installing exactly the same version of the SDK
a

adamant-father-26302

01/31/2023, 6:08 PM
by sdk, you mean go packages (in our case)?
e

echoing-dinner-19531

01/31/2023, 6:09 PM
Yes
a

adamant-father-26302

01/31/2023, 6:09 PM
hm, I would have thought the go.mod file ensured that, but I will check
resource plugin kubernetes is expected to have version >=3.22.2, but has 3.22.1; the wrong version may be on your path, or this may be a bug in the plugin
isnt it weird that it says i have 3.22.1 when
pulumi plugin ls
say i dont have any versions higher than 3.19.2 ?
my go.mod says I have 3.22.1 of the sdk though
kubernetes.PkgVersion() says i have 3.0.0
e

echoing-dinner-19531

01/31/2023, 9:36 PM
Oooh
This looks like PATH is picking up ambient providers. If you do
which pulumi-resource-kubernetes
does that return anything? Because it shouldn't!
a

adamant-father-26302

02/01/2023, 10:19 AM
it was indeed, the
pulumi-bin
package in nixpkgs comes with a lot of pulumi-plugins in the binary directory
the
pulumi
without
-bin
(built from source instead of upstream binary) does not have that
e

echoing-dinner-19531

02/01/2023, 10:21 AM
Not sure what processes are in nix land, but if you can worth nudging the maintainers of that nix pkg about this
a

adamant-father-26302

02/01/2023, 10:22 AM
i quickly tried out the non
-bin
package, and got a
error: failed to load language plugin go: Could not automatically download and install language plugin 'pulumi-language-go', install the plugin using `pulumi plugin install language go`.
Underlying error: 404 HTTP error fetching plugin from <https://api.github.com/repos/pulumi/pulumi-go/releases/latest>.
error instead šŸ™‚
does that ring any bell on a missconfiguration somewhere?
cause it shouldnt be that url it fetches from ?
I will look into these packages,
e

echoing-dinner-19531

02/01/2023, 10:23 AM
yeh you need the pulumi-language- binaries on path
but not the pulumi-resource- binaries
that'll get fixed at somepoint to move the languages to the plugins folder same as resources, but at the moment they're special
a

adamant-father-26302

02/01/2023, 10:24 AM
ah!
they do have a few language-plugins, but unfortunately not the go one, but should probably be easy to make https://search.nixos.org/packages?channel=unstable&amp;from=0&amp;size=30&amp;sort=relevance&amp;type=packages&amp;query=pulumiPackages
alternatively try the
pulumi-bin**
package, and try hide most of the plugins (except the special ones)
doing this
(pkgs.pulumi-bin.overrideAttrs (old:
                  {
                    postUnpack = ""; # override this phase which tries to move all the pulumi plugins we have filtered out from srcs
                    # filter out all srcs refering to plugins.
                    srcs = builtins.filter (src: !(nixpkgs.lib.strings.hasInfix "<http://api.pulumi.com/releases/plugins/pulumi-resource-|api.pulumi.com/releases/plugins/pulumi-resource->" src.url)) old.srcs;
                  }))
seems to work, to filter out all? the plugins, now it will try download plugins itself, and output from its binary directory has a lot less now:
at 14:54:49 āÆ ls /nix/store/mhg6f5y2rq9addw2wgidffmjgbl8vrmy-pulumi-3.53.1/bin/
ļ’‰ pulumi                         ļ’‰ pulumi-language-dotnet  ļ’‰ pulumi-language-nodejs       ļ’‰ pulumi-language-yaml           ļ’‰ pulumi-watch
ļ’‰ pulumi-analyzer-policy         ļ’‰ pulumi-language-go      ļ’‰ pulumi-language-python       ļ’‰ pulumi-resource-pulumi-nodejs
ļ’‰ pulumi-analyzer-policy-python  ļ’‰ pulumi-language-java    ļ’‰ pulumi-language-python-exec  ļ’‰ pulumi-resource-pulumi-python
but I do wonder what the intention is by bundling all the plugins
nixos cant run most dynamically linked binaries, so that might be an issue, but afaik all the plugins are statically built
it could work nice having it bundled, as long as you always keep your sdk's matching the versions your current nixpkgs revision points to
this is the reasoning (https://github.com/NixOS/nixpkgs/commit/7622f30ed2115702e046b2fbd452a5d32af5c5fc ), But all the plugins ive tried have worked fine on nixos without patching, cause they are statically built, but ofcourse there are many plugins, maybe some of them arent.
e

echoing-dinner-19531

02/01/2023, 3:22 PM
```pulimi will look for it in
your PATH```
It will but it can only load one plugin off path, and it has to assume it's the right version. If that package wants to pre-pack binaries it should still be putting them into ~/.pulumi/plugins not just on path.
a

adamant-father-26302

02/01/2023, 3:24 PM
does that go for
pulumi-language-go
aswell?
e

echoing-dinner-19531

02/01/2023, 3:27 PM
No, the pulumi-language- executables need to either be on PATH or in the same directory as the main pulumi executable. The engine will prefer the one on PATH but will then look next to "pulumi" before looking in the plugin folder. You can put them in the plugin folder
~/.pulumi/plugins/language-go/pulumi-language-go
would still work, but it's not how we package them for other systems.
a

adamant-father-26302

02/01/2023, 3:32 PM
I am then thinking, using the
pulumi
package (which builds pulumi from source) that doesn't wrap any plugins with it, running that together with
pulumi-language-go
, both will then be in
PATH
and then cross fingers that plugins are statically built. working now on a package for
pulumi-language-go
https://github.com/afreakk/nixpkgs/commit/74f6fc38e09b024d8d9a0377b4022c614d0466fb
they already have package for language-{nodejs,python}, but dont have for go, package for nodejs here https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/tools/admin/pulumi-packages/pulumi-language-nodejs.nix#L7
been testing it locally and it seems to work
e

echoing-dinner-19531

02/01/2023, 3:37 PM
šŸ‘ Cool, I don't know much about nix myself but if there's small things we can do to help the community with doing a nix pkg I'd like to know
a

adamant-father-26302

02/01/2023, 3:38 PM
most important part I think is, since we shouldnt wrap the plugins, you should build them statically, so they dont have hardcoded paths in the binaries, which relies on FHS