Create directory for Binding Tools For Swift #97208
Conversation
kotlarmilos
requested review from
dalexsoto,
marek-safar,
jkotas,
vitek-karas,
stephen-hawley and
AaronRobinsonMSFT
|
Tagging subscribers to this area: @dotnet/area-meta Issue DetailsDescriptionThis PR creates a directory for the Swift projection tooling. The components are currently undergoing iterative reviews and will be moved from https://github.com/xamarin/binding-tools-for-swift.
|
|
I think that the high-level Swift binding tools should live in its own repo. If we want to add them to an existing repo, it should be xamarin-macios where other Apple-specific high-level binding tools live. All other similar tools are in their own repos: CsWinRT, CsWin32, xamarin-macios, Android, .... . Each of them is a fairly large projects and I do not think we would want to add all of them to dotnet/runtime repo. We aim at treating all of these high-level binding tools the same. cc @dotnet/interop-contrib |
Agree.
Not sure this is where I would go. The Swift language is supported on non-macOS platforms and I think it would be a mistake to keep them in a macOS repo. |
xamarin-macios is a home for Objective C binding tools for .NET. Objective C is in a similar boat as Swift wrt. non-Apple platforms support. |
If Swift tooling is integrated into the .NET SDK, it would be logical to place it in SDK related repos. Also our current trajectory involves streamlining repositories rather than proliferating new ones. |
|
Do you consider the current xamarin-macios to be SDK related repo? |
|
Are we planning to use the binding tools to create test cases to validate that the runtime functionality is working properly? In that case, having the tool in a separate repo might make the devloop somewhat unpleasant - at least while both the runtime support and the binding tool are evolving |
|
I would tend to agree with @jkotas and @AaronRobinsonMSFT here. I don't think dotnet/runtime is the right place for this tooling and a repo like xamarin-macios. I wouldn't expect this tooling to ship by default in the .NET SDK, nor do I think the runtime repo's current infrastructure is well suited for the types of tests we'd want to write for this tooling, especially if we're generating Swift code. My experience with the Wasm.Build.Tests testing in this repo has kinda soured my thoughts on this as every time we have to make large SDK changes, WBT is the long tail keeping us behind for weeks.
I would expect that we wouldn't use the binding tools to validate the runtime functionality. The runtime functionality should be validated with manually written low-level tests. Especially with how much we're pushing up into the binding tooling, I don't think relying on the binding tooling working to validate the calling convention work is a good idea. |
Not really because it's built on top of .NET SDK
How do you expect to ship the interop tooling for Swift? |
My one concern with this is that manually written tests are usually not as creative as tool-written code. Computers are really good at writing bad code. If we don't want the tool in the runtime repo, and if we don't even want to take a dependency on it, we should at least check in some generated stress tests (and a script to re-generate them). |
Same way as we are shipping the current Objective C interop tooling, include it in the Apple-specific workload. |
Just so I understand this full. Are you saying that anyone that would like use Swift tooling on macOS will need to install |
The Swift interop support is scoped to Apple platforms currently. If there is a good reason to, we can do the extra work to enable the Swift interop support on non-Apple platforms later. It is low priority. We can author the Swift binding tools as a package that is included in or referenced by the workload, so that it is possible to use it without the workload too. |
My two cents: a separate repo (in the dotnet org). It's unrelated to any other code in xamarin-macios (and neither would depend on the other), and would also potentially have its own release schedules, so IMHO it makes most sense to be a separate repository. |
|
We should consider this from the user's perspective. As a user, I would expect it to be part of the SDK, similar to how Swift handles C++ interop, with just namespace imports, or alternatively as a separate workload. Having it within the .NET SDK introduces complexity in testing and doesn't follow the existing interop pattern that is implemented on top of the .NET SDK. Adding it to the existing repository like Based on feedback, it seems we should create a separate repository with its own release schedule. This does add compliance and testing overhead and introduces more work in terms of shipping, but it is aligned with the existing pattern for bindings and allows for faster iterations and evolution. The only concern with this approach is the potential burden on users who need to install another workload. One potential solution could be to include it in the .NET SDK when targeting Apple platforms and providing an option for explicit workload installation. |
I think there are two use cases:
|
|
After creating a new repository and discussing with the .NET Engineering team, we have decided to proceed with the Here is the reasoning behind the decision. Our initial focus is on the CryptoKit library, and we want a tool that we will use within the runtime repository. This tool doesn't need to be a part of the workload at this stage, and it will be considered as nice to have for the first deliverable. We intend to publish this tool as a package, and there is already a Darc flow in This decision doesn't rule out the possibility of moving to the new repository at a later stage, but for now, our priority is to iterate quickly and avoid investing significant time in servicing and maintenance at this stage. |
|
After discussing with the Xamarin team, it appears that Unless there is a dedicated dotnet tooling repository, it seems that we have two options: the new repository or runtime repository. The new repository demands a significant amount of initial work but offers a clear separation and could potentially serve as a good long-term solution. On the other hand, the runtime repository can serve as a "temporary" repository for the initial version + it provides infrastructure for shipping. Additionally, it will enable us to have discussions with stakeholders and .NET Engineering/Servicing teams while simultaneously working on the first version. |
|
@kotlarmilos Can we try dotnet/runtimelab? That is something we can easily migrate to dotnet/runtime if an official repo becomes acute or we can take our time with an established "temporary" repo. I think pushing this into the runtime repo is likely to be of a collaborative bottleneck with the current CI and PR policy in dotnet/runtime. |
|
I would highly recommend using a standalone experiment in dotnet/runtimelab if setting up the policies for a new repository is too expensive. |
When they expect to be done with this migration?
dotnet/runtime repository is by far the largest repository in the .NET product. It is not a good place for "temporary" stuff. (It is one of the reasons why we have created runtimelab - to avoid adding additional load onto dotnet/runtime.)
I agree that the runtimelab is a good place if you are looking for a temporary place to work. |
Thanks for your feedback. The
Xamarin support will end on May 1, 2024, so I believe it will happen a couple of weeks before the deadline. I will close this PR and initiate further discussions with the Xamarin and .NET Engineering teams regarding the long-term lifecycle of the tooling. |
Description
This PR creates a directory for the Swift projection tooling. The components are currently undergoing iterative reviews and will be moved from https://github.com/xamarin/binding-tools-for-swift.
Discussion: dotnet/designs#312 (comment)