Closed jeffremer closed 8 months ago
I would be interested in taking a whack at this bug, but any hints as to where to get started would be appreciated.
Most of the logic for this is in:
Package.swift
from Dependencies.swift
and invokes swift package resolve
swift package dump-package
and passes them to PackageInfoMapperAny progress on this? It makes us to tuist clean
every time on CI to avoid problems and that means caching doesn't make any sense.
Any progress on this? It makes us to tuist clean every time on CI to avoid problems and that means caching doesn't make any sense.
Running tuist clean dependencies
doesn't clean the cache artifacts, so you can still utilise caching. @jeffremer it could be interesting to compare this with the behavior of a raw SPM package by creating a dummy Package.swift
, run swift build
, remove the binary dependency, and run swift build
. I'd assume the resolution might fail in this case, too – if so, then this might be a bug in SPM, not in tuist.
tuist install
(formerly tuist fetch
) has been greatly simplified, so this no longer should be an issue. Feel free to reopen if you're still running into this.
What happened?
If you add an SPM package with binary artifacts to
Tuist/Dependencies.swift
then later remove it, subsequent calls totuist fetch
fail with an error along the lines of the following, even if the missing artifact is not referenced inTuist/Dependencies.swift
.The error is along the lines of this, but the exact package will vary…
You must run
tuist clean dependencies
to allowtuist fetch
to then run successfully.While inspecting the
SwiftPackageManager/.build
directory I can see that when runningtuist fetch
after the package with binary artifacts is removed fromTuist/Dependencies.swift
that the directories for those artifacts are in place but it appears thattuist fetch
cleans out the xcframeworks underneath each target.We currently have a somewhat naive wrapper around
tuist
so that developers and CI machines need only run the wrapper to bothtuist fetch
andtuist generate
(as well as some unrelated things such as Cocoapods…).I know we are calling
tuist fetch
too often and I have a plan to mitigate that, but regardless, this still feels like a bug -tuist fetch
shouldn't fail simply because a dependency was removed. I didn't first encounter this by removing, adding, and then removing a dependency - instead I found this issue in CI where we.gitignore
everything underTuist/Dependencies
except for theLockfiles
. This means that between CI runs the result oftuist fetch
between builds is left in place on disk. I had added the Firebase SDK on a branch, my branch was run in CI, then later builds on those same machines encountered this error.How do we reproduce it?
tuist fetch
to fetch the existingFMDB
package - see it succeedTuist/Dependencies.swift
tuist fetch
- see it succeed and now you have FMDB and FirebaseTuist/Dependencies.swift
and comment out the Firebase packagetuist fetch
Expected: the final
tuist fetch
should succeed Actual: the finaltuist fetch
fails with message like the belowError log
Attached is the output of the final
tuist fetch --verbose
call - fetch.logHere is the terse version…
macOS version
13.4.1
Tuist version
3.20.0
Xcode version
14.3.1