search

Brightspace / rules_csharp

Bazel rules for C#
Apache License 2.0
8 stars 5 forks source link

Collaboration with rules_dotnet? #164

Open purkhusid opened 3 years ago

purkhusid commented 3 years ago

Have there been any previous conversations about merging the rules_dotnet effort and this one? I think it would be a tremendous gain for the already tiny . NET/Bazel community to combine these 2 rulesets. There are features that both rulesets can gain from each other and users of both rulesets could benefit from buildfile generators for example.

I'm not a maintainer of rules_dotnet so I can't speak with any authority but maybe @tomaszstrejczek can chime in?

j3parker commented 3 years ago

There haven't been any conversation so far. These rules started as an internal (to D2L) fork of rules_dotnet before it was rewritten. As it stands their APIs are quite different. I'll try to summarize things at a high-level as I see it:

The main things we need that I think were gaps with rules_dotnet:

The things that are a "priority" (we haven't worked on this much lately, but when we pick it up its our next steps) for us, some of this rules_dotnet has and some it doesn't:

Things that are not a priority for D2L (the owners of this repo) but we have no objections to/think are cool:

j3parker commented 3 years ago

So -- we would be happy to collaborate in any way that works. We've made this code open source on GitHub (under a permissive license) partly so that it's available to be copied from. My impression is that both sets of rules are a bit far from feature complete (especially this repo).

I would recommend people use rules_dotnet if it works for them. If, in the future, we could delete this repo and use rules_dotnet for our codebase we will. Our current plans are to expand these rules until they are relatively feature complete, in step with usage of the rules in our internal code base. We have specific (if not terribly unique) needs and at this point we think having these separate rules is working best for us.

We're also happy to take external contributions if people find these rules fit their use-cases better.

purkhusid commented 3 years ago

Ok, it sounds then like these rules are still very much a work in progress? It might then be premature to combine the efforts but I think once these rules have run and test working properly it might be a good time to look into this.

E.g. I contributed the F# support to rules_dotnet and it could pretty much use 95% of the .Net plumbing that existed there since the only step that is different is the compilation task.

It's also on my radar to look into .fsproj/.csproj generation from the Bazel targets and generation of 3rdparty Bazel targets via Paket(https://fsprojects.github.io/Paket/) since it can generate a lockfile which fits well with Bazel's determinism.

I would love for these efforts to benefit as many .Net/Bazel users as possible since we are very few at the moment. But I really do think that Bazel can be a huge benefit for shops with large .Net codebases.

j3parker commented 3 years ago

Ok, it sounds then like these rules are still very much a work in progress? It might then be premature to combine the efforts but I think once these rules have run and test working properly it might be a good time to look into this.

Absolutely. We (D2L) use them, and I think at least one other org uses them (Selenium), but only in a limited capacity.

I'll update our README today to make sure that it's clear that people should check rules_dotnet first.

E.g. I contributed the F# support to rules_dotnet and it could pretty much use 95% of the .Net plumbing that existed there since the only step that is different is the compilation task.

Neat!

It's also on my radar to look into .fsproj/.csproj generation from the Bazel targets and generation of 3rdparty Bazel targets via Paket(https://fsprojects.github.io/Paket/) since it can generate a lockfile which fits well with Bazel's determinism.

Cool! Check out the docs for aspects. I haven't used it personally, but the idea is to teach Bazel how to generate things like IDE files from targets (aside: this is partly why having csharp_library support multi-targeting is important to us; it makes the targets one-to-one which probably makes this simpler).

A related thing is going the other way: generating BUILD files from csproj. We do this because we're not (even close to) ready to have our BUILD files be "the source of truth". We have a .NET library for constructing and serializing Starlark (with idiomatic formatting) but it's currently very coupled to our internal build system. Having the core part of that (the Starlark library and the conversion from csproj to Starlark) could be really helpful for people. I think rules_dotnet has this but only for NuGet/WORKSPACE.

I would love for these efforts to benefit as many .Net/Bazel users as possible since we are very few at the moment. But I really do think that Bazel can be a huge benefit for shops with large .Net codebases.

Yeah, I agree. 😄