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

Task: Find a way to reduce PactSwiftMockServer repo size #6

Open
surpher opened this issue May 11, 2023 · 0 comments
Open

Task: Find a way to reduce PactSwiftMockServer repo size #6

surpher opened this issue May 11, 2023 · 0 comments

Comments

@surpher
Copy link
Collaborator

surpher commented May 11, 2023

❕ Problem Statement

PactMockServer exposes the wrapper around libpact_ffi in a XCFramework package. But the libpact_ffi binaries build from Rust code (https://github.com/pact-foundation/pact-reference/tree/master/rust/pact_ffi) contains binaries for simulators and physical device. 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 each simulator and physical devices). These binaries are huge! They hover at just over 100MB of each. That also means a lot of bandwidth and long time to fetch PactSwift package. 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 since it doesn't make much sense trying to find where the Pact contract has been written to on the physical device and 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.

surpher/PactSwift allows developers to run tests on a physical device, but skips writing the Pact contract onto 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

  1. Remove support to run on physical devices.
  2. Look for ways to not have to commit XCFrameworks and lib.as into repo

👩‍🔧 Technical Design Notes

🤝 Relationships

  • Other Related Issues:
@surpher surpher changed the title Task: Create XCFramework of PactMockServer with only a subset of triples Task: Create XCFramework of PactMockServer with only a subset of static libs May 11, 2023
@surpher surpher changed the title Task: Create XCFramework of PactMockServer with only a subset of static libs Task: Create XCFramework of PactMockServer with only a subset of static libpact_ffis May 11, 2023
@surpher surpher changed the title Task: Create XCFramework of PactMockServer with only a subset of static libpact_ffis Task: Find a way to reduce PactSwiftMockServer repo size May 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant