Upgrade from 0.16.2 to 0.17.1 Results in [!] Unsupported version requirements #922

Closed
tlomenda opened this Issue Apr 1, 2013 · 30 comments

Comments

Projects
None yet
9 participants

tlomenda commented Apr 1, 2013

I am working on In House CocoaPods and have been using the :local => syntax in my podspec to reference pods as local dependencies until I am ready to officially release it to my private pod spec repository.

This worked great in 0.16.2 and is a very useful feature. Now I receive the Unsupported version requirements error.

As documented in "https://github.com/CocoaPods/CocoaPods/wiki/Dependency-declaration-options" this syntax to reference a dependency should be accepted.

Thanks.

Owner

alloy commented Apr 2, 2013

That wiki entry is about project dependencies (in the Podfile), not for those in specs. The fact that it worked before was an implementation detail and is now indeed removed, but this is intentional.

Can you explain what was the exact thing you preferred instead of adding it to a spec repo? (Closing for now, as the actual behavior change was intentional.)

PS it should still be possible to specify all your dependencies in the Podfile with the :local option and they should ‘just work’, although you will have to specify them in the right order as they are resolved.

alloy closed this Apr 2, 2013

tlomenda commented Apr 2, 2013

Thanks for the reply. I see that It still works in the Podfile.

My specific situation is when 1 podspec depends on another (transitive
dependency). In my project's Podfile I only need to specify one dependency
and I get both. Both Pods are for private in-house use and there are often
times that both are in a local development state at the same time (hence
needing the :local). They may not always follow the same release cycle but
it is very nice to have that option. Note, at the time I release a pod I
replace the :local reference to a real version.

It was convenient to set everything to local during the development stage
of a project as well the private pods it depended on. It is unfortunate
that this flexibility was removed. Would it be possible to reconsider. I
can understand why this was removed for pods being pushed to the CocoaPods
master, but for private specs this is a great option.

Another option would be to allow :local, but if you attempt to release a
version to a repository with the :local reference it would fail.

Thoughts?

Overall I have loved the flexibility and control I get with CocoaPods.
Thanks for the great work.


Torey Lomenda, SCEA
Senior Consultant
Mobile & Enterprise Technologies
Object Partners Inc.
612.807.6120

On Apr 2, 2013, at 4:24 AM, "Eloy Durán" notifications@github.com wrote:

That wiki entry is about project dependencies (in the Podfile), not for
those in specs. The fact that it worked before was an implementation detail
and is now indeed removed, but this is intentional.

Can you explain what was the exact thing you preferred instead of adding it
to a spec repo? (Closing for now, as the actual behavior change was
intentional.)

PS it should still be possible to specify all your dependencies in the
Podfile with the :local option and they should ‘just work’, although you
will have to specify them in the right order as they are resolved.


Reply to this email directly or view it on
GitHubhttps://github.com/CocoaPods/CocoaPods/issues/922#issuecomment-15765036
.

Owner

fabiopelosin commented Apr 2, 2013

This behavior was removed because it required to stop in the middle of the resolution process to fetch the external source (i.e. a specification is loaded and to resolve the dependencies of it dependencies we might need to clone a git repo just to get the podspec).

Finally I think that it is confusing, adding an additional line to the podfile is relatively easy and makes clear to users from where they are getting their specifications from.

Owner

alloy commented Apr 2, 2013

@tlomenda I see you point, but I’m inclined to agree with @irrationalfab. We need to constantly compare implementation complexity vs time saved by the user and like he said it should not be that much extra work in the Podfile.

tlomenda commented Apr 2, 2013

Ok, thought I would try since it is a feature I have read other developers taking advantage of and I have used it with satisfying results.

I think transitive dependencies are a good thing, and there are a number of reasons why a developer may be working on two dependent pods at the same time - as I described in my last comment. I suppose the idea that it is confusing is a matter of opinion. I like that CocoaPods provides users with simplicity, consistency, and flexibility and that the local feature feature worked consistently in Podfile and Podspec (from a user perspective), offered great flexibility. Having a useful feature taken away is too bad.

I have also found nice uses for CocoaPods for local development only (no spec repos) with transitive dependencies and the local option in both the Podfile and PodSpec worked great.

Oh well, I will look at finding workarounds to this or stay on 0.16 for a bit.

tlomenda commented Apr 2, 2013

Just an FYI, that I have moved to adding the :local option to the Podfile only and yes that does work.

Although I like the support that 0.16 had for :local, I will look to change my approach to adhere to the new direction of CocoaPods.

Thanks for your time.

Owner

alloy commented Apr 2, 2013

@tlomenda Even though we won’t be changing this back for now, we really appreciate you taking the time to provide feedback and info that we can base future decisions on!

So I'm also pretty confused about this change and how to fix it.

For reference I'm doing this in my podspecs:

s.dependency "ZWCoreKit", :podspec => "https://raw.github.com/zwopple/ZWCoreKit/master/ZWCoreKit.podspec"

Which is no longer working. Heck even if I add this in the podfile before the pod with the dependency it doesn't work.

Are what you guys saying is I now must add my podspecs to a independent repository and reference the dependencies just by name? The whole reason I reference the podspecs directly is because I change my libraries frequently while working on projects and don't want to have to deal with committing two separate repositories for every single change.

Here's my podfile:

platform :ios, "6.0"

pod "Facebook-iOS-SDK"
pod "TestFlightSDK"
pod "AFNetworking"
pod "ViewDeck", :git => "https://github.com/Inferis/ViewDeck.git"
pod "FLKAutoLayout"
pod "ZWCoreKit", :podspec => "https://raw.github.com/zwopple/ZWCoreKit/master/ZWCoreKit.podspec"
pod "ZWTouchFrames", :podspec => "https://raw.github.com/zwopple/ZWTouchFrames/master/ZWTouchFrames.podspec"
pod "ZWTouchKit", :podspec => "https://raw.github.com/zwopple/ZWTouchKit/master/ZWTouchKit.podspec"

And here's ZWTouchKit's podspec that is failing due to this error:

Pod::Spec.new do |s|
  s.name = "ZWTouchKit"
  s.summary = "Collection of UIKit like extensions, utilities and helpers."

  s.version = "1.6.0"
  s.license = "None"
  s.homepage = "https://github.com/zwopple/ZWTouchKit"
  s.author = { "Zwopple | Creative Software" => "support@zwopple.com" }
  s.source = { :git => "https://github.com/zwopple/ZWTouchKit.git" }
  s.requires_arc = true
  s.prefix_header_file = "ZWTouchKit/ZWTouchKit-Prefix.pch"
  s.source_files = "ZWTouchKit"
  s.frameworks = "UIKit", "CoreText", "MapKit"

  s.dependency "ZWCoreKit", :podspec => "https://raw.github.com/zwopple/ZWCoreKit/master/ZWCoreKit.podspec"
  s.dependency "ZWTouchFrames", :podspec => "https://raw.github.com/zwopple/ZWTouchFrames/master/ZWTouchFrames.podspec"
end
Owner

fabiopelosin commented Apr 9, 2013

Heck even if I add this in the podfile before the pod with the dependency it doesn't work.

If you can confirm this, it is a bug. In that case please open a dedicated issue with a minimal example to reproduce it.

Are what you guys saying is I now must add my podspecs to a independent repository and reference the dependencies just by name? The whole reason I reference the podspecs directly is because I change my libraries frequently while working on projects and don't want to have to deal with committing two separate repositories for every single change.

You custom repo doesn't need to be under source control.

However from you description looks like you are interested in the :local option which has always been the only one which allows to use a source without committing. Is this the reason why the Podfile is working as you expect?

With the above Podfile / Podspec example it was working before I expect it to still work since I specify the exact location of the Podspec files and cocoapods should be able to download and inspect them. I understand pre-downloading an entire github repo was a bit extensive but we should be able to hardcode urls to raw podspecs still yes?

Does the :local option work for remote locations or file paths only?

Owner

fabiopelosin commented Apr 9, 2013

With the above Podfile / Podspec example it was working before I expect it to still work since I specify the exact location of the Podspec files and cocoapods should be able to download and inspect them.

To use a custom podspec. The source of the podspec is respected. Ie. in this case CocoaPods cares only about the Podspec file:

pod "ZWCoreKit", :podspec => "https://raw.github.com/zwopple/ZWCoreKit/master/ZWCoreKit.podspec"

To use local checkout in your file system with a podspec in the root:

pod 'ZWCoreKit', :local => '~/Documents/ZWCoreKit'

To use a given remote source with a podspec in the root:

pod 'ZWCoreKit', :git => 'https://github.com/zwopple/ZWCoreKit'

For more info see the docs.

I understand pre-downloading an entire github repo was a bit extensive but we should be able to hardcode urls to raw podspecs still yes?

With your setup CocoaPods was not pre-downloading the git repo but only the podspecs files with http. Specifications should only be concerned to list their dependencies with the appropriate version requirements. It is not their responsibility to specify where to fetch a source from. The Podfile and the custom repos options should cover those scenarios adequately.

@irrationalfab Ok so this works, thanks!, but the lint was still failing thus I thought I was going to need to specifically add them to a spec repo.

I think the big thing people need to take note now ( if you're getting this error ) is that you must specify all dependencies now in the Podfile and dependencies in Podspecs must reference the pod by name and version only.

Doesn't this break pods that are dependent on custom forks of other pods?

For example, I'm working on a pod named CustomNetworking. CustomNetworking is dependent on my custom fork of AFNetworking, living at github.com/eliperkins/AFNetworking. I shouldn't need to declare in my project that uses the pod CustomNetworking that I need a fork of AFNetworking, Cocoapods should just resolve that in the .podspec for CustomNetworking, correct?

So the .podspec for CustomNetworking would have the line:

s.dependency 'AFNetworking', :git => 'https://github.com/eliperkins/AFNetworking'

and the Podfile would just state

pod 'CustomNetworking'

So if I understand this correctly, now, with the current changes, the .podspec would be

s.dependency 'AFNetworking'

and the Podfile would be:

pod 'AFNetworking', :git => 'https://github.com/eliperkins/AFNetworking'
pod 'CustomNetworking'

It feels a little uncomfortable that I've have to understand the dependencies of CustomNetworking and explicitly declare them in the Podfile that uses that pod.

If this design is the new way that pods should be declared, there at least should be some clarification with how to migrate or some sort of backwards compatibility + deprecation of the old style of declaring custom dependencies.

Owner

fabiopelosin commented Apr 9, 2013

It feels a little uncomfortable that I've have to understand the dependencies of CustomNetworking and explicitly declare them in the Podfile that uses that pod.

If the fork is relevant enough a Pod with a new name would be more appropriate. According to the use, a custom repo might be a very good solution. Otherwise it is better to specify in the Podfile that a fork is being so developers are aware of it. Otherwise they would need to understand why AFNetworking is different from AFNetworking, which might be even more uncomfortable.

If this design is the new way that pods should be declared, there at least should be some clarification with how to migrate or some sort of backwards compatibility + deprecation of the old style of declaring custom dependencies.

This never has been a supported feature of CocoaPods, the fact that it used to work was an implementation detail. I doesn't work anymore because CocoaPods has been refactored. The migration path is to either specify the fork in the Podfile, to use a custom podspec or to use a private repo which is very easy to add and to maintain (it doesn't need to be under git source control).

Owner

alloy commented Apr 9, 2013

or to use a private repo which is very easy to add and to maintain

To clarify, @irrationalfab is speaking of a ‘spec repo’.

paulsfds commented May 2, 2013

I greatly dislike this change. Before I could specify my dependencies in the podspec and if those dependencies had other dependencies it would automatically retrieve those (from private git repos). Now, not only do I have to manually specify the dependencies in the Podfile, I also need to specify the dependencies dependencies (and in correct order). This is a pain when you have lots of layers of dependencies.

Anyway, it doesn't look like this will get changed any time soon, but I thought I would add my two cents.

Owner

fabiopelosin commented May 3, 2013

I also need to specify the dependencies dependencies (and in correct order)

FYI, the fact that you need to specify the dependencies in the correct order is a current limitation of the resolver and it will be improved.

Owner

alloy commented May 3, 2013

Before I could specify my dependencies in the podspec and if those dependencies had other dependencies it would automatically retrieve those (from private git repos). Now, not only do I have to manually specify the dependencies in the Podfile, I also need to specify the dependencies dependencies (and in correct order). This is a pain when you have lots of layers of dependencies.

Specs for private source locations should go in a separate private spec repo. When you do that, everything will work as expected, no need to deal with order.

The previous behaviour is fragile and makes it too easy to submit half working specs to the spec repo, which is a problem for everyone if it's the master spec repo.

Anyway, it doesn't look like this will get changed any time soon, but I thought I would add my two cents.

Feedback is always appreciated.

But for this case, it was never meant to work this way. It had unspecified behaviour, which meant that it just happened to work. Now the behaviour is specified and it’s not going to change.

I have been evaluating CocoaPods for use on a large project today; but this feature change (incidental or not) is, unfortunately, a complete deal breaker.

Hopefully someone can tell me I've misunderstood something here, because I can't believe my use case is un-common: I want to develop several modules simultaneously, and having the ability to edit and re-build them without committing to a repository every time is crucial to a fluid workflow.

I am currently doing this successfully, with standard nested projects in Xcode, but as one of my modules is a transitive dependency (shared by multiple other modules), I have to remove that dependency in 'all but one' place to avoid duplicate symbols being created during build.
As I say, this does work, but leaves the sub-modules in a 'broken' state when treated as standalone, so they cannot be compiled for unit-testing or committed as ready for re-use.

CocoaPods could have solved this in theory, with its 'flattening' of the dependency graph, but seems too focused on managing already-complete '3rd Party Vendor' dependencies for my workflow. Which is a shame, I can see how CocoaPods is incredibly useful in certain scenarios; with better local support, it could be so much more.

Does anyone have an alternative way of managing the duplicate symbols problem encountered with a transitive dependency?

@chris-hatton I feel you. I'm experiencing the same problems, a Podspec should be able to refer to a local Pod. This will really improve CocoaPods a lot!

Owner

alloy commented Jun 20, 2013

@chris-hatton @NielsKoole Local overrides are done as @irrationalfab shows in #178.

@alloy But my Podfile from PodA looks like this:

platform: ios

podspec: podspec => "../PodA.podspec"

If I setup my Podfile like this:

platform: ios

pod 'PodB', :path => '../../PodB'

Then PodA knows about PodB indeed. But when I'm going to use PodA in my application project, PodB won't be imported in my project. This is because I cannot declare PodB as a dependency in my PodA podspec file.

Owner

fabiopelosin commented Jun 20, 2013

@NielsKoole In this case you should declare PodB as a normal dependency in PodA (i.e. without the path option) then in the Podfile that you use to develop PodA you can do the following:

platform: ios
pod 'PodB', :path => '../../PodB'
podspec: podspec => "../PodA.podspec"

Then in the Podfile of every project where you would like to use the checkout of PodB you can use the :path option. Note that I can't stress the fact that Pods should have a remote and be versioned. Otherwise you could run the risk of breaking a project which hasn't been developed for some time because it is using the path option, and there would be no easy way to understand on which commit it used to build.

...and I can't stress enough how terrible my workflow would be if, every time I wanted to edit a dependency, I had to commit to a repo. I'm developing four pods simultaneously, which is not that unusual a requirement. Point taken though, that any local references should be diligently removed for release.

@irrationalfab Thank you for your reply. Before I'll try your suggestion, I have a question about dependencies within Pods. When I want to use PodA in my project, it will only lookup for it's podspec right? In my podspec there is no reference to the Podfile (so no declarence to PodB), which means that my project doesn't import PodB. Or do I miss something?

Owner

fabiopelosin commented Jun 20, 2013

I'm developing four pods simultaneously, which is not that unusual a requirement.

This is more or less my point, with the path option you can easily add them at the top of the Podfile, and this is not a tedious process (so I don't see any advantage in having the podspec do it for you). However if you start to do it in multiple projects (where the support in the podspec would make a difference) things could get messy pretty soon.

Owner

alloy commented Jun 20, 2013

@chris-hatton @NielsKoole I suggest you guys try the suggestions first. This is not a usage support forum, such questions should go to StackOverflow or the mailing-list where a wider audience can help you out.

Owner

fabiopelosin commented Jun 20, 2013

When I want to use PodA in my project, it will only lookup for it's podspec right? In my podspec there is no reference to the Podfile (so no declarence to PodB), which means that my project doesn't import PodB.

This is why the podspec should declare the dependency (and any version requirements), however where to get that Pod is not responsibility of the Podspec. In my example I added to the Podfile of PodA a dependency to PodB just to inform the resolver that it should checkout that pod from a local path.

So if in a Podfile you use PodA you get PodB, however if you would like to work also on it you add a dependency to it at the top with the path option.

Btw, I agree with @alloy as the concepts of this comment are spread in other comments across the issues tracker and apparently they continue to pop out.

@alloy, @irrationalfab Understood, and thanks for the help.

amolloy commented Apr 16, 2015

Now that CocoaPods supports generating frameworks, listing the local dependency in the podfile is no longer adequate to solve this problem since a pod's framework will fail to link if it doesn't know about its dependencies. Any possibility of reconsidering this issue with that in mind? Maintaining a podspec repo just to solve this issue is really a significant burden during development.

Danappelxx referenced this issue in SwiftyJSON/SwiftyJSON Sep 9, 2015

Closed

Make release from xcode7 branch #321

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