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.
Related
I have an Objetive-C project that builds an iOS framework. It is currently in a subfolder in a git repo hosted on github. I want to distribute the code that is in the iOS framework as a Cocoapod. I have a couple of specific questions.
First, do I need to make a separate repo with just the code for the framework?
Second, does Cocoapods always build my code into a static library? It is OK if that is the case - static libraries are fine - but I'll have to make changes that affect other projects if we are switching from a framework (which is ultimately a dynamic library) to a static library. I would prefer to know whether it is possible to have Cocoapods build a framework and whether that is a good idea or more trouble than its worth.
Thanks!
I'll tell you what I've done in my projects.
I have an Objetive-C project that builds an iOS framework
So you already know hot to make a framework. Otherwise I would have suggest you to read these wonderful tutorial from www.raywenderlich.com
https://www.raywenderlich.com/5109-creating-a-framework-for-ios
https://www.raywenderlich.com/2430-how-to-create-a-framework-for-ios
First, do I need to make a separate repo with just the code for the
framework?
For my development
I've done a separate repo with all the framework/library (shared code) and added it as a git submodule in my project(s).
git submodule add https://github.com/me/MyFramework
When I brand new clone my project I init my submodules with this commands:
git submodule update --init --remote
git submodule foreach git checkout master // this only if you wanna the master commit and not be in a detach state
You can also lock a submodule to a particular commit or tag or branch of your separate repo by adding
branch = commit|tag|branch
in your .gitmodules file
I've made the framework as a Framework Pod as explained here:
https://www.raywenderlich.com/5109-creating-a-framework-for-ios
And I use it as a development pod by specifying in my main project Podfile the path as a relative pat '../my_framework_pod'
platform :ios, '12.0'
target 'MyMainAwsomeProject' do
use_frameworks!
pod 'MyFramework', :path => '../MyFramework'
end
If you wanna import it not as development pod (the code will be readonly) you could put the git repo URI instead of the relative path.
Second, does Cocoapods always build my code into a static library?
To be honest, I've always seen it as a static library. But this is the static library of the whole of all the Pods you are using in the main project.
But it should be quite painless for you as you need only to change how to use it. By adding your framework to the Podfile along with all the other Pods you are already using.
You would add it only to your main project Podfile and when you type pod install it's up to the pod command to create the correct workspace.
Hope to have shown you a valid and nice journey to make.
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.
This seems like something that should be done very easily. I don't know why I just can't seem to find a simple answer to that.
I am creating a pod library that has a pod dependency.
So in my .podspec, I have a s.dependency 'SomePod', '~> 1.0'. Since I am writing my library using SomePod, I want the source files from it in order to import it and use it. Sure one way to do it is to have a PodFile in the repo and then pod install the SomePod.
But is there some other way to download the somePod dependency so that I can use it in my library? What is the best practice around that to have a clean structure?
FYI, I am using the Cookie Cutter library in order to generate all my project structure. What's left for me to do is download those podspec dependencies and avoid using Podfile and pod install since I already have a .xcworkspace generated from Cookie Cutter, so pod install won't like that and will go crazy.
Well you could handle the dependency management with other Tools (Carthage etc.) or simply on your own (git clone + project integration), but as you are already providing a podspec for your lib, why not just stick to cocoapods for third party lib integration?
This would be the typical approach for your setup, as you just need to write a simple Podfile, assure that SomePod is fetched with the same version as defined in podspec and call pod install.
Advantages:
you can still watch third party sources
you can debug into third party lib
you can compile, test & debug against the exact same version of SomePod that will be fetched from a client project of your lib (no need to keep versions manually in sync)
I've read all the tutorials (some less deeply than others), and discovered that there is a huge focus on using the pod lib create command and how to get your new cocoapod into the the podspec repo and available to other developers, but they are all missing the middle part involving actually setting up and developing your pod, Xcode example project, etc..
I'm trying to make a cocoapod for internal use that has dependencies on other pods. I told pod lib create that I wanted an example project and now I need to be able to build and run it using the pods it depends on. I'm not clear on how I actually get those pods to download. I understand that there is a podspec syntax for specifying dependencies:
spec.dependency 'SOMEPOD', '~> VER.0', but that doesn't do much for my example project.
Am I supposed to make a Podfile in the folder with my example project? Does that conflict with the podspec somehow? Do I need to include the pod I'm making in that podfile? Should I not be using an example project and just be developing my pod in conjunction with a test project that pulls my pod in like any other cocoapod?
Also, when all my testing is said and done, does the example project get distributed with the pod and set up as a weird sub-target in whatever project uses the pod? Or do I eventually have to make a different repo that just has the pod (without the example project)?