search

pact-foundation / pact-net

.NET version of Pact. Enables consumer driven contract testing, providing a mock service and DSL for the consumer project, and interaction playback and verification for the service provider project.
https://pact.io
MIT License
842 stars 231 forks source link

RFC: Add linux-musl-x64 Runtime Support #496

Open botondbotos opened 5 months ago

botondbotos commented 5 months ago

Previous issues Add linux-musl-x64 Runtime Support

Is your feature request related to a problem? Please describe. According to Compatibility / Operating System page Linux (musl) is not supported, however starting with Pact FFI Library 0.4.17 the libpact_ffi-linux-aarch64-musl.so and libpact_ffi-linux-x86_64-musl.so shared libraries are part of releases.

Describe the solution you'd like Update pact-net to use latest Pact FFI Library 0.4.19 which has the libpact_ffi shared libraries and extend the NuGet package with additional runtime targets.

Breaking Changes No

Potential Downsides/Caveats n/a

Describe alternatives you've considered n/a

Additional context After replacing the runtimes/linux-x64/native/libpact_ffi.so file added by PactNet 5.0.0-beta.2 package with libpact_ffi-linux-x86_64-musl.so I was able to successfully run pact-net tests inside Docker using mcr.microsoft.com/dotnet/sdk:6.0.421-alpine3.19-amd64

adamrodger commented 4 months ago

Currently there is no reliable way to detect libc vs musl during a .Net restore operation and therefore no reliable way to ensure the correct libpact binary is restored. That makes this issue currently infeasible until a reliable way of doing that detection is found.

botondbotos commented 4 months ago

Could you please help me understand why it is preferred to restore the correct pact_ffi package over picking the correct one at runtime? I have a PoC implemented, which is addressing the issue of musl support: https://github.com/pact-foundation/pact-net/pull/497#issuecomment-2087340260 One of the drawbacks is that all native packages need to be deployed, but the runtime can pick the correct one.

adamrodger commented 4 months ago

That's the design of the FFI packaging, so that the correct binary is restored to the bin folder when the NuGet is installed. That means we're leaning on existing features provided in MSBuild instead of rolling our own detection code, which is bound to be worse.

I'm not sure how runtime vs restore time is a distinction here anyway? Either way there's no reliable way to detect libc vs musl, because if there was you could use it with either style. Both call in to .Net APIs to determine the OS/arch currently, but there's no API to determine libc vs musl.

I can understand why that is also - .Net itself doesn't need to worry about that because your code is all IL and it's the installed runtime that matters. Given we're doing native interop though then it does matter to us, so the missing API matters.