When a resource `dependsOn` a remote component, we were not correctly waiting on it, because we were skipping over waiting on comoponents, and only waiting on their custom resource children. For remote components, we do not know the children, but waiting on the remote component will always wait on all children.
Co-authored-by: Mike Metral <1112768+metral@users.noreply.github.com>
- Only build casing tables once per package
- Right-size buffers in name generation
These changes lead to a significant speedup in example gen for
azure-native.
In short, this allows subtyping to correctly "propagate" through an Output;
if Cow is a subtype of Animal, this commit makes it so Output[Cow] is
treated as a subtype of Output[Animal].
Without this change, users of the Python SDK occasionally contend with a
confusing error message that is resolved by adding a call to
`.apply(lambda x: x)` to satisfy mypy.
Touches #3767.
Fix#6843.
* Allow non-pulumi imports for Node.js
Currently the code generator is assuming that Node.js dependencies are
following a naming scheme that is prefixed with `pulumi/`. If this is
not the case the generated import statement is incorrect.
This commit adds a map `ProviderNameToModuleName` to the language
definition that allows you to map the name of the extracted provider of
a dependency to a module name that the generator now uses to create the
import statement.
* Prepend "pulumi" to import names in Node.js SDK
It is common when writing multi-language components to have a module
name which conflicts with a provider name. This can produce unusable
code, since you cannot simultaneously import a package as `aws` and have
a namespace `aws`, for example.
This commit makes this situation much less likely, by renaming the
imported identifier for providers to `pulumiX` where it would
previously have been `x`.
This has an unfortunate side effect of making the examples in the
documentation slightly uglier, since import statements for third-party
packages are now of the form `import * as pulumiAws from "@pulumi/aws"`.
I don't see a way to discern whether code generation is for SDKs vs
examples however, and short of plumbing that through, I don't see a way
around this, so test expectations are updated accordingly.
Co-authored-by: Ben Schiborr <bschiborr@apple.com>
- Lazily produce conversion failure diagnostics. This lowers the
allocation volume and cuts down on execution time by avoiding the
conversion of source and dest types to strings.
- Add a fast path for union conversions that checks if the source type
is identical to any of the union's element types. Type equality
checks are generally much faster than type conversion checks.
These changes lead to a significant speedup in codegen time in
azure-native.
- Track which languages have been imported for a package. If a language
has already been imported, do not re-run its importers.
- Track which package contexts have been loaded in the Go code
generator, and do not reload a context that already exists.
These changes shave a profound amount of time off of codegen in
azure-native, speeding things up by a factor of 5.
When converting a `schema.InputType` to a `model.Type`, calculate the
resolved form of the type in the schema type system rather than the
model type system. The results are semantically identical, but the
number of type objects that are allocated is much smaller b/c
`model.NewOutputType` no longer allocates.
This deserves a little more explanation.
In order to prevent nested outputs and/or promises, `model.NewOutputType`
calculates the resolved form of its argument prior to allocating a new
`OutputType` value. Calculating the resolved form of the argument is a
no-op if the argument is already fully resolved. Therefore, passing in a
fully-resolved schema type prevents `model.NewOutputType` from
calulating the resolved form, and `model.NewOutputType` will only
allocate the `OutputType` itself instead of the `OutputType` and the
resolved form of any eventuals present in its argument.
This has a _very important_ knock-on benefit: the schema -> model type
translator ensures that given a `schema.Type` instance `T` it will
always return the same `model.Type` instance `U`. This termendously
speeds up type equality checks for complex types, as they will now be
referentially identical.
This change alone gives a significant speedup in azure-native code
generation.
This commit modifies the generation of `setup.py` to use Python
variables as the source for the package version and plugin version
instead of placeholder strings. This has the effect of making the
packages installable via the `-e` flag directly from their source
directory rather than requiring a build step, which is useful while
developing a plugin and examples in tandem.
This commit modifies Go program generation to prevent producing array
and slice object elements as pointers in args structures, which fails at
runtime and does not make sense in any case. For example, in the case of
a type defined like this in schema:
```json
"statements": {
"type": "array",
"items": {
"$ref": "/aws/v4.8.0/schema.json#/types/aws:iam/getPolicyDocumentStatement:getPolicyDocumentStatement"
}
},
```
The following (which fails at runtime) was produced before this change:
```go
Statements []*iam.GetPolicyDocumentStatement `pulumi:"statements"`
```
And the following is produced after after this change:
```go
Statements []iam.GetPolicyDocumentStatement `pulumi:"statements"`
```
Test expectations are updated accordingly.
This commit fixes code generation for intermediate module paths to
produce valid TypeScript identifiers.
Before this change, the following (non-compilable) import was produced
in `./jetstack/certmanager/acme`:
```
import * as jetstack/certmanager/acme/v1alpha2 from "./jetstack/certmanager/acme/v1alpha2";
```
After this change, the following import is produced:
```
import * as v1alpha2 from "./v1alpha2";
```
This example is repeated at each level of the module tree. Test
expectations are adjusted to reflect this change.
This commit modifies the Go code generator to use configured aliases for
the root package name of a Go module. This is useful when a version 2
package is present, as it prevents generation of identifiers such as
"v2" which were produced by the old logic.
These changes add support for unmarshaling and marshaling package
schemas using YAML instead of JSON. Language-specific data is
canonically JSON. Users of the `*Spec` types will need to update the
types of the the their `Language` values to use the new
`schema.RawMessage` type instead of `json.RawMessage`: the former has
support for YAML while the latter does not.
This fixes#7504, and is the other half of the interim fix corresponding
to #7359. The case listed in #7509 no longer reproduces after this fix
is applied.
The diff rendering logic tests whether the DetailedDiff is nil to determine whether to use it for rendering or defer to older older supported approaches to computing diffs.
The new logic added in https://github.com/pulumi/pulumi/pull/7226 could lead to replacing a nil DetailedDiff with an empty DetailedDiff, whcih would make the rendering logic believe that a DetailedDiff was present but empty, instead of missing entirely.
This change ensures that we maintain nil-ness of the DetailedDiff when we transform it for handling of replaceOnChanges.
Also adds tests for this and other cases on applyReplaceOnChanges.
Fixes#7486.
This commit adds a newline to the end of the package.json files
generated by Pulumi codegen, such that they can be installed in place
without modification.
