I have a question regarding cocoapods' development pod.
I find a source file in 'development pod' which contains a bug that I need to fix.
I know how to change the codes to fix it, but I am not quite sure how to fix/patch the file itself so that when I redo pod install later, it sustains the changes I made.
After some research, I figured out that I can fix/patch pod file by using https://github.com/jpsim/pod-diffs/blob/master/README.md
However, the file I like to fix resides in Development Pods.
According to https://guides.cocoapods.org/making/using-pod-lib-create,
Development Pods are different from normal CocoaPods in that they are
symlinked files, so making edits to them will change the original
files, so you can work on your library from inside Xcode.
Does this mean I can safely make modifications in the file itself to fix the bug?
Sorry, I am not familiar with fixing Pod files. Any help will be appreciated.
Yes, this would work. When using a development pod, running pod install will not overwrite your changes with whatever is in the pod's repo, but instead will use the code as specified in the :path of your development pod.
When you do this, you should a) put the development pod under your own version control (usually in a fork of the original pod), and b) consider offering your fixes upstream via a pull request.
Related
I am new to CocoaPod and IOS in general, I am trying to use a framework I built locally in my podfile as follows:
# Pods for Example
pod 'OsonWidget', :path => "../OsonWidget/"
when I run a pod install and open the .xcworkspace of the project, the framework gets saved under Pods/Development pods. So my question is what is Development pods
Normally in Podfile you point to the repo with its git name and your intended version.
You’re not doing that. Instead you are pointing to the pod by the :path identifier in the Podfile.
Other than the two ways mentioned above, there are other ways to point to a repo.
Obviously you are locally pointing to a pod, ie the pod was not fetched from the actual repo, implying that you own the pod and you’re developing the pod, you want to make changes to it and immediately see how the changes work for you in your Example app. Hence it’s named ‘development pods’.
Any change you make will be reflected into the Example project. Though if you add a new file, then you need to run pod install again so the projectfile gets updated.
This is slightly different from other dependency managers where the term 'development' is used for dependencies that are necessary for testing, benchmarking, and other developer tasks. Example with Ruby Gems, you have add_development_dependency vs. add_runtime_dependency
With CocoaPods the decision to use something as development vs. deployment is per file i.e. whether or not a pod/framework imports a file.
This all means you could have a file in your test target i.e. only import the pod in your test target and never include it in production e.g. the KIF pods. But mainly if you import a pod in your production code, then you'd need to import it again in files you have under you unit test target.
I did some digging on cocoapods.org, and found this snippet:
Development Pods are different from normal CocoaPods in that they are symlinked files, so making edits to them will change the original files, so you can work on your library from inside Xcode. Your demo & tests will need to include references to headers using the #import <MyLib/XYZ.h> format.
https://guides.cocoapods.org/making/using-pod-lib-create
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.
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.
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.
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.