https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# contribute
s
This message was deleted.
b
I'm most interested in the lower-level tfgen stuff for now, because that's the foundation that everything else will be built atop. I'd also really like feedback on how you imagine a Pulumi program being authored in a .NET Language. The current prototype uses CSI because I wanted to play around with it, but the experience there is untenable in the long term, I think. So understanding what a dotnet Pulumi program looks like would be interesting. Do we want a top level Pulumi.Run() that takes a Action/Func and you author your program in that callback? Do we want to say instead "You program must have a static method somewhere of this shape"? How do we want to communicate stack exports? Something that's returned from a hypothetical deploy function?
f
I agree that CSI is untenable. One of Pulumi's best features is that it blurs the line between the app and the infrastructure. Most people don't use CSI for their .NET apps
I think we should try to mimic the design-time experience from Entity Framework Core. See: https://docs.microsoft.com/en-us/ef/core/miscellaneous/cli/dbcontext-creation
TLDR: There's a well-known interface 
IDesignTimeDbContextFactory<T>
that you can implement to setup EF Core at design-time. If EF Core can't find a type that extends that interface, it will fallback to your app's dependency injection
As for stack exports... maybe the app's handler should be given some sort of object that it can use to export things? Maybe something as simple as:
Copy code
var service = new Pulumi.Azure.Service(
  "hello",
   replicas: 3,
);

pulumi.Export("endpoint", service.Endpoint.Apply(e => e.HostName));
@bitter-oil-46081 What do you think of this for .NET tfgen? https://github.com/loic-sharma/pulumi-aspnet
I tried to make this resemble EF Core's fluent APIs so that it feels familiar to .NET folks. We may want to have support for attributes too (though I personally don't like that as much)
An issue with my approach of using fluent APIs is that it does make it harder to determine which resource settings are required. That being said, I do think that complex stacks would be easier to configure using the fluent API. Food for thought 🙂
t
@bitter-oil-46081 The option with 
Pulumi.Run
- does it mean we won't use pulumi CLI? I think calling pulumi directly from code could be powerful, but isn't the workflow too different from what JS version does now?
b
@tall-librarian-49374 No. You would continue to use the CLI. The question is more around how does the language provider actually rendezvous with the actual program that you wrote and kick it off? For example, The Python and Node language hosts have small scripts that set things up and then jump into your script, in an idiomatic way: https://github.com/pulumi/pulumi/blob/master/sdk/nodejs/cmd/run/index.ts#L249-L272 https://github.com/pulumi/pulumi/blob/master/sdk/python/cmd/pulumi-language-python-exec Go, on the other hand has you explicitly call a 
pulumi.Run
export (https://github.com/pulumi/pulumi-aws/blob/master/examples/webserver-go/main.go#L14-L44), where it sets stuff up and then jumps into your callback. For C#, I could see either the contract you write an exe which we logically run, and then in your main you call something like: Pulumi.Run, or we say you expose a static method with this shape (or maybe marked with an attribute) and we do our setup and call that method.
t
Then I guess just exposing a function/interface implementation from C# dll makes most sense. Although, it's a minor detail if the workflow is the same.
a
I think the way that ASP.NET is doing it might be interesting, specifically in the OWIN space. There's an attribute that gets declared on the assembly itself, which is then resolved. It could also be an interface.
Open in Slack
PreviousNext
Powered by