This message was deleted.

@bored-oyster-3147 any thoughts on the above?

These questions might be better suited for @red-match-15116 or @lemon-agent-27707. I agree that currently the manual plugin installation & keeping it in-sync with NuGet packages is a chore, I am running into a similar issue with my own API-hosted Automation API usage. I think that specifically might be a limitation of the current CLI dependency, but they might be able to answer better

It would be nice if the nuget package knew this relationship and had a way to bootstrap the correct version of the plugins

I think this is the relevant issue: https://github.com/pulumi/pulumi/issues/5448

I'd definitely be willing to look into what implementing this for dotnet might entail.

@bored-oyster-3147 I think this is where you might want to start digging. TBH haven’t spent much time on this myself but let us know if you run into any blockers

@red-match-15116 is the implementation you linked one that works for inline programs?

GetRequiredPlugins is part of the gRPC interface for LanguageServer. LanguageServer is what runs inline programs. For CLI programs, language servers are implemented in go. Here's plugin acquisition for dotnet: https://github.com/pulumi/pulumi/blob/73a66f48ead301bacf1d7d2833c016cf803b57c1/sdk/dotnet/cmd/pulumi-language-dotnet/main.go#L128-L199 Automatic plugin acquisition will involve implementing this for the inline language runtime server: https://github.com/pulumi/pulumi/blob/73a66f48ead301bacf1d7d2833c016cf803b57c1/sdk/dotnet/Pulumi.Automation/Runtime/LanguageRuntimeService.cs#L[…]30 The design for this may not be so straight forward. Different inline programs require different sets of plugins, the entire program could be a compiled executable without dependency information to inform plugin versions, etc.

Well I'm thinking for inline programs if it is using a traditional

Pulumi.Stack

than we could potentially get the parent assembly of that stack implementation and use it to comb dependencies and find references to pulumi providers. So that would basically be this functionality. But if the inline function is a delegate and they're not providing a stack type, than it may require some thought about how we determine what assembly we should use as a root assembly. Especially since delegates like that could be chained from anywhere.. not even sure where to begin with that honestly

@bored-oyster-3147 please consider the implications of compiling to a single file executable too

That's a good point. I'm curious - are you able to run pulumi programs with a single file executable outside of Automation API if you specify the binary location in your project YAML file?

Yes I was able to do that before switching to automation api

was the end result of that that the pulumi CLI was able to acquire the required plugins for your self contained executable? or rather, can the pulumi CLI do that currently?

Not sure what you mean by "acquire the required plugins"... the single file executable ran successfully though

Yea I was confused for a moment. So my understanding is that currently the binary option for dotnet is not able to determine which plugins are required because it relies on

.csproj

to do so, correct?

So I guess the pulumi cli found the plugins

I'm going to see if I can get something together that works and then start thinking about edge cases

Re csproj - yes: https://github.com/pulumi/pulumi/issues/5334#issuecomment-704230763

The problem you are currently having IMO is that your plugins are listed in 2 places (your automation API code and your NuGet packages) and you need to keep them in sync. If we were doing either of the options you just suggested I don't think it would solve the problem of there being 2 sources of truth. Ideally the Automation API should be able to determine the plugins required auto-magically like the CLI does from the single source of truth, your package's dependencies. I don't think determining the plugins that we need, or installing them, will be the issue - the issue is between those 2 actions, which is determining the version. For dotnet programs the CLI relies on running

dotnet build

itself in order for the provider binaries to be present in the nuget cache directory. Since Automation API isn't doing any kind of

dotnet build

, there will need to be some other mechanism for fetching those binaries if they are not present. Because this function relies on parsing a version file that the package includes bundled. I suspect this is because NuGet Version != Plugin Version

I suspect this is because NuGet Version != Plugin Version

I find this surprising

I don’t know if that’s actually why, just me guessing why it would read version from the text file rather than the NuGet package

This is the PR where it was originally introduced, if thats helpful: https://github.com/pulumi/pulumi/pull/3450/files

That will help a lot actually, thank you

I see this comment - which makes me think it was to distinguish resource plugins from other pulumi packages

Pulumi package doesn’t contain a version.txt file. This is not a resource-plugin.

just ignore it.