Skip to content
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

Is there a way to specify a dependency on another branch when building my Cocoapod? #3901

Closed
AndyIbanez opened this issue Jul 25, 2015 · 9 comments

Comments

@AndyIbanez
Copy link

I originally asked this in StackOverflow, but figured it would be more likely to get help here. Please bear with me.

The original question is here.

The TL;DR version is:

I'm building a Cocoapod that will currently depend on different branches than master of Alamofire and SwiftyJSON. This is because my pod uses Swift 2.0, and the branches I'm specifying have been updated to Swift 2.0.

In my Podspec, I have specified SwiftyJSON and Alamofire as dependencies. I read in a SO answer that you cannot specify different branches for the dependencies in the Podspec, and you should do it in the Podfile instead. So I modified the Podfile to use the different branches for Alamofire and SwiftyJSON.

But, when I try to lint the project, it complains about many errors. All these errors have to do with Swift syntax that changed from Swift 1.0-1.2 to Swift 2.0. This can only mean that, despite me specifying the branches in my Podfile, when linting it will download the master branch, and hence it won't succeed until my needed branches are merged into their respective masters.

My Podspec and Podfile are below:

#
# Be sure to run `pod lib lint ALSMAL.podspec' to ensure this is a
# valid spec and remove all comments before submitting the spec.
#
# Any lines starting with a # are optional, but encouraged
#
# To learn more about a Podspec see http://guides.cocoapods.org/syntax/podspec.html
#

Pod::Spec.new do |s|
  s.name             = "ALSMAL"
  s.version          = "2.0.0"
  s.summary          = "A Swift wrapper for the Atarashii MAL API."
  s.description      = <<-DESC
A Swift, protocol-oriented iOS framework to interact with Atarashii MAL API, an unofficial API for MyAnimeList.net.
                       DESC
  #s.homepage         = "https://github.com/AndyIbanez/ALSMAL"
  s.homepage         = "https://andyibanez.com"
  s.license          = {:type => "MIT", :file => "LICENSE"}
  s.author           = { "Andy Ibanez" => "andy@ibanez.me" }
  s.source           = { :git => "https://AndyIbanez@bitbucket.org/AndyIbanez/alsmal.git", :tag => s.version.to_s }
  # s.social_media_url = 'https://twitter.com/AndyIbanezK'

  s.platform     = :ios, '9.0'
  s.requires_arc = true

  s.source_files = 'ALSMAL/*'
  s.resource_bundles = {
    'ALSMAL' => ['Pod/Assets/*.png']
  }

  s.dependency 'Alamofire'
  s.dependency 'SwiftyJSON'
end

# Uncomment this line to define a global platform for your project
platform :ios, '9.0'
use_frameworks!

link_with 'ALSMAL', 'ALSMALTests'

target 'ALSMAL' do
   pod 'Alamofire', :git => "https://github.com/Alamofire/Alamofire.git", :branch => "swift-2.0"
   pod 'SwiftyJSON', :git => "https://github.com/SwiftyJSON/SwiftyJSON.git", :branch => "xcode7"
end

target 'ALSMALTests' do
    pod 'Alamofire', :git => "https://github.com/Alamofire/Alamofire.git", :branch => "swift-2.0"
    pod 'SwiftyJSON', :git => "https://github.com/SwiftyJSON/SwiftyJSON.git", :branch => "xcode7"
end

I'm out of ideas to try.

@segiddins
Copy link
Member

Yes, that's intended. Linting lints against the podspec and not the Podfile.

@AndyIbanez
Copy link
Author

Is there absolutely no way to specify a different branch as part of the dependency in the Podspec then? I Just need to know to decide if I should pause this project until Xcode 7 is officially out of beta and move on to other projects until then.

@segiddins
Copy link
Member

No, non-released dependencies can only be set in the Podfile.

@AndyIbanez
Copy link
Author

Gotcha. Thanks a lot for your response.

@foscomputerservices
Copy link

@segiddins, I realize that this thread has been closed, but I felt that I had to re-raise the issue that was originally described by @AndyIbanez above now that we're at the swift 3.0 migration.

As an indy developer, I have multiple clients' applications and custom podfiles that are written in swift and have dependencies on other pods that also are written in swift. All of my customers would like me to begin migrating and testing their applications to swift 3 and iOS 10.

If I understand what's written above correctly, I am going to have all of my applications and all of my pods stuck at swift 2.0 until all of my (swift-based cocoapod) dependencies complete their conversion to the next version of swift and push new pods that are compatible with the same swift language version (3.0 in my case).

However, I suspect (but I might be wrong) that my dependencies probably will not want to release a swift 3.0 version of their pod as, almost certainly, swift 3.0 will be unstable until this fall. So that would seem to imply that I will not be able to start migrating my app until after swift 3.0 is released this fall. Certainly I cannot be the only developer in this position.

It seems that my only other option is to inline all of the code from my pods so that I can point to my dependencies using the various branches that my dependencies are using to perform their swift 3 changes on.

Of course this also implies that if any of my dependencies have indirect dependencies on swift libraries that I need to inline the code from those indirect dependencies as well.

I sure hope that I'm missing something....

@orta
Copy link
Member

orta commented Jun 20, 2016

Not too sure what you're asking, but you would declare all of the dependencies to their corresponding Swift 3.0 branches in each Podfile.

This question is that you cannot push a podspec that relies on un-released podspecs to trunk. That's not changed since last year.

@foscomputerservices
Copy link

Thanks for the quick response!

The issue is exactly the one that you describe; it seems that I have to wait to update my pods to swift 3.0 until all of the swift dependencies of that pod have updated to swift3 and pushed podspecs to trunk.

Normally this limitation of the podspec isn't an issue because unreleased pods are adding new functionality and there are no cross-pod dependencies other than version. However, in the case of the swift language spec being updated not only is pod version important, but language version as well. That is, to compile my application I can only use one compiler (swift 2 or swift 3) to compile my application and all of its transitive dependencies.

For all of the pods that I transitively depend upon:

  1. I might need to convert the code myself and provide pull requests to the original author
  2. The original author may have a conversion completed, but hasn't yet published an updated pod

So, my application's Podfile for my Swift 3 code looks as follows:
pod 'DMTDFoundation', git: 'git@bitbucket.org:dmtd/dmtdiosfoundation.git', branch: 'development'
pod 'RNCryptor', git: 'https://github.com/RNCryptor/RNCryptor.git', branch: 'swift3'

However, when I have a pod that depends on a pod that's not yet available, I have a problem:
s.dependency 'RNCryptor', '~> 4.0' # This only compiles with Swift 2.0

In this case, rnapier is already working on the update to Swift 3.0 on a branch called 'swift3' (hooray!). However, there's no way for me to reference that code from my dependent podspec, so my application will not compile using the swift 3 compiler as I cannot update the dependency in DMTDFoundation.podspec.

When I do a pod install of the above application, I see the following in the output:

Using RNCryptor (4.0.0)

My transitive closure of swift code dependencies is getting pretty large. Perhaps the only thing that I can do is to create private podspecs for all of the pods and publish them all to a private repository until everyone has completed publishing swift3 podspecs to trunk.

@orta
Copy link
Member

orta commented Jun 20, 2016

You can move the transitive dependencies into the Podfile, so they also can get the branch reference, which should negate the issue around the transitive nature of the dependencies. As they would probably still have the same version number - you'd still be working correctly to the Podfile.lock contract.

We've migrated a few apps between swift versions this way, then once everything is stable and in trunk, we remove the transitive deps from the Podfile.

@foscomputerservices
Copy link

Yes! That works perfectly. Thank you!

For anyone that might have the same issues, I simply added a temporary method in my Podfile that overrides the necessary dependencies:

# TODO: Remove this after all pods are converted to swift 3
def swift3_overrides
    pod 'RNCryptor', git: 'https://github.com/RNCryptor/RNCryptor.git', branch: 'swift3'
end

target 'VB-MAPP' do
    swift3_overrides

    pod 'DMTDFoundation' # This podspec still references 'RNCryptor', '4.0.0', but is overridden above
    pod # ...
end

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants