Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should the SDK be named csharp? #13

Open
pjmagee opened this issue Jun 5, 2024 · 2 comments
Open

Should the SDK be named csharp? #13

pjmagee opened this issue Jun 5, 2024 · 2 comments

Comments

@pjmagee
Copy link
Contributor

pjmagee commented Jun 5, 2024

Reason for this issue:

.NET SDK generally would mean support for any language on the .NET runtime

  • F#
  • C#
  • VisualBasic

Source Generators (Roslyn) is unique to C# but there does seem to be discussions within F# community on redirecting compilation from csc (C# compiler) and taking the IL to incorporate into F#.

fsharp/fslang-suggestions#864

@pjmagee
Copy link
Contributor Author

pjmagee commented Jun 5, 2024

Then comes the discussion around the new features of dagger functions and how does this look and feel? This will mostly be designed around .NET Attributes I would suppose but unsure how the DX would be for an F# developer.

It may be better to actually split and focus on a csharp named sdk, and if f# is popular, F# sdk should be made (which could still potentially have some benefits of any shared .net code) - One idea is that a

CSharp Project is used to generate the C# SDK from the source generator and a main F# project is used which pulls in those C# generated types.

This is supposedly what a lot of F# developers do. They do sometimes require C# Projects due to the popularity of C#.

@wingyplus
Copy link
Owner

wingyplus commented Jun 5, 2024

Yeah, this is my original goals that I hope this SDK would be.

I've try with F# recently at #14. The code is a bit ugly but its works. 🙈

My thought is we can write the SDK with C# and make language in the family (F#, PowerShell, etc.) calling this SDK. I'm not sure if we need a small wrapper to make DX better for the language. We can discover it after make C# works. :)

For the functions, I see 2 ways we can go:

  1. Allows user to configure language like Python that allows user to custom package manager (https://github.com/dagger/dagger/blob/main/sdk/python/runtime/main.go#L37). I didn't have time to looking into it but it's sound interesting.
  2. Separate module runtime per language. And find the way to build dagger module that centralize the logic.

However, we might need to write a module runtime library to load the code (C# method, F# function) to register module into the Dagger Engine (like Go main function does in dagger.gen.go) which looks like it depends on the language. I hope that we can play around with the Attribute somehow and sharing it across languages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants