Open garrettmoon opened 7 years ago
From @nguyenhuy on March 22, 2017 19:16
IIRC, I ran into this problem before and pod update
helped.
There is no Podfile.lock checked in for the examples, so I'm not sure how CocoaPods is determining that we were using a naïve previous resolver.
I think it looks at your local Podfile.lock. I'd vote for checking those files into our repo.
From @nguyenhuy on March 22, 2017 19:17
https://github.com/pinterest/PINRemoteImage/issues/335 is probably the same problem.
From @master-nevi on March 30, 2017 23:44
Those Pinterest pods have been in beta for a loooong time; a pod in beta for that long and in production apps like Pinterest is probably production ready at this point isn't it?
From @nguyenhuy on March 31, 2017 11:5
@garrettmoon ^
@master-nevi yeaaaaah, we just haven't gotten around to do a proper release.
Any light at the end of the tunnel on this one 😛 ? At this point I've basically had to alias pod update <$args>
with pod update PINRemoteImage/FLAnimatedImage <$args>
to avoid that error message.
This isn't just a problem for examples, isn't this a problem for everyone? I'm personally stuck here. I can't run 'pod install' to add a new pod. (It appears that cocoapods 1.4 would actually install new pods when you list them on the command-line using "pod update", but in 1.5 we just get an error.) So my option at this point is to downgrade to 1.4, reverse out my 1.5-specific configuration, run "pod update blah blah" to get the podfile.lock updated then update to 1.5, make my changes again and finally run "pod update blah blah" again.
Can we pleas get some relief here?
UPDATE: I've worked out that I can explicitly include the pod version in the Podfile its self: "pod 'PINRemoteImage/FLAnimatedImage', '= 3.0.0-beta.13'". Not pretty but it works. I'm sure Texture developers everywhere will be very happy to have this fixed. I suspect this is a problem for any project using cocoapods.
From @Adlai-Holler on March 22, 2017 18:23
If you run
pod install
on most of our examples, you get this error:This is really irritating.
Podfile
doesn't specify thePINRemoteImage/iOS
dependency. It's specified inAsyncDisplayKit.podspec
.pod update PINRemoteImage/iOS
in each example once will save this from being a problem in the future, but I'm not sure.Podfile.lock
checked in for the examples, so I'm not sure how CocoaPods is determining that we were using a naïve previous resolver.Thoughts @maicki @nguyenhuy ?
Copied from original issue: facebookarchive/AsyncDisplayKit#3212