Carthage: Endless loop when fetching

[avalanched]

Sometimes i get stuck in an endless loop for https://github.com/antitypical/Result

[mdiep]

What version of Carthage are you on? carthage version

[avalanched]

$ carthage version
0.8.0

[ikesyo]

It might be dupe of #493.

[mdiep]

I'm seeing this today. The resolver is getting stuck during carthage update.

[MarvinNazari]

i can't upgrade to latest ReactiveCocoa i get into a endless loop fetching Result when i try to update, using carthage v0.8

[Autoc0diq]

Same here.

[marcoconti83]

This happens for me too on 0.9.2, it worked fine for a week and then suddenly started looping. Any temporary workaround?

[marcoconti83]

It seems like this ticket is related: https://github.com/Carthage/Carthage/issues/493. A possible cause (and solution) is listed in that ticket.

[guidomb]

This just happened to me in version 0.16.2

[guidomb]

Well the way I could reproduce this was by having a the following configuration

Project's Cartfile

github "ReactiveCocoa/ReactiveCocoa" ~> 4.2.0
github "CocoaLumberjack/CocoaLumberjack" ~> 2.2.0
github "Wolox/WLXBluetoothDevice" ~> 0.6.3
github "Wolox/WLXBluetoothDeviceReactiveExtensions" ~> 0.10.0
github "Wolox/WLXNordicUtilities" ~> 0.9.0

Wolox/WLXBluetoothDeviceReactiveExtensions also included github "ReactiveCocoa/ReactiveCocoa" ~> 4.2.0 but Wolox/WLXNordicUtilities included it like "ReactiveCocoa/ReactiveCocoa" ~> 4.1.0.

Once I changed Wolox/WLXNordicUtilities to include ReactiveCocoa with ~> 4.2.0 everything worked.

[mdiep]

also included github "ReactiveCocoa/ReactiveCocoa" ~> 4.2.0 but Wolox/WLXNordicUtilities included it like "ReactiveCocoa/ReactiveCocoa" ~> 4.2.0.

Were those supposed to be different?

[guidomb]

@mdiep Yeah sorry bad copy pasting. I meant

but Wolox/WLXNordicUtilities included it like "ReactiveCocoa/ReactiveCocoa" ~> 4.1.0.

[ghost]

We are also running into this problem. Version 0.16.2 and 0.17.

[mdiep]

If you see this, it's because Carthage is trying to resolve your dependencies, but can't find versions that work together. It's going further back in history to try to find versions that work together (and then mistakenly fetching again).

[AndrewSB]

Is it possible to see which dependencies are causing the versions to not work together?

[mdiep]

Not currently, no. You'd need to examine them manually.

[jobertcodes]

I'm facing the same issue with version 0.17.2. Some times it eventually passes that loop, some times it gets stuck there indefinitely, for the same Cartfile.
I can't figure out what's wrong since we don't have more output during this step.

[fobin]

Same issue started with me now. Version 0.17.2. Tested a bit a saw a difference. This doesn't work (starts to loop Alamofire endlessly):

github "Alamofire/Alamofire"
github "Alamofire/AlamofireNetworkActivityIndicator" "swift2.3"
github "bryx-inc/BRYXBanner"
github "dzenbot/DZNEmptyDataSet"
github "MortimerGoro/MGSwipeTableCell"
github "SwiftyJSON/SwiftyJSON"
github "ZipArchive/ZipArchive"

This works:

github "Alamofire/Alamofire"
github "Alamofire/AlamofireNetworkActivityIndicator"
github "bryx-inc/BRYXBanner"
github "dzenbot/DZNEmptyDataSet"
github "MortimerGoro/MGSwipeTableCell"
github "SwiftyJSON/SwiftyJSON"
github "ZipArchive/ZipArchive"

So the difference is in AlamofireNetworkActivityIndicator branch. Still it starts to loop "fetching Alamofire" and never stops. Reordering doesn't help.

Edit: Hmm. This happened first all the time but now Alamofire has merged that branch to master so this isn't valid test case anymore.

[mdiep]

@fobin You're spot on that this is related to branch pinning. It can happen with any non-release pin. Hoping to fix this soon.

[zaubara]

Any updates on the issue?
We're using carthage 0.20.1 and recently ran into this again.
Interestingly enough, an older version (with older repos ofc) worked fine. Some repos use non-release pins, some are private, some link back to others; but none of the versions or branches are conflicting, I double-checked that.

Current workaround: It does work if I remove the problematic repo and run the update again with the repo alone and stitch everything back together.
Example: Repo a, b and c are in the main Cartfile. b is the problematic one; all 3 have their own Cartfiles, but b seems to be looping on a completely unique repo (WeakArray); b shares multiple repositories with c, not a single one with the main one. c shares a few with the main. c used to use b, but for the sake of getting it to work i removed it from the cartfile.
Obviously not the most straightforward, but required for the submodules to work on their own.

[mdiep]

Nothing to report. I haven't had time to make progress on this.

[alejandro-isaza]

@zaubara you should try punic

[zaubara]

Alright, thanks for the update.
@aleph7 Looks great, I'll try that, thanks!

[nasht]

For what its worth, I saw this happen when I had a secondary dependency point to a branch which I had forgotten to push to the Repo.

ie. My Root Project points to repos A, B, and C. , repo C points to a branch of repo D which is not available in the repo (I had forgotten to push it).

Doing Carthage update on Root resulted in the dodgy behaviour and interestingly, the infinite fetch loop happened to A, or B , but not C - where I'd expect to see an error.

The fix was as simple as pushing the missing branch to the remote.

[NachoSoto]

I'm running into this on 0.26.2.

$ carthage update swift-protobuf --platform ios --verbose
*** Fetching A
*** Fetching Few
*** Fetching Other
*** Fetching Dependencies
*** Fetching Result
*** Fetching Result
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching LlamaKit
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box
*** Fetching Box

LlamaKit and Box? Looks like something it's making Carthage resolve to a very old version of Result :(

[NachoSoto]

I narrowed it down to having changed a.b.c to master in one of my dependencies in Cartfile.private.
Specifically, this is what I had:

github "facebook/ios-snapshot-test-case" "2.1.4"
github "ashfurrow/Nimble-Snapshots" "master"

Changed to

github "facebook/ios-snapshot-test-case" "master"
github "ashfurrow/Nimble-Snapshots" "master"

Probably because ashfurrow/Nimble-Snapshots/master is pinned to 2.1.4, pointing to master lead to this weird issue.

Is there some low hanging fruit to at least make the experience for this less horrible for the user? I'm happy to contribute that if anybody can point me in the right direction :) (I'm not super familiar with the Carthage codebase anymore).

[mdiep]

The most helpful thing would be to create a test case that exhibits the issue. ResolverSpec is pretty straightforward and makes this easy to do.

Or an even more helpful task would be https://github.com/Carthage/Carthage/issues/2000 – creating a script/option that saves the all the versions that the resolver sees to a JSON file or something so that they can be used for a test case.

[BobElDevil]

A new resolver implementation also was just merged to master here #2122 (can be activated by passing the --new-resolver flag). I'd also be curious to know if this resolver solves any of the issues seen here, or manifests them in different ways.

[NachoSoto]

Thanks @BobElDevil! Should we release a new version?

[BobElDevil]

To simplify getting it into users hands, that would make sense. There was only one other PR merged (a lib update), so it should be safe. I'm not sure what the protocol on doing a release is though, I've never done it.

[ewoks]

any progress on this? still not fixed?

[tmspzz]

@ewoks feel free to submit a pr

[nekonari]

Whoa, this is still open? I just ran into this issue. Seems like removing .resolved and .private produces different point where it starts infinite loop. But even after multiple tries, it doesn't resolve correctly... 😞

[tmspzz]

@nekonari have your tried with --new-resolver

[nekonari]

@blender Yes, it didn't help. I had to recover the old .resolved, then manually up the version of an updated library then do carthage build. Haven't found a way to successfully run carthage update yet.

[tmspzz]

@nekonari try this branch https://github.com/Carthage/Carthage/pull/2455

[nekonari]

@blender It didn't really help. I ended up divvying up the Cartfile into parts and hack Cartfile.resolved files into one to make this work. 😞

[tmspzz]

@nekonari i suggest then you record the dependencies (as explained in that branch) and add them as a test for the resolver.

[leonid-s-usov]

Got the same issue today. WHat's happening?

[absuurd]

Getting this as well. Any update?

*** Fetching XCGLogger
*** Fetching realm-cocoa
*** Fetching Alamofire
*** Fetching AlamofireObjectMapper
*** Fetching Bolts-ObjC
*** Fetching NVActivityIndicatorView
*** Fetching NVActivityIndicatorView
*** Fetching NVActivityIndicatorView
*** Fetching NVActivityIndicatorView
*** Fetching NVActivityIndicatorView
*** Fetching NVActivityIndicatorView
*** Fetching NVActivityIndicatorView
*** Fetching NVActivityIndicatorView

If I remove NVActivityIndicatorView, it will happen to another dependency

[absuurd]

^ My issue was that NVActivityIndicatorView had removed the branch I was attempting to pull in

[molayab]

Is there any fix for this? I'm having the same issues with the infinite fetch loop, the only way that I found to get it works was changing manually the .resolved file with the versions that I want to use.

I discovered that these files were using wrong versions however on my cartfile was defined the desired versions. It's weird the issue.

For example I had there define one internal framework as == 4.3.6 but carthage always was trying to use a very old version (4.2.4.test) (This tag doesn't follow the semantic versioning. I really don't know why it is using it as the default one)

[tarbayev]

rm -rf ~/Library/Caches/org.carthage.CarthageKit solved the problem for me

[breferrari]

Just had this problem with RxSwift, it was looping trying to fetch it.
Clearing the Carthage cache as @tarbayev sugested solved the problem for me also.

[jhandguy]

Same here.

[juliancadi]

Clearing Carthage cache didn't work for me:

*** Cloning ReactiveCocoa
*** Cloning Quick
*** Cloning CocoaAsyncSocket
*** Cloning RxSwift
*** Cloning Result
*** Fetching CocoaAsyncSocket
*** Fetching CocoaAsyncSocket
*** Fetching CocoaAsyncSocket
*** Fetching CocoaAsyncSocket
*** Fetching CocoaAsyncSocket
...

[tmspzz]

To everyone that is having issues, try --new-resolver.
The problem most of the time is there is a conflicting requirement or a tag is missing in one of the repositories.

If you are using a branch name as instead of a version, be sure to use --new-resolver.

[juliancadi]

carthage update --platform ios --new-resolver did the job for me

[dulgan]

Just occurred for me on 0.34.0, as it happened to fill my entire disk while afk, I think it could be a thing to pay attention to...

Even a "rm" command gave me a "No space left on device" error 😭

Solved by the --new-resolver (--not-so-new-isn't-it-?-resolver).

EDIT: not really solved, just occurred with the --new-resolver too...

[mendesbarreto]

Hey guys,

Unfortunately, the Carthage is giving me a lot of headaches these days every time I'm going to use Carthage update --platform ios. The problem is very intermittent, but I always should remove the Carthage cache 3 or 4 times before it works, it's very rare when it works on the first try.

I already tried --new-resolver and --no-use-binaries but it seems to happen when the Carthage try to fetch RxSwift for me every time 😫.

Maybe this is a problem with Catalina or Xbuild from Xcode 11 because I started to get this problem after my update. 😢

Thank you for all your help.

[ralbertini]

I had this problem when inside a branch I changed the project swift version. When I came back to previous branch (old swift version) the problem appears to me.

As previous answers, cleaning the carthage cache rm -rf ~/Library/Caches/org.carthage.CarthageKit and running carthage update --platform iOS --cache-builds --new-resolver solved the problem

[HamzaSellami]

Any news about this problem?
I am facing it since last xcode update 12.2 and Swift 5.3.1.
I tried cleaning carthage cache and running carthage update --verbose --platform iOS --cache-builds --new-resolver but still having infinite loop while fetching !

Thank you in advance for your help.