Disclaimer - I am very new to cocoapods. This might be a very silly question for most ios developers.
The artifactory documentation link for uploading cocoapods is quite explanatory and easily understandable. I have followed the steps and I have tried uploading a well known pod (ABCustomUINavigationController) to the my own local instance of artifactory.
The deployment section of the documentation says
I am using the Web UI for deploying the pod (in .tar.gz format) to the artifactory. The way I've done that is:
Is this the ideal way to deploy pods? Also, if I want to upload a xcodeproj (build output) of the pod along with the .podspec file, then how should I go about it?
Thanks.
I see you uploaded the pod itself under the .specs folder of your repo, this is actually where Artifactory keeps the index that the pod client later retrieves when you use pod repo-art add or pod repo-art update. Although there's no restriction as to where to put the pods themselves I would keep them out of the .specs folder to keep things organized for yourself.
As for build outputs - A CocoaPod typically contains source code (and perhaps other resources) that a project can include and not the output of the build of a project so I'm not sure what is the benefit of uploading extra content (such as build products) with it and separated from it.
In any case the way the pod client handles pods is by searching for a proper entry in the index (i.e. everything that's under .specs in your repo) that satisfies the required version defined in your project's Podfile and then using the address in that index file (which points back to Artifactory in our case) to download the required Pod.
So in other words, anything else you put in the repository which is not a tarballed pod is ignored both by Artifactory and by the pod client.
For MAC users:
Step 1:
brew install gnu-tar
Reason: As default mac uses tar for zipping and which has problems with jFrog artifactory
Usage:
gtar czvf swift-sdk.tar.gz *
gtar czvf testPOD.tar.gz testPOD/testPOD/* testPOD/testPOD.podspec
Note: Make sure unnecessary files not get zipped. For instance if .git present in zip, it creates lot of issues.
Step 2:
Follow official link and video
https://www.jfrog.com/confluence/display/RTF/CocoaPods+Repositories#app-switcher
Some of the useful commands:
For add spec repo to the local machine:
pod repo-art add cocoapods-local "http://localhost:8081/artifactory/api/pods/cocoapods-local"
For repo update:
pod repo-art update cocoapods-local
Push artifacts to jFrog:
curl -uadmin123:123456 -XPUT http://localhost:8081/artifactory/cocoapods-local/testPOD/0.1.0/ -T testPOD.tar.gz
Cocoapod spec repo:
source 'https://github.com/CocoaPods/Specs.git'
Point to spec repo in Podfile:
plugin 'cocoapods-art', :sources => [
'cocoapods-local'
]
Related
Currently we need to work with a library which has been merged into another project. That library has its own podspec and was previously available as a remote pod from its own git repo. After it was merged in the big project, the big project uses that pod with a local path.
We still need that library in our project but fetching the whole "merged" project for that pod does not seem legit.
Is there any way to specify a path in the Podsfile which would be able to retrieve the pod from a folder inside an existing git repo?
As I understand you - you're trying to fetch some existing part of the repo as a cocoapod.
So, if this library is not a pod itself - no, it's not possible. You can install libraries (read frameworks) via cocoapods only if they have a pod published, or created by you locally.
You basically have two options here:
Move this code to git-submodule and use it in both projects
Create a pod by yourself (locally, or publish it) and use it in both projects via cocoapods
The second way is preferable, cause cocoapods themselves save you a lot of nerves during construction or maintenance.
If you want some help on any approach - feel free to ask here.
So far I was working on an app and my Team Lead said not to commit the pod files and I just followed his instructions.
Then our Lead changed and he said to commit the pod file to Git. So I was confused which one to go with.
Should we commit the pod file or not and if we should not then why. Please help me clear on this thing as I went through some articles as well but didn't find any satisfactory answer.
Whether or not you check in your Pods folder is up to you, as workflows vary from project to project. It is recommended that you keep the Pods directory under source control.
Benefits of checking in the Pods directory
After cloning the repo, the project can immediately build and run, even without having CocoaPods installed on the machine. There is no need to run pod install, and no Internet connection is necessary.
The Pod artifacts (code/libraries) are always available, even if the source of a Pod (e.g. GitHub) were to go down.
The Pod artifacts are guaranteed to be identical to those in the original installation after cloning the repo.
Benefits of ignoring the Pods directory
The source control repo will be smaller and take up less space.
As long as the sources (e.g. GitHub) for all Pods are available, CocoaPods is generally able to recreate the same installation. (Technically there is no guarantee that running pod install will fetch and recreate identical artifacts when not using a commit SHA in the Podfile. This is especially true when using zip files in the Podfile.)
There won't be any conflicts to deal with when performing source control operations, such as merging branches with different Pod versions.
Source: Cocoapods
I suggest & recommend, not to commit pods directory(third party source integrated using Pod) in your Git/SVN repository.
Here is sample source, suggesting you, what to commit and not.
Pod is a dependency manager and may have so many third party libraries in it. You project source will become heavier (large in size) and the same will get it downloaded every time a new destination uses it.
You can easily integrate all Pod libraries/files source using command pod install from any source/destination.
There may be different version of SDK, command line tool and cocoa pod in different systems. It automatically handles integration specific libraries supported by SDK tool & command line version, as well as cocoa pod version.
Note: It is not bad, you commit pod files with source code to Git/SVN. But also, that's not good to add dependencies (of third party library) with your code, which is not required and easy to handle using pod on different destinations (systems).
Update: .xconfig files are not required to commit. PodFile is enough and required to commit.
If you are using local development pods, there is an annoying issue if you don't commit the Pods repo.
Assume you are working on a branch and added file X to a local development Pod. So it's added in 'Compile Sources' in the development Pod target of Pods.xcodeproj file.
Now you switch branch to another commit which doesn't have file X. Since you gitignore the Pods.xcodeproj, the file X remains in 'Compile Sources' and causes build to fail.
I'm trying to work with a git repo who's dependencies are configured through CocoaPods. However, my internet connection is rubbish (I'm on holidays) and keeps cutting and interrupting pod install. I managed to install 2 of the 6 dependencies through pod (took all day) and realised I actually have the zips of these frameworks already on my computer. So I added for example LayerKit to my pods directory in the project folder. Then when I run pod install again, it hasn't noticed that I already added the file... Any idea how I can fix this or a better way I can work around this. I really have no idea how pod works, I usually just run pod install and it all works miraculously.
You probably want to create a folder under your project's main folder and place all of them in there.
Once that is done, update your target in your Podfile to look like this:
pod 'NameOfPod', :path => 'Relative/Path/To/Podspec'
That allows you to access the pods locally on your system. The path needs to point to the Podspec file for the pod. Also, make sure you do not alter the directory structure in the pods, as this will likely break them.
Currently I'm working with 2 workspaces: First workspace contains MyLibrary pod, created by the pod lib create MyLibrary command. The second workspace I'm using is my project's workspace which includes the project I'm working on.
Is it possible to integrate MyLibrary workspace inside the second workspace? It will be very helpful as I could see all my code in a single workspace.
Found documentation on this:
Using the files from a local path.
If you wold like to use develop a Pod in tandem with its client project you can use the path option.
pod 'AFNetworking', :path => '~/Documents/AFNetworking'
Using this option CocoaPods will assume the given folder to be the root of the Pod and will link the files directly from there in the Pods project. This means that your edits will persist to CocoaPods installations.
The referenced folder can be a checkout of your your favorite SCM or even a git submodule of the current repo.
Note that the podspec of the Pod file is expected to be in the folder. (http://guides.cocoapods.org/syntax/podfile.html#pod:)
Another important note:
This is awesome for small changes that are made exclusively on existing source files. Adding or removing source files is out of the question because you have no access to the project file. For bigger changes like that, you should open the local project file. (http://www.cocoanetics.com/2014/07/development-pods/)
Great example tutorial can be found here:
http://blog.sigmapoint.pl/developing-static-library-for-ios-with-cocoapods/
Enjoy!
I have some doubt on CocoaPods
I think the 1st rule is that keep Podfile and ignore pods folder entirely. But I am so confused about this after I have used some time
Since I insist on #1, somebody says *.lock should be kept in repo. Do I need do this?
Pods generates some xconfig files, it seem I can't add HEADER_SEARCH_PATH in it ?
if YES, it breaks my rule #1 again. Please see this question the-target-overrides-the-other-ldflags-build-setting-defined-in-pods-pods
some buddies modify codes managed by CocoaPods such as AFNetworking rather than from custom repo. I told him NEVER do this because it will recover to origin version after pod update/install but after pod update/install his code didn't change. that's WHY?
My opinion is DON'T MODIFY EVERTHING IN PODS PROJECT EXCEPT PODFILE
You should always check in your Podfile and Podfile.lock.
Checking in your Pods directory is debatable. If you would like to be able to clone the project and run it without requiring users to have CocoaPods you should check this in. I personally do not check this directory in, instead you just have to run pod install after cloning the project for the first time.
If you want to alter the xcconfig files with changes such as HEADER_SEARCH_PATH you should check this in so those settings don't get overwritten unintentionally. Really the podspec should handle all of these settings so you probably shouldn't be changing much in there.
If you're planning on altering the code included by a Pod you should either check in your Pods folder or fork the repo and redirect it to in your Podfile. Documentation on that here. This way you can specify that CocoaPods uses the given spec but uses your fork instead.
EDIT The Podfile.lock (similar to the Gemfile.lock) stores information on the actual version included during the install. Consider this:
You require a spec like pod 'foo', '~> 1.0.0 in your Podfile.
You run pod install and it installs the newest version of foo matching the semantic versioning conventions (specified by ~>)
You don't check in your Podfile.lock
Another developer clones the repo, the newest version of foo is now 1.0.3.
They run pod install. Version 1.0.3 is installed even though they didn't run pod update.
This information is 'locked' in the Podfile.lock so that to do this you have to run pod update which should be very intentional.