CLI for removing carthage cache?

[jessesquires]

I've run into a few bugs (and I've had a few bugs reported on my projects) that were resolved by deleting the carthage cache (rm -rf ~/Library/Caches/org.carthage.CarthageKit) and running a fresh carthage update.

I think it would be convenient to have a CLI for this, perhaps carthage clean, that would be responsible for clearing the cache, cleaning up any artifacts and rebuilding frameworks.

Thoughts?

[jspahrsummers]

This sort of suggestion has come up before—most recently in #427 (although the intent there is slightly different).

I guess my initial reaction is: if the Carthage cache has to be cleaned, that probably is a Carthage bug, and we should fix that rather than offer a hacky workaround that we expect users to try.

Do you have examples of where purging the cache helped?

[jessesquires]

Yeah, theses are the 2 most recent and well-documented:

• Carthage build failing, unknown error #436
• Carthage builds ExampleModel.framework jessesquires/JSQCoreDataKit#13

[jspahrsummers]

Sorry about the delay, and thanks for the examples!

I'd still like to avoid a clean command, but this is good motivation to make the cache transient or something instead, to reduce occurrences of problems like this.

[ryanbaldwin]

Actually, I think I just found a valid reason for being able to manually clean the carthage cache: cached binaries and different Swift versions.

I'm playing around in Xcode 9 Beta, and thus using the new Swift 3.2/Swift 4 switching. I have a couple carthage binaries that were compiled in Swift 3.1, which is a version not supported by the Swift compiler in Xcode 9 (it has to be compiled by Swift 3.1 at a minimum). Would be great if either

• I had the ability to clean all or individual binaries, or
• The cache took into account the version of Swift being used to build the framework.

Thoughts?

Also - I just noticed this was closed on May 14th 2015. Whoops. Sorry J.

[rae]

The linked issue was closed due to inactivity. See the 15👍🏻 on above comment. This is a big pain point.

[andersio]

0.24 and 0.25 have considerably improved on this front. If you have encountered any circumstance that doesn't feel right, perhaps consider filing a separate issue with the details?

[rockshassa]

Can confirm this is still a big pain point.
Encountered this issue when building SocketIO on a machine that hosts two Xcode versions (8.3.2 and 9)
After building SocketIO in swift 4 on Xcode9, subsequent builds that depend on Xcode8 and Swift 3.2 will fail with an error
"SocketEngine.swift:27:8: error: module compiled with Swift 4.0 cannot be imported in Swift 3.1:"

I am going to have to add some handling to nuke the carthage cache before each build. from my perspective, a clean function would be nice, or ideally you'd have some logic inside carthage to detect this situation and invalidate appropriately.

[chrisballinger]

FWIW I've had an issue where carthage update/bootstrap wasn't changing to a new remote (changed the user for a github source to point to my own fork), and the only solution was to manually clear the cache. (running 0.26.2) Took a while to figure out why it wasn't working because deleting the Carthage checkouts in my project folder wasn't cutting it.

[az-oolloow]

On my mac this Cache derived data folder grew to circa 30 GB. It would be good if there was a supported way to reclaim some of that space back.