More automation api questions... - Are the followi...
# dotnet
More automation api questions... • Are the following cli options still relevant, and if so can they be set? • ...
• Are there plans to eventually avoid the need for
? • ... otherwise has anyone tried to automate this step somehow?
@bored-oyster-3147 any thoughts on the above?
re pulumi cli options, I can add them to my own cli and pass them through the automation api if configurable...
re plugins, do they need to be installed for every stack? ... I intend to run multiple stacks from one custom cli command
Also, needing to specify plugin names and versions is a bit fiddly when they need to match nuget packages, so the version is in two places and becomes a chore to update.
I'm compiling to a single file executable with dotnet 5, so I can't use the related assembly version at runtime afaik.
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:
🙌 1
I'd definitely be willing to look into what implementing this for dotnet might entail.
🍺 1
🚀 1
@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: Automatic plugin acquisition will involve implementing this for the inline language runtime server:[…]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.
Will probably need a bit of experimentation.
Well I'm thinking for inline programs if it is using a traditional
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
I have some ideas. I'm going to put something together in the next few days so I can get your thoughts on it
👍 1
@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
but I was using a hack to preinstall the plugins into the runtime container:
Effectively I'm mapping the dotnet nuget package to the plugin name and version. Ideally the nuget package has a method that can simply "load the plugin" that it depends on so there's no magic required.
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
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
That's why I changed my dockerfile to use
dotnet list package
to mimic what was happening for csproj files
Still feels like this process should be "inverted"; either ask the package for the list of plugins (name, version) it requires, or ask the package to install them. The first option might be better as then the caller could aggregate and sort the list for uniqueness across multiple package dependencies, apply caching etc.
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:
That will help a lot actually, thank you
partypus 8bit 1
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.