Commit Graph

11 Commits

Author SHA1 Message Date
Thomas Gummerer 531146678e
debugging: more consistency for naming ()
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!
2024-09-04 10:36:45 +00:00
Thomas Gummerer d51c0bdd87
implement the engine bits for debugging support ()
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>
2024-08-30 10:31:28 +00:00
Fraser Waters 1beb4f827e
Compile protobufs with "pulumi" namespace ()
* Move proto file to top level

* Regenerate go protobufs

* Regenerate python protobufs

* Fix dotnet protobuf references

* Update README

* Fix up nodejs protobufs

* Add to CHANGELOG

* lint

* Remove google/protobuf/status

* Revert server changes

* Restore pyi files

* Revert "Remove google/protobuf/status" for nodejs

This reverts commit d692f00bd2.
2022-07-12 14:45:03 +01:00
CyrusNajmabadi 66bd3f4aa8
Breaking changes due to Feature 2.0 work
* Make `async:true` the default for `invoke` calls ()

* Switch away from native grpc impl. ()

* Remove usage of the 'deasync' library from @pulumi/pulumi. ()

* Only retry as long as we get unavailable back.  Anything else continues. ()

* Handle all errors for now. ()


* Do not assume --yes was present when using pulumi in non-interactive mode ()

* Upgrade all paths for sdk and pkg to v2

* Backport C# invoke classes and other recent gen changes ()

Adjust C# generation

* Replace IDeployment with a sealed class ()

Replace IDeployment with a sealed class

* .NET: default to args subtype rather than Args.Empty ()

* 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 ()
2020-04-14 09:30:25 +01:00
James Nugent a1b55192dd Regenerate protocol buffers code 2020-02-28 11:53:47 +00:00
Pat Gavlin 905e7353e4
Update the provider RPC interface ()
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 , , , and .
2019-03-05 10:49:24 -08:00
Sean Gillespie 2d4a3f7a6a
Move management of root resource state to engine ()
* 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
2018-09-18 11:47:34 -07:00
Sean Gillespie f284112b4e
Use nightly protoc gRPC plugin for node ()
* 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
2018-09-17 15:16:31 -07:00
Sean Gillespie c2b2f3b117
Initial Python 3 port of the Python SDK ()
* Machine-assisted Python 3 port

* Hack around protoc python imports

* Regenerate gRPC and protobuf

* CR: Bash code cleanup
2018-06-26 11:14:03 -07:00
Pat Gavlin a23b10a9bf
Update the copyright end date to 2018. ()
Just what it says on the tin.
2018-03-21 12:43:21 -07:00
joeduffy a045e2fb1e Implement more of the Python runtime
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.
2018-02-24 08:58:34 -08:00