Currently, in our company, we just commit all pods (like AFNetworking, Realm, etc) to svn/git. From time to time, when other developer install pod, update pod, there are conflict.
We also use this so that we don't touch other pods.
pod install --no-repo-update
Can I know what is the good practice for using third party pods? Do I need to commit those pods?
Or just do pod install again after our codes are checked out ? I just want to avoid code conflict for using pods.
You can refer to http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control
Whether you check in or not, the Pods directory, the Podfile and Podfile.lock should always be kept under version control. It is recommended to keep it under version control and don't add it to your .gitignore
We also faced the same problem.As a solution, in commit we write only pod file with required pod list . Whenever other person take update, his podfile is updated and then from console he update his project pods.
As pod is same for all so you dont need to commit the pods. for more specific you can you can give pod with version.
Khant usually it's not a good practice to upload your dependencies to your repositories mostly because your will be saving space and time. it's ok to push your Podfile but all the code of your dependencies should be omitted and installed locally for each developer. And each time a new dependency is added or update you will just need to run the pod update command. to do that you can add to your .gitignore file on a new line just Pods/.
Either way if you are working on a big scale application you should on swift you should follow the best practices and use a correctly .gitignore setup like this one example and also if you want to know some pros and cons on avoiding Cocoapods dependencies you can check this official documentation
In my opinion, we don't push all pods to svn or git. You can commit only Podfile and may want to freeze to a specific version of a Pod, in which case you can specify that version number.
pod 'Objection', '0.9'
And when other members install pods, it will be same.
Related
I want to remove specific dependency using cocoapods. if I execute pod install, other dependencies are getting updated before removing the dependency I want to delete. I just want to remove specific pod without touching any others. And I know deleting, updating any dependency also updates others. Is there any way to solve this problem?
Actually my problem is when I modify some dependency (AFNetworking for example) and run pod install it reverts back to its original version. But I don't want to lose my changes.
Remove specific pod from podfile and run below command in terminal:
pod install --no-repo-update
pictorial representation with steps detailed.
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 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.
I'm working on a private pod, with a few other engineers. This pod is used by a few projects.
I've set up the private podspec repo properly, and everything works, but my git tags are climbing at a rapid pace. I feel like there must be a better way to approach this, just unsure about how to proceed. Here's what I'm doing.
Change code to private pod.
pod spec lint.
Assuming this succeeds, then
add git tag to repo for private pod.
change version in podspec file, and change tag in podspec file.
pod repo push ....
Then in my main app that uses this:
6. pod update
While this all works, it does cause me to escalate my git tags very rapidly, even a good amount of these tags, and pod versions, will never be used. Also, if another project does a "pod update", then it will get this latest version, even though I haven't tested it fully on my target app.
Just wondering if there's a workflow where I could use my private pod, make changes to it, and test it with my target app, and once I'm satisfied, then tag & push the podspec.
I guess basically, I want to "branch" my podspec until I'm sure it's ready, and then only release it to the group by performing the versioning & tagging.
Thanks for any tips on a good workflow.
-Dan.
You don't need to use tags to reference your code in pod file. You can also use repo 'head' and once the code is stable create a tag and use it. For reference Using Pod file. Look for pod 'Objection', :head in the document and read the relevant part.