Build xcconfig from podspec using exact version of dependency - xcode

The ParcelKit Cocoapods podspec file defines a dependency on the Dropbox Sync API SDK like so:
s.dependency 'Dropbox-Sync-API-SDK', '~> 3.1.0'
At the moment, this means it fetches version 3.1.1 of the SDK (it's ambivalent about the final part of the version number - which is a good thing!). But the same podspec also then adds an entry to the Framework search paths of the xcconfig file using a hardcoded version number, 3.1.0:
s.xcconfig = { 'FRAMEWORK_SEARCH_PATHS' => '"${PODS_ROOT}/Dropbox-Sync-API-SDK/dropbox-ios-sync-sdk-3.1.0"' }
This causes a compilation error, because it looks for v3.1.0 and ignores what is actually installed, v3.1.1, so it can't find the header files and everything breaks.
Obviously we can manually update the ParcelKit podspec (and indeed, it has already been updated to explicitly reference v3.1.1) but I wondered if there's a more robust way to define this so that if Dropbox ever releases v3.1.2 then the podspec continues to work automatically? i.e. that it will automatically add 3.1.2 to the Framework search paths rather than 3.1.0.

To specify a version like this remove the ~>.
s.dependency 'Foo', '3.1.0'
The different ways to specify a version are explained here

Related

source issue with podfile

I'd like to specify version 5.1.0 of the InstaCart TrueTime library in a Podfile instead of 5.0.3. I think this is the only way to use 5.1.0 since 5.0.3 hasn't been added to the master per https://github.com/instacart/TrueTime.swift/issues/97
(The library is pretty outdated unfortunately.)
According to Add Pod dependency with source to .podspec, the way to do this is add
source 'https://github.com/instacart/TrueTime.swift.git'
at the top, but I then get the following error with 'pod update':
[!] Unable to find a specification for `TrueTime`
I think this error occurs because the source has TrueTime.podspec at the top level instead of inside a '5.1.0' folder, even though my podspec doesn't specify a version:
s.dependency "TrueTime"
Is my thinking correct, and is there a way to solve this issue?
The source attribute is used to refer to a podspec repository, not a single pod.
To accomplish that goal, you could set up a private specs repository and publish the desired podspec there - then refer to the podspec repo from the Podfile.
Details at https://guides.cocoapods.org/making/private-cocoapods.html

How to satisfy cocoapod external dependancy when using specific branch

In my project I'm using both Swinject and SwinjectAutoregistration pods. Both are usually declared as '2.0.0' versions like so:
pod 'Swinject', '2.0.0'
pod 'SwinjectAutoregistration', '2.0.0'
But in order to build my project in the beta version of Xcode 9, I need to take a specific branch of the Swinject github repo, as stated here. The new declaration looks like this:
pod 'Swinject', :git => 'https://github.com/Swinject/Swinject.git', :branch => 'swift4'
When I then try pod update I have dependencies error. I believe SwinjectAutoregistration declares a dependency to Swinject 2.0 so I have different sources for the same pod.
Is there a way to tell cocoapods that this specific source of the pods acts like the 2.0 version?
Well, it seems like specifying the source as the github repo instead of the cocoapod repo for this particular pod works.
I added this line before the target 'MyGreatApp' do line:
source 'https://github.com/Swinject/Swinject.git'
I must specify that this works for this particular pod, but might not work for other cases. The fine folks behind Swinject have a fix for an Xcode (9, beta) bug on a branch in their github repo that is not in the cocoapod repo.
So this answer works in this case, but unfortunately this might not be as generic as I hoped.

Podspec dependancies in local repos

We've made a local repository for local podspecs. In it I've put this Lua podspec, because I need 5.1.5 support. To make sure there are no name collisions, I called it Lua51. It validates fine (via "pod spec lint", so so far so good. :-)
-> Lua51 (5.1.5)
The lua language (for embedding).
pod 'Lua51', '~> 5.1.5'
- Homepage: https://github.com/qmx/lua
- Source: http://www.lua.org/ftp/lua-5.1.5.tar.gz
- Versions: 5.1.5 [mypodrepo repo]
Building on that, I’d like to make a podspec that uses this as a dependency. So I added "dependencies": { "Lua51": [ "~> 5.1.5"] } to the podspec for luaz, but when I do a “pod spec lint” I get
[!] Unable to find a specification for `Lua51 (~> 5.1.5)` depended upon by `luaz`.
Is there a limit on searching for dependencies in the main repo only? Or have I done something else wrong when specifying the dependancy?
Assuming that dependency is in place, how should I add the Lua51 header directory to the HEADER_SEARCH_PATHS, so that luaz will compile?
BTW, all my podspecs are in JSON notation. Here is the link for the podspecs Lua51 and for luaz
Cheers
Nik
I think this is fixable by the --sources=https://github.com/artsy/Specs flags on the command.
I think we could definitely do a better job around explaining the problem here. Perhaps if we don't find it we could recommend using the sources flag.

CocoaPods get current dependency versions

I have a project which uses CocoaPods. My Podfile specifies the dependencies required, however, I did not specify the versions that should be used.
I'd like add explicit dependency versions to my Podfile, so that using pod install after checking out my project on a new computer would always fetch my current, not newest version of Pod dependency from CocoaPods.
Is there a way to quickly check which version of each Pod dependency I currently have in my project directory?
The only way to update the currently installed versions of your pods is by running pod update. If you don't do this all the current version information is stored in the Podfile.lock and will make sure the versions are the same between installs.
This file is also the best place to look for these versions if you want to add them. In your Podfile.lock you'll see a list like this:
PODS:
- EasyMapping (0.6.3)
- Expecta (0.3.1)
- OCMock (3.1.1)
- OHHTTPStubs (3.1.6):
- OHHTTPStubs/Core
- OHHTTPStubs/Core (3.1.6)
- Specta (0.2.1)
The top level (left most) entries are the pods you have specified in your Podfile. As you can see to the right is the currently installed version. You can grab the versions from here and put them in your Podfile.

CocoaPods block dependency installation

I haven't found the answer to this within the Podfile docs, so I'm not sure if it's possible.
I want to install a CocoaPods project which has 3 dependencies. I add it to my Podfile:
pod 'IDMPhotoBrowser'
and run install:
$ pod install
Installing DACircularProgress (2.1.0)
…
Installing IDMPhotoBrowser (1.2)
…
Installing SVProgressHUD (0.9)
However, I have a hacked up version of SVProgressHUD in my project which contains code not in the current repo. Additionally, SVProgressHUD 0.9 is from January, and there are months of additional commits since then. I would like to use my manually added version instead.
Can I specify in my Podfile that SVProgressHUD should not be installed, so that my manually added version is used? Or do I just need to delete it by hand every time I run pod install?
Alternatives
I know I could upload my fork to github and do something like:
pod 'SVProgressHUD', :git => '<my git repo>', :commit => '<my sha>'
but I'm hoping to not need to upload code just to get Cocoapods to do what I want.
It's not so much about blocking the dependency as it is overriding it with your own. This means that CocoaPods needs to find your local copy of SVProgressHUD before it activates IDMPhotoBrowser and looks for SVProgressHUD in the master spec repo.
You can achieve the setup you want by declaring your version of SVProgressHUD first in your Podfile using a local podspec:
Your custom version needs to be in a subdirectory of your project, with a valid podspec at the root of that directory, e.g., External/SVProgressHUD/SVProgressHUD.podspec.
Update your Podfile like this:
pod 'SVProgressHUD', :path => 'External/SVProgressHUD' # this needs to be declared first
pod 'IDMPhotoBrowser' # your custom pod will be used as the dependency here
If you don't have a local podspec, you should be able to take a copy of the 0.9 version of SVProgressHUD (and if necessary modify it to compile any new code you've added).

Resources