There's lots of moving parts though. I've tried to document them and set up scripts to automate most of things: •

surpher/PactSwift

is the main interface that's aiming to remove pact business logic but only act as a Swift interface •

surpher/PactSwiftMockServer

is the wrapper around

lib_pactffi

(and should delegate most/all the business logic to lib.a`. This is the working repo that does the implementation •

surpher/PactSwiftServer

is vending XCFramework binary avoiding maaaasssive repo. This is the "shareable" repo that vends the compiled results of

PactSwiftMockServer

•

surpher/PactMockServer

delivers module.modulemap to bridge Rust -> Swift

Some of these names are, at least to me, not entirely obvious. For example from

PactSwiftMockServer

, I would not have guessed that it is a wrapper about Pact FFI 😅

well, you can rename it when it's in your hands 🙂 It was an evolution of requirements and everchanging Swift/Apple ecosystem

In your opinion, would there be much of a benefit from having a bit of a monorepo structure? I did this for example with Pact Python. The repo has

pact-python

,

pact-python-ffi

and

pact-python-cli

it was a monorepo, but it quickly blew up to Gigs and Gigs of repo to download on each CI pull

ah, yeah ok... I'm not familiar with what gets pulled in within the Swift ecosystem

the actual interface was maybe a couple of files, but the binaries that need to include rust runtime so it can run on an iOS device or on a system that doesn't install rust so dylibs could be used, each binary version was more than 150MB, now split that to platforms, that ended up adding another ~600MB of history to the repo on each release 🎉

You're saying that the binaries were being incorporated into the Git history?

yup, at the time SPM didn't do the plugins yet, where it could download a hosted binary

oh wow... that's a glaring feature gap from SPM 😆

and only when XCFrameworks were introduced, that was able to shed a lot of binary crap

You don't want to maintain it after it moves into the Pact Foundation?

I haven't touched it in a year, but I'm not against continuing to be the main maintainer of it

I believe if you use GitHub's 'transfer owner' feature, GitHub will automatically redirect? At least, I know it does that if you rename your default branch (I did that going from

master

to

main

in Pact Python)

not sure, just pointing it out

But you're right, if there's no redirect, then you'll need to have repos on your side informing people of the redirect.

not a problem, can even push in a logger warning telling them to make the switch

fair enough. It's also possible to put a notice up that, while there's someone who can review PRs, we're looking for someone to take ownership

there was very little contribution from outside so I'm not worried if you'd want me to remain the PR reviewer and worry about architecture. Just can't put as much time as I used to to jump on new features. I've set up scripts to release new wrappers when Ron pushes out new libpact_ffis but then updating/introducing new features is a bit of an ask right now.

Perhaps we should get up an issue on the project to see if anybody is interested in becoming the maintainer?