pulumi/sdk/dotnet
Fraser Waters 1d215c2c0c
Move InstallDependencies to the language plugin (#9294)
* Move InstallDependencies to the language plugin

This changes `pulumi new` and `pulumi up <template>` to invoke the language plugin to install dependencies, rather than having the code to install dependencies hardcoded into the cli itself.

This does not change the way policypacks or plugin dependencies are installed. In theory we can make pretty much the same change to just invoke the language plugin, but baby steps we don't need to make that change at the same time as this.

We used to feed the result of these install commands (dotnet build, npm install, etc) directly through to the CLI stdout/stderr. To mostly maintain that behaviour the InstallDependencies gRCP method streams back bytes to be written to stdout/stderr, those bytes are either read from pipes or a pty that we run the install commands with. The use of a pty is controlled by the global colorisation option in the cli.

An alternative designs was to use the Engine interface to Log the results of install commands. This renders very differently to just writing directly to the standard outputs and I don't think would support control codes so well.

The design as is means that `npm install` for example is still able to display a progress bar and colors even though we're running it in a separate process and streaming its output back via gRPC.

The only "oddity" I feel that's fallen out of this work is that InstallDependencies for python used to overwrite the virtualenv runtime option. It looks like this was because our templates don't bother setting that. Because InstallDependencies doesn't have the project file, and at any rate will be used for policy pack projects in the future, I've moved that logic into `pulumi new` when it mutates the other project file settings. I think we should at some point cleanup so the templates correctly indicate to use a venv, or maybe change python to assume a virtual env of "venv" if none is given?

* Just warn if pty fails to open

* Add tests and return real tty files

* Add to CHANGELOG

* lint

* format

* Test strings

* Log pty opening for trace debugging

* s/Hack/Workaround

* Use termios

* Tweak terminal test

* lint

* Fix windows build
2022-04-03 15:54:59 +01:00
..
Pulumi fix: #8994 (#9058) 2022-03-22 11:46:20 +01:00
Pulumi.Automation Add color option to stack up, preview, destroy, and refresh for automation api (#8811) 2022-01-24 23:34:22 +01:00
Pulumi.Automation.Tests ci: radical idea - what if slow tests & no stdout makes GH consider runner dead? 2022-03-06 14:52:13 -08:00
Pulumi.FSharp Enable deterministic builds 2021-04-29 14:24:43 +12:00
Pulumi.Tests [sdk/dotnet] Normalize provider providers merge (#8838) 2022-01-31 12:44:31 +01:00
cmd/pulumi-language-dotnet Move InstallDependencies to the language plugin (#9294) 2022-04-03 15:54:59 +01:00
.editorconfig Add **preview** .NET Core support for pulumi. (#3399) 2019-10-25 16:59:50 -07:00
.gitignore [Automation API] - C# Implementation (#5761) 2021-02-18 11:36:21 +01:00
Makefile Makefiles are very whitespace sensitive (#9301) 2022-03-26 09:00:21 +00:00
README.md Avoid overriding dotnet proj settings accidentally (#6670) 2021-04-01 15:27:24 -04:00
dotnet.sln [Automation API] - C# Implementation (#5761) 2021-02-18 11:36:21 +01:00
dotnet.sln.DotSettings [dotnet] Fix Resharper code issues (#7178) 2021-06-10 10:32:33 -04:00
pulumi_logo_64x64.png Fixing up Pulumi logo in dotnet package 2021-04-21 18:45:21 +01:00

README.md

.NET Language Provider

A .NET language provider for Pulumi.

Building and Running

To build, you'll want to install the .NET Core 3.0 SDK or greater, and ensure dotnet is on your path. Once that it does, running make in either the root directory or the sdk/dotnet directory will build and install the language plugin.

Once this is done you can write a Pulumi app written on top of .NET. You can find many examples showing how this can be done with C#, F#, or VB. Your application will need to reference the Pulumi NuGet package or the Pulumi.dll built above.

Here's a simple example of a Pulumi app written in C# that creates some simple AWS resources:

// Copyright 2016-2019, Pulumi Corporation

using System.Collections.Generic;
using System.Threading.Tasks;
using Pulumi;
using Pulumi.Aws.S3;

class Program
{
    static Task<int> Main()
        => Deployment.RunAsync(() =>
        {
            var config = new Config("hello-dotnet");
            var name = config.Require("name");

            // Create the bucket, and make it public.
            var bucket = new Bucket(name, new BucketArgs { Acl = "public-read" });

            // Add some content.
            var content = new BucketObject($"{name}-content", new BucketObjectArgs
            {
                Acl = "public-read",
                Bucket = bucket.Id,
                ContentType = "text/plain; charset=utf8",
                Key = "hello.txt",
                Source = new StringAsset("Made with ❤, Pulumi, and .NET"),
            });

            // Return some values that will become the Outputs of the stack.
            return new Dictionary<string, object>
            {
                { "hello", "world" },
                { "bucket-id", bucket.Id },
                { "content-id", content.Id },
                { "object-url", Output.Format($"http://{bucket.BucketDomainName}/{content.Key}") },
            };
        });
}

Make a Pulumi.yaml file:

$ cat Pulumi.yaml

name: hello-dotnet
runtime: dotnet

Then, configure it:

$ pulumi stack init hello-dotnet
$ pulumi config set name hello-dotnet
$ pulumi config set aws:region us-west-2

And finally, preview and update as you would any other Pulumi project.

Public API Changes

When making changes to the code you may get the following compilation error:

error RS0016: Symbol XYZ' is not part of the declared API.

This indicates a change in public API. If you are developing a change and this is intentional, add the new API elements to PublicAPI.Unshipped.txt corresponding to your project (some IDEs will do this automatically for you, but manual additions are fine as well).

Project maintainers will move API elements from PublicAPI.Unshipped.txt to PublicAPI.Shipped.txt when cutting a release.