You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PactMockServer exposes the wrapper around libpact_ffi in a XCFramework package. But the libpact_ffi binaries built from Rust code (https://github.com/pact-foundation/pact-reference/tree/master/rust/pact_ffi) contain binaries for simulators and physical devices. The problem is that all these binaries are static and include the rust runtime code for each of the platforms we're supporting (x86_64, aarm for both simulator and physical devices - so there's 4 copies of .a for each version). These binaries are huge! They hover at just over 100MB for each platform. That also means a lot of bandwidth is chewed up and long time to fetch PactSwift package onto dev's machines. It also uses up unnecessary disk space on developers' machines!
Although it's nice to not worry about running Pact tests on a specific target, it doesn't really make sense to run them on a physical device. It doesn't make much sense and it's rather hard finding where the Pact contract have been written to on a physical device and then trying to extract it.
We can consider just failing terribly when a developer tries to run Pact tests on a physical device, or "gracefully" fail the test with a meaningful message? Not fussed.
surpher/PactSwift allows developers to run tests on a physical device at the moment, but skips writing the Pact contract onto an iDevice's disk.
💡 Or maybe look into having PactSwiftMockServer package only contain the source files and can we leverage SPM Plugins to fetch libpact_ffi binaries separately from repo? This could also let us drop dealing with rust altogether as we could potentially spm-plugin-execute fetching a binary from pact-foundation/pact-reference that's already been built before we build xcframework to vend from PactSwiftMockServer.
The thing is that each update to libpact_ffi "baked" into the repo just explodes the size that each project pulls in.
For example, pact-foundation/pact-reference is releasing these binaries and hosting them on GitHub, but we'll need to improve their script generating the static libs to use the right triples we would need (eg: aarch64-apple-ios-sim, x86_64-apple-ios and aarch64-apple-darwin, x86_64-apple-darwin).
Another option to reduce the libpact_ffi size for macOS targets would be to share a dynamic lib? The released FFI libs pact-reference/rust offers are around 7MB in size.
But moving to a dynamic lib for macOS would mean developers would also need to install rust on their machines? This could prove as a big barrier to adoption of PactSwift.
Reach out to me (@surpher) and we can talk about all of the approaches I've thought up. There's been quite a few, and a few approaches I've already tried I am really not proud of!
💬 Task Description
Remove support to run on physical devices
Look for ways to not have to commit XCFrameworks and lib.as into repo - perhaps a SPM plugin that would fetch the prebuilt libpact_ffi.a from pact-foundation and insert it?
👩🔧 Technical Design Notes
🤝 Relationships
Other Related Issues:
The text was updated successfully, but these errors were encountered:
surpher
added
help wanted
Extra attention is needed
tech
Something technical that doesn't fit a feature or enhancement
hacktoberfest
A tag describing the issue or pull request is considered part of hacktoberfet
labels
Aug 2, 2023
As a first pass PactSwiftMockServer will be split into a thin package only sharing the PactSwiftMockServer.xcframework binary target and the rest will be moved into a PactSwiftMockServer-source where the interface and all is managed. CI will submit changes to xcframework to the repo PactSwift pulls in as a dependency.
Edit: main branch has been set up to pull in a new package PactSwiftServer that only hosts XCFramework binary. Much smaller.
❕ Problem Statement
PactMockServer exposes the wrapper around
libpact_ffi
in a XCFramework package. But the libpact_ffi binaries built from Rust code (https://github.com/pact-foundation/pact-reference/tree/master/rust/pact_ffi) contain binaries for simulators and physical devices. The problem is that all these binaries are static and include the rust runtime code for each of the platforms we're supporting (x86_64, aarm for both simulator and physical devices - so there's 4 copies of .a for each version). These binaries are huge! They hover at just over 100MB for each platform. That also means a lot of bandwidth is chewed up and long time to fetchPactSwift
package onto dev's machines. It also uses up unnecessary disk space on developers' machines!Although it's nice to not worry about running Pact tests on a specific target, it doesn't really make sense to run them on a physical device. It doesn't make much sense and it's rather hard finding where the Pact contract have been written to on a physical device and then trying to extract it.
We can consider just failing terribly when a developer tries to run Pact tests on a physical device, or "gracefully" fail the test with a meaningful message? Not fussed.
surpher/PactSwift
allows developers to run tests on a physical device at the moment, but skips writing the Pact contract onto an iDevice's disk.💡 Or maybe look into having
PactSwiftMockServer
package only contain the source files and can we leverage SPM Plugins to fetchlibpact_ffi
binaries separately from repo? This could also let us drop dealing withrust
altogether as we could potentially spm-plugin-execute fetching a binary from pact-foundation/pact-reference that's already been built before webuild xcframework
to vend fromPactSwiftMockServer
.The thing is that each update to
libpact_ffi
"baked" into the repo just explodes the size that each project pulls in.For example, pact-foundation/pact-reference is releasing these binaries and hosting them on GitHub, but we'll need to improve their script generating the static libs to use the right triples we would need (eg: aarch64-apple-ios-sim, x86_64-apple-ios and aarch64-apple-darwin, x86_64-apple-darwin).
Another option to reduce the
libpact_ffi
size for macOS targets would be to share a dynamic lib? The released FFI libs pact-reference/rust offers are around 7MB in size.But moving to a dynamic lib for macOS would mean developers would also need to install
rust
on their machines? This could prove as a big barrier to adoption of PactSwift.Reach out to me (@surpher) and we can talk about all of the approaches I've thought up. There's been quite a few, and a few approaches I've already tried I am really not proud of!
💬 Task Description
lib.a
s into repo - perhaps a SPM plugin that would fetch the prebuiltlibpact_ffi.a
from pact-foundation and insert it?👩🔧 Technical Design Notes
🤝 Relationships
The text was updated successfully, but these errors were encountered: