Hi,
We are one last step away from explicit dependencies declaration.
Our issue is that we are using Realm. Per tuist recommendation we declared both “Realm” and “RealmSwift” as dependencies and this working correctly.
However, we also have an external SPM dependency that is using Realm.
To make it compile with our project we also added both Realm and RealmSwift to the dependencies.
This works correctly. However when we try to run the test target in the SPM dependency it doesn’t compile because per Realm recommendation we should only link either Realm or RealmSwift but not both.
So we are stuck between having correct tests in our SPM or having an app that compiles.
For now the workaround we have is modifying on the fly the Package.swift before running the tests but this is not ideal.
I also tried using #if TUIST inside the Package.swift in my SPM but with no luck.
@Philippe
Where can I read more about this? Are Realm and RealmSwift binaries pre-compiled? And if so, are they static or dynamic?
A small reproducible project would be very useful
Realm seems to support both dynamic and static building → https://www.mongodb.com/docs/atlas/device-sdks/sdk/swift/install/#-optional--build-realmswift-as-a-dynamic-framework
This is where they recommend to select either Realm or RealmSwift → https://www.mongodb.com/docs/atlas/device-sdks/sdk/swift/install/#select-the-package-products
I made a sample, the zip contains 3 projects:
app_with_realm
: Realm project directly taken from the tuist repo in the fixtures.
app_with_realm_spm
: A project that doesn’t compile. It has Realm as a direct dependency and a swift package that contains two targets:
One simple target with no dependencies.
A second target with the first target as dependency and also RealmSwift as a dependency.
The tests in the SPM can compile.
app_with_realm_spm_working
: A project that does compile. Everything is the same as the first one but the SPM’s second target depends both on RealmSwift and Realm.
The tests in the SPM don’t compile.
Here is the link to the archive with the 3 samples:
https://www.swisstransfer.com/d/942df02d-ed74-4c20-8203-1e6b49edb137
SPM not working with tuist
SPM working with tuist
Thanks for those examples @Philippe. When I try to install the dependencies in app_with_realm_spm
, I get the following error:
The 'swift' command exited with error code 1 and message:
Updating https://github.com/PhilippeWeidmann/SpmWithRealm.git
Updated https://github.com/PhilippeWeidmann/SpmWithRealm.git (0.35s)
Creating working copy for https://github.com/PhilippeWeidmann/SpmWithRealm.git
error: 'spmwithrealm': Couldn’t check out revision ‘491ae125879f2913eaf4a3f0054fba453fa06c79’:
fatal: reference is not a tree: 491ae125879f2913eaf4a3f0054fba453fa06c79
error: fatalError
Consider creating an issue using the following link: https://github.com/tuist/tuist/issues/new/choose
The revision 491ae125879f2913eaf4a3f0054fba453fa06c79
doesn’t seem to exist there. Would you mind taking a look at it?
Hey @Philippe
As you mention, developers shouldn’t have to depend on both RealmSwift
and Realm
. The need for that is a workaround due to discrepancy between SPM and Tuist behavior.
I agree this is a pain point and we shouldn’t assume developers will find the attached issue.
What I would suggest as next steps here is:
- Add
Realm
dependency when generating a project with a RealmSwift
external dependency when using the XcodeProj-based integration. This will 1) ensure developers don’t need to add this workaround themselves 2) fix your scenario as Realm
would only be added when generating a Tuist project and wouldn’t be present in the purely SPM-based graph. We already have some custom mapping for specific packages here, so we could expand it with extra logic for adding a dependency when Realm
is found.
- Or we investigate how our integration differs from SPM and why Tuist needs the extra dependency.
Clearly, it would be better to find out the underlying problem, but if we can’t do that, it might be a good idea to encode the workaround in Tuist for the time being.
1 Like
I agree, the first solution would remove the burden on the developer’s side.
It would be great to find the underlying issue but maybe it has something to do with the way the declare their Package. If this requires a fix on their side it might take some time for them to fix the issue, even more now that Realm is not supported by MongoDB.