Cache failing to resolve dependencies with name collision

[regexident]

Carthage keeps a cache of fetched dependencies in ~/Library/Caches/org.carthage.CarthageKit/dependencies/….

Assuming you have a project with this in its Cartfile:

github "antitypical/Result"

And another project with this:

github "somebody/Result"

Then due to not using any further subdirectories for antitypical or somebody carthage ends up fetching the wrong dependency from the local cache for the second project being bootstrapped.

This pretty much defeats the whole point of supporting namespacing in the first place. 😢

[mdiep]

Projects aren't namespaced by owner. antitypical/Result and somebody/Result are treated as forks of the same dependency. This is a feature so that if you, e.g., depend on ReactiveCocoa/ReactiveCocoa but want to use mdiep/ReactiveSwift, you can do so.

[regexident]

I'd argue that that's not how Carthage's "namespaces" are used though.

And from my understanding this also breaks with forks.

Let's say you have two independent projects (A, B), which both make use of Result.

Let's further say somefork/Result is a fork of antitypical/Result, which split at version 1.x.
Over time both projects diverge in development leading to two rather different versions of 2.x.

Project A depends on antitypical/Result ~> 1.x and B on somefork/Result ~> 1.x.
Time comes and project A migrates to antitypical/Result ~> 2.x while Project B migrates to somefork/Result ~> 2.x (or any other backwards-incompatible version change).

This is totally fine from an isolated point of view, but breaks Carthage if you're doing development for both on the same machine. 💥

[mdiep]

But if both create Result.framework, this won't work anyway.

That all sounds like correct, desirable behavior to me.

[regexident]

Projects A and B share nothing in common. Other than a dependency with the same name, that happen to be forks (or not).

Let's say you're consultant/freelancer or working in an agency and at one time happen to work for two companies: for company A on project A and company B on project B. They both happen to use dependencies that share the same name (and could be forks of each other, but not necessarily so). You certainly won't make either of them change their deps just because you, one of possible hundreds of devs happen to also be working on a project that uses a conflicting dependency somewhere else, but on the same dev machine.

[mdiep]

Ohhhh… I misunderstood your issue. This is specifically about Carthage's shared cache for 2 dependencies with the same name in completely separate projects. That's something we should fix.

[regexident]

Yes, exactly. 🙂

Sorry if I didn't make myself clear enough. 🙈

[mcfedr]

Having lots of issues with this on our CI server, when devs are using forks of the same dependences. Carthage doesnt seem to change the remote in the cache once it exists.

[sjmadsen]

I wonder if this isn't the source of a problem I noticed last week.

Internally, we have several frameworks that an app depends upon. I needed to make changes to one of them for a bug fix, but in order to test the fix, I had to temporarily point the app's Cartfile at the file:/// URL of my local framework clone. Carthage was unable to find the updated develop commits in that local clone during carthage update until I deleted the cached repository in ~/Library/Caches/org.carthage.CarthageKit/dependencies.

In this case, because of the matching name, Carthage didn't check "upstream" from its cache, even though it was out of date.

[mcfedr]

@sjmadsen That is the same issue i am having

[mcfedr]

Anyone got any good work arounds for this? Dont really want to kill the cache before every build on CI, but its not great when you randomly get fails because of the wrong cache,...