New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Endless loop when fetching #733

Open
avalanched opened this Issue Sep 4, 2015 · 38 comments

Comments

Projects
None yet
@avalanched
Contributor

avalanched commented Sep 4, 2015

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

screen shot 2015-09-04 at 13 34 44

@mdiep

This comment has been minimized.

Member

mdiep commented Sep 4, 2015

What version of Carthage are you on? carthage version

@avalanched

This comment has been minimized.

Contributor

avalanched commented Sep 4, 2015

$ carthage version
0.8.0

@ikesyo

This comment has been minimized.

Member

ikesyo commented Sep 5, 2015

It might be dupe of #493.

@mdiep

This comment has been minimized.

Member

mdiep commented Sep 14, 2015

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

@MarvinNazari

This comment has been minimized.

MarvinNazari commented Sep 16, 2015

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

This comment has been minimized.

Autoc0diq commented Oct 9, 2015

Same here.

@marcoconti83

This comment has been minimized.

Contributor

marcoconti83 commented Oct 15, 2015

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

@marcoconti83

This comment has been minimized.

Contributor

marcoconti83 commented Oct 15, 2015

It seems like this ticket is related: #493. A possible cause (and solution) is listed in that ticket.

@guidomb

This comment has been minimized.

Contributor

guidomb commented Jun 8, 2016

This just happened to me in version 0.16.2

@guidomb

This comment has been minimized.

Contributor

guidomb commented Jun 9, 2016

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

This comment has been minimized.

Member

mdiep commented Jun 9, 2016

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

This comment has been minimized.

Contributor

guidomb commented Jun 12, 2016

@mdiep Yeah sorry bad copy pasting. I meant

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

@ghost

This comment has been minimized.

ghost commented Jun 30, 2016

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

@mdiep

This comment has been minimized.

Member

mdiep commented Jun 30, 2016

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

This comment has been minimized.

AndrewSB commented Jul 1, 2016

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

@mdiep

This comment has been minimized.

Member

mdiep commented Jul 2, 2016

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

@jobertsa

This comment has been minimized.

jobertsa commented Aug 23, 2016

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

This comment has been minimized.

fobin commented Sep 8, 2016

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

This comment has been minimized.

Member

mdiep commented Sep 9, 2016

@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

This comment has been minimized.

zaubara commented Apr 13, 2017

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

This comment has been minimized.

Member

mdiep commented Apr 13, 2017

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

@alejandro-isaza

This comment has been minimized.

alejandro-isaza commented Apr 13, 2017

@zaubara you should try punic

@zaubara

This comment has been minimized.

zaubara commented Apr 13, 2017

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

@nasht

This comment has been minimized.

nasht commented Sep 15, 2017

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

This comment has been minimized.

Contributor

NachoSoto commented Oct 31, 2017

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

This comment has been minimized.

Contributor

NachoSoto commented Oct 31, 2017

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

This comment has been minimized.

Member

mdiep commented Oct 31, 2017

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 #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

This comment has been minimized.

Contributor

BobElDevil commented Nov 2, 2017

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

This comment has been minimized.

Contributor

NachoSoto commented Nov 2, 2017

Thanks @BobElDevil! Should we release a new version?

@BobElDevil

This comment has been minimized.

Contributor

BobElDevil commented Nov 2, 2017

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

This comment has been minimized.

ewoks commented Mar 13, 2018

any progress on this? still not fixed?

@blender

This comment has been minimized.

Member

blender commented Mar 13, 2018

@ewoks feel free to submit a pr

@nekonari

This comment has been minimized.

nekonari commented Jun 1, 2018

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... 😞

@blender

This comment has been minimized.

Member

blender commented Jun 1, 2018

@nekonari have your tried with --new-resolver

@nekonari

This comment has been minimized.

nekonari commented Jun 1, 2018

@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.

@blender

This comment has been minimized.

Member

blender commented Jun 1, 2018

@nekonari try this branch #2455

@nekonari

This comment has been minimized.

nekonari commented Jun 13, 2018

@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. 😞

@blender

This comment has been minimized.

Member

blender commented Jun 13, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment