-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Emit schema.Package.Version when possible #7938
Conversation
Diff for pulumi-random with merge commit 5fe49eb |
Diff for pulumi-azuread with merge commit 5fe49eb |
Diff for pulumi-kubernetes with merge commit 5fe49eb |
Diff for pulumi-random with merge commit b316eca |
Diff for pulumi-azuread with merge commit b316eca |
Diff for pulumi-kubernetes with merge commit b316eca |
Diff for pulumi-gcp with merge commit 5fe49eb |
Diff for pulumi-aws with merge commit 5fe49eb |
Diff for pulumi-gcp with merge commit b316eca |
Diff for pulumi-aws with merge commit b316eca |
Diff for pulumi-azure with merge commit 5fe49eb |
Diff for pulumi-azure with merge commit b316eca |
pkg/codegen/python/gen.go
Outdated
// TODO: puipyVersion is the pythonic version of pkgVersion. The code to | ||
// transform it is in pulumi/pulumictl. Should that be extracted to | ||
// somewhere like pulumi/pulumi/sdk/python.go? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No strong opinions.. looks like pulumictl depends on pkg https://github.com/pulumi/pulumictl/blob/master/go.mod#L11 so if the least common ancestor is pkg we can put it there; alternatively factor into its own little dedicated GH repo and package. The barriers to that are pleasantly low. If it's really small then "a little dulication is better than a little dependency" applies here too so we can inline a copy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just duplicated the code.
Taking a closer look, most of the code dealt with the current git tree being dirty, and generating a semver version. Since we are provided a semver version already, I just help with the pythonic parts. It's not long. I located it in pulumi/pkg/codegen/python/utilities.go
.
SO I dug around how these versions are used and filed #7955 with questions. The fact Python (and Node?) auto-install Go plugins binaries in their setup.py strikes me as a bit of an unfortunate choice. Presumably this is the distinction:
The |
I like where this is going since Makefile-based manipulations of VERSION were giving me some headache. Before we ship this it would be good for @mikhailshilkov to make sure this causes no extra problems for provider builds. |
The reason we put this version placeholder initially was to avoid version-related diffs on every commit. Has this been mitigated somehow? Adding @stack72 to chime in too. |
@mikhailshilkov The mitigation is that if you don't specify version in |
@iwahbe Thank you for the clarification! Do I understand correctly that this is mostly to clean up the tests but likely won't affect the providers? |
It is primarily about cleaning up tests and internal consistency. It should also help decrease the amount of makefile necessary for multi-lang. |
This looks great! We'd talked about doing something similar in #7589 - am I understanding correctly that this PR achieves the "set the version in a single location" part of that issue? |
Diff for pulumi-kubernetes with merge commit fc7ccce |
Diff for pulumi-gcp with merge commit fc7ccce |
Diff for pulumi-aws with merge commit fc7ccce |
Diff for pulumi-azure with merge commit fc7ccce |
Note that this is only the case for workflows that do this explicitly by using |
@iwahbe I'm not really super sure, how does our system do it in practice? I peeked at https://github.com/pulumi/pulumi-aws/blob/master/sdk/python/setup.py#L11 and I see 0.0.0. That seems to work? Also in my investigation #7955 it turns out that Node JS packages are the other kind of packages that auto-install the plugin, yet they have no PULUMI_VERSION distinction? How do they do it? I can't seem to find the mechanism of how we hook into npm install. |
Taking a look around pulumi-aws I saw what you did, but when ran |
At this point I'm fairly convinced that the correct behavior (when not testing) is to create a pythonic version of When testing, we emit |
pkg/codegen/python/gen.go
Outdated
pluginVersion := "0.0.0" | ||
if version.Version != "" { | ||
// This happens in test builds | ||
pluginVersion = version.Version | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that we want to use version.Version
here: "github.com/pulumi/pulumi/pkg/v3/version"
is the version of the Pulumi SDK itself, and is unrelated to the schema version. Should this be
pluginVersion := "0.0.0" | |
if version.Version != "" { | |
// This happens in test builds | |
pluginVersion = version.Version | |
} | |
pluginVersion := "0.0.0" | |
if pkg.Version != nil { | |
pluginVersion = pkg.Version.String() | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your right. I got the version of the pulumi-resource-*
confused with the version of pulumi
itself.
@t0yv0 I want to make sure the tests pass, then I'll merge. |
Diff for pulumi-azuread with merge commit b716553 |
Diff for pulumi-aws with merge commit b716553 |
Diff for pulumi-azure with merge commit b716553 |
Diff for pulumi-gcp with merge commit b716553 |
Diff for pulumi-random with merge commit b716553 |
Diff for pulumi-kubernetes with merge commit b716553 |
Description
We currently offload adding the
Package.Version
information to makefiles in our SDKs. This means that package information which is specified in aschema.json
is ignored in favor of another process. This PR has version information emitted if and only ifPackage.Version
is supplied. This meansversion.txt
fordotnet
setup.py
accurately contains a version forpython
package.json
accurately reports it's version fornodejs
.If
Package.Version
is not supplied, no behavior is changed.This has 2 major motivations:
"0.0.0"
is not expected behavior.dotnet build
requiresversion.txt
to exist. This prevents special cases from developing SDKs and testing our SDK codegen.Pending Questions
VERSION
andPLUGIN_VERSION
Checklist
npm
oryarn
for testing (discussed for Codegen testing upgrades #7989).