Some providers have nested types whose properties can also be configured
via envvars. Until now, only top-level (non-nested) envvars are shown.
This change also shows the envvars for nested types.
Fixes#8323
Use `ComponentResourceOptions` instead of `CustomResourceOptions` for
components (for the SDKs that have `ComponentResourceOptions`) in
generated docs.
Fixes#16928
Noticed while working on another codegen related task. Python apply
calls weren't being generated correctly, they looked valid but they
didn't actually execute. They would fail with an error that the lambda
had been called without all required positional arguments.
This fixes it to use `all` in dictionary form and to index into the
dictionary in the lambda body.
This PR extends sdk-gen for .NET to support parameterized providers.
When a schema has a parameterization, we emit a new function
`PackageParameterization()` in the `Utilities` class and call this
function for generated resources, invokes and methods.
It requires https://github.com/pulumi/pulumi-dotnet/pull/311 to be
merged first and a new version of Pulumi nuget package to be released,
then we can bump the version we use here.
EDIT: Now using Pulumi nuget package v3.66.0 ✅
This takes https://github.com/pulumi/pulumi/pull/16392 and updates local
SDK generation for nodejs and adds parametrisation support for invokes
---------
Co-authored-by: Fraser Waters <fraser@pulumi.com>
Co-authored-by: Will Jones <will@sacharissa.co.uk>
Currently we generate an "internal" package in our Go sdks that the
other packages in the sdk need to import. This requires them to know the
base import path (because Go doesn't have relative imports).
We also want to start writing out go.mod files as part of codegen rather
than provider authors manually adding them in the sdk directory above.
This _also_ requires the import path for the module.
Rather than requiring every user to specify the base import path in the
schema "go language" section we improve the default behaviour to use the
provider and repository fields from the schema that users are probably
filling in anyway.
Noticed by @thomas11 on Slack
(https://pulumi.slack.com/archives/C02FXTZEZ6W/p1722410344206549). We
had a number of places doing `pulumi.String(fmt.Sprintf(template,
args))`, when they could just use `pulumi.Sprintf`. This updates
programgen to use that.
Fixes https://github.com/pulumi/pulumi/issues/16810.
The container types already marshalled correctly here, but other types
like refs and primitives didn't keep their Plain attribute.
With https://github.com/pulumi/pulumi/pull/15957 we introduced the
schema setting `Languages.Python.InputTypes` to optionally generate
TypedDict based input types side-by-side with Args classes. This setting
defaulted to `classes`, meaning that only Args classes are generated. To
enable the TypedDict types, SDK authors had to explicitly opt in by
setting it to `classes-and-dicts`.
We now flip this setting to generating TypedDict input types
side-by-side with the Args classes, unless explicitly disabled by
setting it to `classes`.
Fixes https://github.com/pulumi/pulumi/issues/16375
This required fixing `__convert` in Go programgen to handle expressions
that needed to result in input-y values. This also fixed the
"single-or-none" codegen test.
This commit extends PCL so that it knows about the `DeletedWith`
resource option. With this, we can give `pulumi convert` the ability to
preserve `DeletedWith` resource options when converting programs.
Part of https://github.com/pulumi/pulumi-yaml/pull/437
When generating literals for inputs that have TypedDict types, we want
to use the pythonic names (snake_case) for keys.
We also have to take care of tracking the fact that we’re inisde a
TypedDict for nested dicts.
Fixes https://github.com/pulumi/pulumi/issues/16646
This adds support for replacement parameterised providers to Python and
a small integration test to check it works e2e.
When using parameterised providers we need to use the new (currently
unstable) RegisterPackage system, instead of sending
Version/DownloadURL/etc via RegisterResourceRequest. Once
RegisterPackage is stable the intention is to change _all_ packages to
use it and for normal packages to fall back to the
RegisterResourceRequest options, while parameterised packages will
error.
The actual parameter value is embedded in the python SDK as a base64
string that we decode before sending to the gRPC endpoint as bytes.
This fixes go package generation so users don't _have_ to set the import
base path explicitly in the go info part of the schema. This only really
helps our packages (because we assume the path is "github.com/pulumi")
but it fixes some of the generated test data and should also work for
local SDKs, where they aren't _really_ at "github.com/pulumi" but also
that it doesn't matter what URL is used as long as it's a valid one.
Fixes https://github.com/pulumi/pulumi/issues/13756
---------
Co-authored-by: Thomas Gummerer <t.gummerer@gmail.com>
The existing overlays (e.g. Chart v3 in Kubernetes, or CallbackFunction
in AWS) are not available in every language Pulumi supports. This often
confuses users because the generated docs include all languages Pulumi
supports (e.g. see
https://github.com/pulumi/pulumi-kubernetes/issues/2181).
To solve that problem, this change adds a new optional parameter to the
schema that allows configuring the languages an overlay (resource or
function) supports.
To support this in docsgen the existing Language Chooser
(`LangChooserLanguages`) of resources is made configurable and extended
to functions.
Note: This doesn't support resource methods right now. They'll need
extra handling because and overlay resource method might not support all
of the languages its resource supports. I'll tackle this in a follow up
PR.
Here's a screenshot of how this will look like for the Helm v3 chart for
example:
<img width="1046" alt="Screenshot 2024-07-01 at 16 11 23"
src="https://github.com/pulumi/pulumi/assets/2453580/b1a1365a-6dee-4099-829a-2859639a4c8c">
The PR contains the following commits. I'd recommend to look at the
first three ones and then check the regenerated golden files in the last
one:
- **Add schema parameter to constrain supported languages for overlays**
- **Update developer docs and changelog**
- **Refactor LanguageChooser and always pass supported languages**
- **Regenerate testdata**
relates to #13231
Currently, when generating docs for the AWSX package, Go constructor
syntax examples were not generated due to a panic. This causes all
constructor examples to not be emitted in the docs.
The panic occurred when trying to get the version of referenced packages
in the PCL program to emit import paths. However, _transitive_ package
references were not resolved in the PCL binder when binding resource
types. This PR fixes the problem such that now we do find the transitive
package references from any input or output property of the resources
being bound.
In the case of the awsx package, the top-level package is awsx itself
and aws is the transitive dependency. Anytime in codegen we call
`program.PackageReferences()` we should get both of them. Added a unit
test for this as well.
Testing this fix locally against the awsx package showed constructor
examples being generated for every language, however there was still a
problem in the _formatting_ of Go code which is also fixed (see change
in `gen_program_expressions.go`)
Resolves part of #16463
For resources that don't have a schema, we emit a best guess for how
they are declared and how imports should be emitted. For these resources
we emit `index.{ResourceName}` if that resource is from the index
module, however this is not how resources are usually generated, instead
we should generate `{packageName}.{ResourceName}` for resources from the
index module which is what this PR resolves.
Fixes#16461
In this PR we fix generating constructor syntax examples for Kubernetes.
The problem initially was due to generating a PCL program with syntax
errors for the kubernetes schema. The syntax error was happening because
we emitted properties `$ref` and `$schema` which are not valid
identifiers in PCL. Fixing this was simple enough, we only needed to
quote these properties that start with dollar signs and we get a valid
PCL program.
Full PCL program for kubernetes:
https://gist.github.com/Zaid-Ajaj/abe899430a0b5f99a428934dcac75d52
However, the valid PCL program wouldn't convert to Go with program-gen
and it would hang without showing any errors or stack traces. I wrote a
script to split the programs for each resource and convert each
separately. This way I narrowed down the problem to this program:
```
resource "def" "kubernetes:apiextensions.k8s.io/v1:CustomResourceDefinition" {
apiVersion = "string"
kind = "string"
spec = {
versions = [{}]
}
}
```
Debugging this in Go program-gen didn't show an obvious error and it
kept on hanging. However I noticed that we lowering expressions twice:
once for the entirety of resource inputs when generating resources and
again when generating the expressions separately. Lowering expressions
has been the source of many bugs and it seems to trip up program-gen a
lot and suspected something wrong was going on here, so I simplified it
to lower the expressions once when we generate resource inputs. This
fixed the hang issue as well as a few of our test programs (see diffs
for test programs and tests schemas)
Tested this against the full kubernetes schema and we can now generate
the full Go program:
https://gist.github.com/Zaid-Ajaj/3ac734536969a989edae92219968d51f
> The second time we lower expressions not only is redundant but also
can generate invalid code if the lowered expressions have temporary
variables because program-gen would just emit these variables inside
inline expressions like objects and lists which gives invalid Go code.
Resolves part of #16463
This commit fixes Python code generation (specifically, program
generation) whereby we were previously emitting calls to the
non-existent `remoteAsset` function/constructor. We now use the
(correct) `RemoteAsset` constructor, in line with other asset types
exposed by the Python SDK.
Noticed this issue while doing SDK gen for parameterised providers, but
figured it deserved its own conformance test. Check that if a provider
has a pre-release semver that the _exact_ version can be reported by the
generated SDK. This already just works for NodeJS, but Python needed a
fix to write the version to `_utilities.py` rather than trying to
unconvert the pypi version from the package.
Also needed to make the conformance test checks for
`GetProgramDependencies` even weaker (which is fine, they are just a
very basic sanity check) because the provider reports a version of
"3.0.0-alpha.1.internal" while the python version is "3.0.0a1+internal".
The latest version of the core Pulumi SDK contains a decorator,
`@deprecated`, that is used when generating SDK code in order to signify
deprecated properties in a way that can be recognised by other SDK code.
This is useful when writing generic Python code that e.g. traverses
class properties without triggering deprecation warnings for those not
explicitly mentioned in user code. The [original pull
request](https://github.com/pulumi/pulumi/pull/16400) has more details.
Alas, we can't rely on the fact that a user will upgrade _both_ a
particular (generated) provider SDK and the core Pulumi SDK at the same
time. Thus, it's entirely possible that a user bumps their version of
(say) `pulumi_aws`, whilst leaving their `pulumi` library at the same
(compatible, according to specified bounds) version. In doing so they'd
hit errors when the new SDK tried to import the `@deprecated` decorator,
which doesn't exist in the old core SDK.
This commit thus fixes this by altering code generation so that each SDK
receives its own inlined copy of the `@deprecated` decorator, which it
can reference regardless of the version of the core SDK. This decorator
applies the same `_pulumi_deprecated_callable` tag to functions it
decorates, which a sufficiently modern SDK will recognise to avoid
triggering e.g. https://github.com/pulumi/pulumi/issues/15894. Later on,
we can hopefully find a way to avoid doing this and use only a version
of `@deprecated` specified in the core SDK.
Codegen tests have been updated and the inlined decorator has manually
been tested using the AWS Classic SDK.
Addresses
https://github.com/pulumi/pulumi/pull/16400#discussion_r1646562455
Epic: Improved Typing https://github.com/pulumi/pulumi/issues/12689
This PR adds the flag `Languages.Python.InputTypes` to the schema, which
can take the values `classes` or `classes-and-dicts`. In the first
iteration of the feature, this defaults to `classes`, which leaves code
generation as is and does not change input types.. If the flag is set to
`classes-and-dicts`, `TypedDict` based types are generated next to the
current `<Type>Args` classes. In the future this could be extended to
support `dicts` to generate only `TypedDict` types.
The generated types are conditional on the used type checker to work
around perf issues in MyPy and PyCharm, see
https://github.com/pulumi/pulumi/issues/12689#issuecomment-2117240276
```python
if not MYPY:
class DeploymentArgsDict(TypedDict):
api_version: NotRequired[Input[str]]
kind: NotRequired[Input[str]]
metadata: NotRequired[Input['ObjectMetaArgsDict']]
...
elif False:
DeploymentArgsDict: TypeAlias = Mapping[str, Any]
```
Removing the workaround is tracked in
https://github.com/pulumi/pulumi/issues/16408
---------
Co-authored-by: Anthony King <anthony@datapane.com>
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
Presently, the Python SDK incorrectly emits deprecation warnings for
properties even if user code does not reference them. This is due to
various pieces of code in the SDK that enumerate properties e.g. for the
purpose of serialisation/RPC calls. In enumerating properties, their
getters are invoked, triggering the deprecation warnings.
There isn't currently a way for us to detect which properties may or may
not be deprecated and handle them appropriately, so this commit
introduces one. Deprecation messages are moved into a new decorator,
`@pulumi.deprecated`. This decorator accepts a `Callable` and wraps it,
making two changes:
* Before the decorated `Callable`'s execution, deprecation messages are
printed.
* The returned `Callable` is tagged with a new reserved property,
`_pulumi_deprecated_callable`, which references the wrapped `Callable`
(that is, the original `Callable` whose invocation will _not_ produce
deprecation warnings).
With this in place, we subsequently make the following two changes:
* We modify the SDK enumeration code (specifically that in
`input_type_to_dict` to check for `_pulumi_deprecated_callable`
properties and use them where appropriate to invoke getters without
triggering deprecation warnings.
* We modify Python code generation so that instead of emitting
statements to print deprecation warnings, we simply emit applications of
the `@pulumi.deprecated` decorator instead.
This commit adds some Python unit tests to exercise the decorator and
manual testing has been performed using the AWS Classic SDK.
Fixes#15894
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
Adds a conformance test for an explicit provider resource.
# Description
Fixes https://github.com/pulumi/pulumi-azure-native/issues/1554
### Context
The problem here is that when we compute `InputType: model.Type` in
`pcl.Resource`, we map the types of input properties of resources from
`schema.Type` into `model.Type`. When one of these properties is a
`schema.UnionType` (union of objects to be exact), we map that _as is_
to `model.UnionType` which trips up Go program-gen as it doesn't know
how to reduce the type to the actual _selected_ object type based on the
resource inputs.
### Resolution
The way to fix this is not in Go program-gen, instead we _reduce_ the
computed union types during the binding phase into the actual object
types based on the resource inputs so that all program generators only
work against explicit objects rather than having to deal with unions of
objects
### Example:
```pcl
resource "example" "azure-native:eventgrid:EventSubscription" {
destination = {
endpointType = "EventHub"
resourceId = "example"
}
expirationTimeUtc = "example"
scope = "example"
}
```
Before:
```go
pulumi.Run(func(ctx *pulumi.Context) error {
_, err := eventgrid.NewEventSubscription(ctx, "example", &eventgrid.EventSubscriptionArgs{
Destination: eventgrid.EventHubEventSubscriptionDestination{
EndpointType: "EventHub",
ResourceId: "example",
},
ExpirationTimeUtc: pulumi.String("example"),
Scope: pulumi.String("example"),
})
if err != nil {
return err
}
return nil
})
```
After:
```go
pulumi.Run(func(ctx *pulumi.Context) error {
_, err := eventgrid.NewEventSubscription(ctx, "example", &eventgrid.EventSubscriptionArgs{
Destination: &eventgrid.EventHubEventSubscriptionDestinationArgs{
EndpointType: pulumi.String("EventHub"),
ResourceId: pulumi.String("example"),
},
ExpirationTimeUtc: pulumi.String("example"),
Scope: pulumi.String("example"),
})
if err != nil {
return err
}
return nil
})
```
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
# Description
Fixes#16191
The original issue is that the intermediate PCL we generate used enum
names instead of enum values for numeric enum inputs. This PR changes it
so that the PCL program now uses the first numeric value for the first
enum case then subsequently fixing downstream program-gen bugs that
didn't know how to handle numeric values as inputs for enums.
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
# Description
Partially addressing
https://github.com/pulumi/pulumi-azure-native/issues/3308
Implementing a new go language option called `importPathPattern` which
can be used to override how the base import path and modules are
concatenated to create imports in generated Go programs. By convention
this used to be `{baseImportPath}/{module}` which has worked for all of
our providers. However, azure-native v2 has introduced a new import
scheme where the convention above causes incorrect import paths to be
generated.
This is where `importPathPattern` comes into play and allows for a
different convention. In the case the of azure-native v2, the pattern
_must_ be `github.com/pulumi/pulumi-azure-native-sdk/{module}/v2`.
This PR implements `importPathPattern` and tests it using a squashed
down azure-native v2 schema containing only contents from the
`eventgrid` module. This schema sets the option like this:
```json
"importPathPattern": "github.com/pulumi/pulumi-azure-native-sdk/{module}/v2"
```
This schema also modifies `packageImportAliases` from the current
azure-native v2 schema to exclude /v2 before the module path (see the
file below). This change is needed in the actual azure-native v2
provider cc @danielrbradley and it is the second part of fully fixing
https://github.com/pulumi/pulumi-azure-native/issues/3308
> We cannot just use `{baseImportPath}/{module}` because the base import
path for azure-native v2 has a suffix v2 (it's required)
Also implemented a small feature in ProgramTest to allow overriding the
used plugin host for the specific program test, this is because I wanted
to test the program against the simplified azure-native v2 schema
without changing how other test load the previous azure-native v1.x
schemas (I tested that without this, binding programs fails)
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
The current Python code generator does not emit `__init__.py` files for
modules that only contain enumerations. This is problematic in cases
such as https://github.com/pulumi/pulumi/issues/16221, whereby
`pulumi-command` wishes to define an enumeration to be shared across
modules, in a module with no other types or resources. In such cases, an
SDK is generated that does not type check, since the enumeration types
are not exported appropriately. This commit addresses this by generating
`__init__.py` files in these cases as expected.
Fixes#16221
Upgrade pulumi-java to the latest version:
### Bug Fixes
* Escape javadoc special characters in generated code.
* Fail fast rather than emitting `PANIC`s when attempting to generate
code for ill-formed programs.
# Description
Fixes#15852 by removing the trailing whitespace from each expression
emitted in the `DependsOn` array
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
Currently, our resource API docs for Python only display a type name
itself. If the type is defined in a different module, we do not indicate
this explicitly, which causes confusion.
For example, [K8s Pod
Inputs](https://www.pulumi.com/registry/packages/kubernetes/api-docs/core/v1/pod/#inputs)
is in `core.v1` module itself but refer to the `meta.v1.ObjectMeta`
type. Node.js docs display the type as
<img width="719" alt="image"
src="https://github.com/pulumi/pulumi/assets/1454008/fb3e8fc5-7dc8-4661-ac6f-95e7d7918cfc">
but Python simply shows
<img width="725" alt="image"
src="https://github.com/pulumi/pulumi/assets/1454008/4cd4c09c-13cb-4070-b716-0b78ad98379b">
The same problem exists when we reference types from external packages,
and even for composed types like `Sequence[some_external_type]`.
This PR removes a special case for Python that reduces a full type name
to its name. Instead, it executes on the same path as Node.js and C#.
I had to apply some cleaning to Python types to remove underscore
prefixes of modules. We use underscore-prefixed imports in SDK gen, but
they should not be visible in user docs.
I expect we need to apply the same fix to Go, but I suggest we do that
as a follow-up.
Testing: the existing test suite seems adequate for testing the change.
All the discrepancies look like improvements to me.
Fixes#15137
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
# Description
Fixes#15751
- In .NET, non-primitive types such as objects used in config variables
will be generated anyways under the `Types` namespace as plain-shaped
objects inside of the `Config` class. This is because the types from
`Outputs` or `Inputs` cannot be used directly from config. Also no
longer marking objects used from config variables as "outputs" (doesn't
make any sense)
- In Go, disable adding imports into the `config.go` based on used
shared types because these are not used/referenced in the config module
anywhere anyways.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
# Description
This PR replaces the test program `discriminated-unions` with a new
program `basic-unions` that uses a synthetic schema that has basic union
definitions.
The former program was failing compilation with Go because of a
**faulty** azure-native SDK (tests using v1.56.0). It didn't generate
the extra types for union objects (those with suffix `Args`). Those
missing extra types are added in newer versions of azure-native SDK but
the shape of the same resource doesn't have unions anymore so we can't
just upgrade the version of the azure-native sdk we are testing with.
I decided not to depend on a specific azure-native SDK and instead use a
synthetic schema with the sole purpose of showing that we can emit
correct code for fields assigned to object which are bound to different
union cases. The downside here is that we can't compile the example for
any language since it is a synthetic schema with no generated SDK
(conformance tests in Go would make this possible but we are far away
from that 😢)
Closes#10834 since the original issue was due to faulty SDK, not
program-gen.
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [ ] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
# Description
This PR implements Java constructor syntax examples, rendering them into
the docs. It upgrades pulumi-java to 0.10.0 which includes features from
https://github.com/pulumi/pulumi-java/pull/1338
It also updates contructor syntax generator to emit an unbound variable
for resource-typed properties. We use the name of the resource as the
name of the variable:
```typescript
const example = new Resource("name", { pet: randomPet })
````
where `pet` is a property that is typed as `random.RandomPet` so it gets
assigned the (unbound) variable called `randomPet`
Previously we would skip emitting any code for resource-typed
properties. I think this gives better docs even though it doesn't
compile
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
# Description
This PR implements constructor syntax examples in YAML, rendering them
into the docs.
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
# Description
Fixes#14462 by special casing how we handle `dependsOn` and generating
`DependsOn = { ... }` instead of `DependsOn = new[] { ... }`
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
---------
Co-authored-by: Thomas Gummerer <t.gummerer@gmail.com>
# Description
Fixes#15769 by specifically handling object expressions that are
annotated as `Any` and emitting the correct code.
- In case of Go, expression `X` is emitted as `pulumi.Any(X)` where the
type name here is `map[string]interface{}`.
- In case of C#, we generate `Dictionary<string, object?>` expressions
(similar to what we do inside `toJSON` calls)
- Updates the test aws-native schema from 0.13.0 to 0.99.0
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new flag to the schema metadata to tell codegen to use the
new proposed style of SDKs where we fill in versions and write go.mods
etc.
I've reworked pack to operate on packages assuming they're in this new
style. That is pack no longer has the responsibility to fill in any
version information.
This updates python and node codegen to write out SDKs in this new
style, and fixes their core libraries to still be buildable via pack.
There are two approaches to fixing those, I've chosen option 1 below but
could pretty easily rework for option 2.
1) Write the version information directly to the SDKs at the same time
as we edit the .version file. To simplify this I've added a new
'set-version.py' script that takes a version string an writes it to all
the relevant places (.version, package.json, etc).
2) Write "pack" in the language host to search up the directory tree for
the ".version" file and then fill in the version information as we we're
doing before with envvar tricks and copying and editing package.json.
I think 1 is simpler long term, but does force some amount of cleanup in
unrelated bits of the system right now (release makefiles need a small
edit). 2 is much more localised but keeps this complexity that
sdk/nodejs sdk/python aren't actually valid source modules.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
# Description
This PR is an initial implementation of emitting constructor syntax of
resources into the docs for typescript, python, go and csharp.
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
# Description
This PR improves enum type resolution from strings. When we try to
resolve `Union[string, Enum]` for a string expression, we choose
`string` because it is the more general type since not every string is
assignable to `Enum`. However, here we spacial case strings that are
actually part of that `Enum`.
The result is that `pcl.LowerConversion` will choose `Enum` from
`Union[string, Enum]` when the value of the input string is compatible
with the enum. This greatly improves program-gen for all of typescript,
python, csharp and go which now will emit the fully qualified enum cases
instead of emitting strings.
Closes https://github.com/pulumi/pulumi-dotnet/issues/41 which is
supposed to be a duplicate of
https://github.com/pulumi/pulumi-azure-native/issues/2616 but that is
not the case (the former is about unions of objects, the latter is
unions of enums and strings)
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->