https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
a
At my company, we are coding in python and using poetry to manage our dependencies. Seems to work well.
e
Yup same SDK version = same plugin version
a
Copy code
āÆ 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
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
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
That's probably SDK drift, are you sure local and CI are both installing exactly the same version of the SDK
a
by sdk, you mean go packages (in our case)?
e
Yes
a
hm, I would have thought the go.mod file ensured that, but I will check
Copy code
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
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
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
Not sure what processes are in nix land, but if you can worth nudging the maintainers of that nix pkg about this
a
i quickly tried out the non 
-bin
package, and got a
Copy code
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
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
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
Copy code
(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:
Copy code
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
```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
does that go for 
pulumi-language-go
aswell?
e
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
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
šŸ‘ 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
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
3 Views
Open in Slack
PreviousNext
Powered by