We're a bit inconsistent with naming for debugging, calling it enable
debugging in some places, attach debugger in others, and start debugger
yet in others.
Unify this, so we call everything that goes from the engine towards the
language host attach debugger, while the message we get back from the
language host is called start debugging since we're telling the engine
that we want to be starting the debugging session.
Thanks @julienp for the suggestion!
We want to introduce dubugging support for Pulumi programs. This PR
implements the engine changes necessary for that. Namely, we pass the
information whether we expect a debugger to be started to the language
runtime, and introduce a way for the language runtime plugins to report
to the engine that we're waiting for a debugger to attach. The language
runtime is expected to include the information relevant for the user to
be able to attach to the debugger, as well as a shortened message.
The idea is that the configuration can be picked up by an IDE, and the
debugger can attach automatically. Meanwhile the short message should
contain enough information to be able to attach a debugger manually,
while being short enough to be displayed to the user in the CLI output.
(this will commonly be either the port of the debugger, or the PID of
the process being debugged).
The implementation of the CLI flags and each of the language runtimes
will follow in subsequent PRs.
I tried adding a test to this, but I'm not sure it's possible with our
current testing infrastructure. To do this properly, we'd need to make a
RPC call to the engine, but we don't have that available in the
lifecycletests (? please let me know if I'm missing something). Once
more of the feature is implemented we might be able to implement an
integration test for it. (Not straightforward either, as we'll have to
tell the debugger to continue, but that should be more doable).
Another thing that's not clear to me is that @EronWright mentions this
could be used for MLC/provider debugging as well. However I'm not seeing
how that's going to work, as MLCs/providers are being run as a binary
plugin, which we don't compile from pulumi/pulumi, and thus wouldn't
necessarily even know which debugger to launch it under without a bunch
of additional configuration, that might be better in a shim around the
program (or just keeping the debugging the way we're currently doing,
launching the program and then letting the engine attach to it).
---------
Co-authored-by: Eron Wright <eron@pulumi.com>
Co-authored-by: Julien <julien@caffeine.lu>
* Make `async:true` the default for `invoke` calls (#3750)
* Switch away from native grpc impl. (#3728)
* Remove usage of the 'deasync' library from @pulumi/pulumi. (#3752)
* Only retry as long as we get unavailable back. Anything else continues. (#3769)
* Handle all errors for now. (#3781)
* Do not assume --yes was present when using pulumi in non-interactive mode (#3793)
* Upgrade all paths for sdk and pkg to v2
* Backport C# invoke classes and other recent gen changes (#4288)
Adjust C# generation
* Replace IDeployment with a sealed class (#4318)
Replace IDeployment with a sealed class
* .NET: default to args subtype rather than Args.Empty (#4320)
* Adding system namespace for Dotnet code gen
This is required for using Obsolute attributes for deprecations
```
Iam/InstanceProfile.cs(142,10): error CS0246: The type or namespace name 'ObsoleteAttribute' could not be found (are you missing a using directive or an assembly reference?) [/Users/stack72/code/go/src/github.com/pulumi/pulumi-aws/sdk/dotnet/Pulumi.Aws.csproj]
Iam/InstanceProfile.cs(142,10): error CS0246: The type or namespace name 'Obsolete' could not be found (are you missing a using directive or an assembly reference?) [/Users/stack72/code/go/src/github.com/pulumi/pulumi-aws/sdk/dotnet/Pulumi.Aws.csproj]
```
* Fix the nullability of config type properties in C# codegen (#4379)
These changes add two new methods to the provider interface and extend
the results of three others.
The new methods are `CheckConfig` and `DiffConfig`, which fill out the
set of methods required for a complete implementation of the
first-class provider design. Though these methods are optional for
backwards compatibility, they should be implemented by all future
providers for the best possible user experience.
The adjusted result types are `DiffResponse`, `ReadResponse`, and
`ErrorResourceInitFailed`. The first has been updated to include a list
of the properties that changed (if any). The latter two now include
an estimated set of inputs for the resource as well as the resource's
state. Together, these three changes enable the engine to determine the
set of inputs that should be specified by a user in order to match those
that describe the resource's current state.
This contributes to #2453, #1662, #1635, and #1718.
* Protobuf changes
* Move management of root resource state to engine
This commit fixes a persistent side-by-side issue in the NodeJS SDK by
moving the management of root resource state to the engine. Doing so
adds two new endpoints to the Engine gRPC service: 1) GetRootResource
and 2) SetRootResource, which get and set the root resource
respectively.
* Rebase against master, regenerate proto
* Use nightly protoc gRPC plugin for Node
Newer versions of the Node gRPC plugin accept the 'minimum_node_version'
flag, which we can use to instruct protoc to not support Node versions
earlier than Node 6. This allows the compiler to use 'Buffer.from'
instead of the deprecated 'Buffer' constructor, which fixes a
deprecation warning on Node 10.
* Protobuf changes
This change includes a lot more functionality. Enough to actually
run the webserver-py example through previews, updates, and destroys!
* Actually wire up the gRPC connections to the engine/monitor.
* Move the Node.js and Python generated Protobuf/gRPC files underneath
the actual SDK directories to simplify this generally. No more
copying during `make` and, in fact, this was required to give a smoother
experience with good packages/modules for the Python's SDK development.
* Build the Python egg during `make build`.
* Add support for program stacks. Just like with the Node.js runtime,
we will auto-parent any resources without explicit parents to a single
top-level resource component.
* Add support for component resource output properties.
* Add get_project() and get_stack() functions for retrieving the current
project and stack names.
* Properly use UNKNOWN sentinels.
* Add a set_outputs() function on Resource. This is defined by the
code-generator and allows custom logic for output property setting.
This is cleaner than the way we do this in Node.js, and gives us a
way to ensure that output properties are "real" properties, complete
with member documentation. This also gives us a hook to perform
name demangling, which the code-generator typically controls anyway.
* Add package dependencies to setuptools.py and requirements.txt.