* Work in progress, first passing tests
* Test unknown dep prop similar to Python
* Test fixes
* Fix lint
* Nit fix
* CHANGELOG
* Add ResourceInputArray and simplify the API
* Adopt urnSet
The underlying library `dill` that we use for serializing dynamic providers into Pulumi state for Python dynamic providers serializes classes differently depending on whether they are in `__main__` or in another module. We need the by-value serialization to be applied in all cases.
https://github.com/uqfoundation/dill/issues/424 is tracking adding the ability into `dill` to specify this by-value serialization explicitly, but until then, we will temporarily re-write the `__module__` of a provder class prior to serialization, so that `dill` behaves as we need for the dynamic provider use case.
Fixes#7453.
Implement Node/.NET-style dependency semantics for component resources.
Depending on a component implicitly depends on all of the component's
children. The exact set of children depends on exactly when the
component resource is observed.
Part of #7542.
Implement Node/.NET-style dependency semantics for component resources.
Depending on a component implicitly depends on all of the component's
children. The exact set of children depends on exactly when the
component resource is observed.
Part of #7542.
Do not return the inputs as the state for update previews that use an
unconfigured provider. Returning the inputs as the state allows the
language SDKs to incorrectly treat unknown properties as known (because
we can't call `Update` on an unconfigured provider, we can't know which
properties are unknown). Users can re-enable the existing behavior by
setting the `PULUMI_LEGACY_PROVIDER_PREVIEW` environment variable to a
truthy value (e.g. `1`, `true`, etc.).
Most users will be unaffected by these changes. The most common programs
that may be affected are those that combine the creation of a managed
Kubernetes cluster with the deployment of applications to that cluster. These
programs generally need to configure a k8s provider instance by constructing
a kubeconfig from the output of the managed k8s cluster. Any changes to the
cluster that cause the kubeconfig to be unknown then cause the provider to
go unconfigured at runtime. Prior to these changes, resources managed by the
k8s provider would have some known outputs in this scenario, as the engine
would treat the resource's input values as its output values. After these changes,
the resource's outputs will be treated as unknown. The most frequent affect
that this has is that applies/stack outputs that depend on the outputs of
a k8s resource managed by a provider with an unknown kubeconfig will not
run/be displayed as `output`s during previews, respectively.
We might be able to improve on this by taking advantage of schema
information and filling in unknown values for properties that do not
exist in the inputs.
Fixes#7521.
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
Co-authored-by: Luke Hoban <luke@pulumi.com>
Similar to #5282, but for core SDK types. The tl;dr is that because
Sequence[T] is covariant, constructing resources becomes much more
ergonomic.
Fix#7693.
These changes take a step towards simplifying and unifying the
generation of output types in the Go SDKs, especially for pointer,
array, and map outputs. This code was previously duplicated amongst the
various specialized output type generators, which led to inconsistencies
between the various implementaitons.
This is prep work for fixing #7595.
Fix `cloudSourceControlSSHRegex` so that it will match git remotes with periods or hyphens in the hostname. However, `azureSourceControlSSHRegex` _does_ match hostnames with a period. As a result, `TryGetVCSInfo` will treat these sorts of remotes as Azure source control remotes and drop the first group. This causes updates to have an incorrect `"vcs.kind"` field. For example, an update with a Git remote of `github.foo.acme.com` will have a `"vcs.kind"` field of `foo.acme.com`. This occurs if a user is using a self-hosted GH enterprise instance.
We can use the new `provider.MainWithOptions` to reduce boilerplate in some of our testcomponent providers.
Also, while cleaning up here, I took this as an opportunity to replace use of `github.com/pkg/errors` in the `tests` dir to use the built-in functionality of the Go standard library.
This commit adds a new counterpart to `ComponentMain` which accepts
an options struct for specifying callback functions. Currently it
supports `construct` (for components) and `call` (for methods), but is
extensible in a non-breaking fashion in future to support all other
provider methods as they become useful to implement.
The original `ComponentMain` still exists, though it may be desirable to
deprecate it in future in favor of `MainWithOptions`.
* Inputty depends_on support for Python
* Fix circular import
* Add a test, fix bugs found by test
* Fix typo
* Minimize loss of dep information in presence of unks to match Node behavior
* Add CHANGELOG entr
* Update sdk/python/lib/pulumi/output.py
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
* Update sdk/python/lib/test/test_resource.py
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
* Fix _is_prompt
* Enhance tests, found out a gap against Node impl
* Add non-listy case
* Internal functional combinators
* Do not use all/deep await when merging
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
* [backend/filestate] Allow `pulumi stack ls` to see all stacks regardless of passphrase
The information exposed via `pulumi stack ls` does not require being able to decrypt state files, but the existing logic for `pulumi stack ls` with the filestate backend was to fully decrypt the state file anyway, silently skipping any stacks that could not be decrypted. This led to surprising results from `pulumi stack ls`.
After these changes, `pulumi stack ls` with the filestate backend will list *all* stacks that are available. Notably, because there is no notion of "project" scoping in the fielstate backend (yet), `pulumi stack ls` will list all stacks independent of the project name.
Fixes#4798.
