I want to know which files created by CocoaPods in a given iOS project should be checked into version control. What makes most sense to include and ignore? Should I just add the Podfile? Or should I add the entire pods directory?
This is an ongoing debate even with the CocoaPods core team. https://github.com/CocoaPods/guides.cocoapods.org/issues/3
At some point someone felt that it should be ignored enough to get it into Github's gitignore template for Objective-C.
Some good points were brought up in the linked debate above about longevity of the project where if you check in your pods directory in the future other developers should always be able to build the source regardless of the state of CocoaPods or the specs repository without any dependency on the command line too. But I could see you having this same issues with Git submodules since the remote repositories could be deleted in the future as well. I think this comes down to your preference. Personally I don't like having updates to external dependencies directly in my source control history.
Related
I'm writing a project that uses a range of 3rd party iOS libraries (e.g. TWStatus, BSKeyChain), some of which I've modified (up to 10% custom code), but wouldn't be suitable for the original GitHub project.
I thought about future updates from the library authors, and came across CocoaPods today, which looks to be a good dependency manager in the same vein as Bundle or Vundle (for Vim).
I'm curious whether it's possible for my custom code to co-exist with future changes by the library authors using CocoaPods??
CoocaPods by default pulls in a library as source, along with instructions to build that library. (There are some exceptions for close-sourced libs). So this makes it easy to debug issues and test changes out within the context of your project.
Having decided on a change, you should do one of the following:
Submit the change back to the master library. You'll get the benefit of easily being able to upgrade to new versions that include all of the testing provided by the wider community. The easiest way to to do this is to fork the library, apply the change, and send a pull request
If your changes aren't really of benefit to other users of the library, you can just fork the library, without submitting the change back up to master. If the license permits you can maintain a private fork, and still resolve it from CocoaPods. To do this:
Podfile:
#As long as the pod-spec is published at the root of the git repo, this works.
pod 'MyFantasticLib', :git => 'https://github.com/dogue/Doguetastic.git'
#. . and you can use this lib while you're waiting for your pull req. to be approved.
You could also consider setting up a private spec repo.
The first option is usually the best.
So, to be clear.
You've made changes to a dependency
You also want to keep those dependencies up to date.
--
Seems to me this would be a pain. You'd need to merge the new stuff into your own version for every update, for every pod/dependency.
However, if you've made changes... do you really need to? Consider using the adapter or façade pattern to write a wrapper around them, and then you can update them as much as you like (assuming their interface doesn't change).
Just some thoughts
I am looking for the best way to share a "common" Xcode project amongst multiple developers on multiple apps. One developer will be working on the "common" Xcode project, while another developer will be working on a project that will use the source from the common code Xcode project.
Where I am stuck is how to set this up with both Xcode and Git so that when the developer of the common code library makes a change, the developer that uses that library will not have delete and re-add the Xcode project, or lose their work.
I have looked at some documentation with Git submodules, but there is a lot of debate around the topic and its usefulness. Are we better off just having one Repository with ALL the code for all the projects in it, that way everyone checks-in/out of the same place?
Thanks for the advice and pointers!
There is no "best-way" in software development. There are always a number of solutions to any problem. The trick is working out which solution best fits you. Int his case there are a number of factors to consider - how your developers like to work, what sort of experience and back grounds they have, how you want to manage the code, etc.
I think there are a few solutions you need to consider. Pick one and try it out, but don't be afraid to change if you find it doesn't work or hack it around to suite your needs.
One repo. Not usually considered the best solution because it restricts the ability to reuse code on other projects. In XCode you tend to end up with numerous build targets and highly complex builds. This can become un-manageable quite quickly. Also tends to make versioning difficult and can break things quite fast.
Multiple repos and static libraries. There are a number of variations on this. The repos can be managed by Git independently or you can employ submodules. I would seriously consider breaking code out into projects that build static libraries. Using XCode workspaces you can have a number of projects open at the same time and arrange them as either siblings or nested child projects. This depends greatly on what and how you want to build them. Using Git submodules has the advantage that the submodules are effectively versioned which means that make changes to a static library project is not going to break everything that is using. The downside of using Git submodules is that they (IMHO) are not the most user friendly part of Git and take some getting used to. A good Git client is most useful in this. Sourcetree is free, but (again IMHO) Tower is easier to use and handles submodules better than Sourcetree.
Using Cocoapods. Cocoapods is like using Maven or Ant for Xcode. It an makes things quick and easy to get running and automatically handles dependencies. However it also messes with the XCode project files, often requires manual intervention, adds additional compilations that you may not require and depending on how you setup your builds, can get in the way. Figuring out how to control the way it plays with your project files can also take some time. A lot of people like Cocoapods because it's initially easy to use and doesn't require the technical knowledge that Git Submodules require. Personally I'm not sure that bringing Java dependency management ideas into Xcode is a good idea in the long run.
The way we share common projects/libraries is through the use of private Cocoapods. Its not pure git, but cocoapods do use git. You can read the official documentation on how to set up a private podspec repo : http://guides.cocoapods.org/making/private-cocoapods.html
There are also loads of possibly simpler explanations on how to set up a private podspec repo like this one
We have a project that utilizes SVN for source control, as necessitated by company policy. The project depends on about a dozen external libraries, which are found publicly on github. Until now, we've simply been downloading a zip file of each library we use, then add the source code directly to our project, but this is bad practice for obvious reasons.
We would like the ability to update the external libraries, and use them in other projects as well. Additionally, we will modify some of the libraries, and would like to be able to merge in changes as the main branch of the library updates.
How would one go about setting up this kind of project? I had thought about forking each git library, but I'm not sure how I would add the dependency to xcode and have SVN properly include the libraries. I've also looked at cocoapods, but if I'm not mistaken, they seem to be more for read-only dependencies.
Use a python based build system and install pysvn and one of the python git bindings - your build system can then handle (inter-)dependencies cleanly.
I have an environment where I'm building several library solutions in TFS. At the end of the build process the script packages them into a NuGet package and pushes them to our local feed.
Now we can include these libraries, which change little day-to-day, in our upstream projects.
These libraries as well as our upstream projects generally are branched at the same version. Basically the trunk is our evolving latest version. Say before branching the trunk is 3.0.0.123, 123 being a running build number. At some point we mark the current trunk as what we're going to release and branch it. The version number of the trunk at the time of the branch becomes the version of that branch and we would increment the version in whatever appropriate manner for the trunk to what we would feel is likely going to be the next release (say 3.1.0.456).
This presents a slight oddity to how we'd like to use NuGet. We would want that the branch, 3.0.0.456, use the lateset library from the branch (perhaps 3.0.0.457) and the trunk to use the latest from the trunk (3.1.0.789)
So what this basically boils down to is can we setup the versions for a solution using NuGet to be similar to the manner NuGet uses when defining dependencies within a package?
Ideally, I'd like to tell the branched upstream application to use [3.0.0.456, 3.1) and the trunk to use latest (no version). In this scenario it would pick up the branch would pick up the next branch build (3.0.0.457) and the trunk would pick up whatever the last NuGet package that was published to the feed.
The only idea that I've come up with as a possible solution is using parameters for the build template and using that to update the package.config file before the NuGet targets are run.
I appologize if this should go on SuperUser or elsewhere...
After doing some digging to have my build do some auto creation of packages for our library projects I came to the (wrong) conclusion that this was a limitation of NuGet. I parsed their source for any XSD documents to describe their XML so that I could see how their nuspec worked.
While I had their source I started looking into how I could modify the package.config file to accept their schema for limiting versions. After some digging I found an attribute that can be added to the package node in package.config: allowedVersions. This is exactly what I was looking to add!
Once I had this piece of information I was able to dig a little deeper into how it was implemented. Turns out that this functionality has been around for a while and is even documented on their docs site: http://docs.nuget.org/docs/reference/versioning
It is in the dependency versioning guide located at the bottom. I must have completely glossed over it or never read that far!
Turns out that this was a non-issue and the only problem was my ignorance. Just a reference for any Googler's out there that land on this page!
SOURCE (LOCATED AT BOTTOM OF PAGE): NuGet Versioning
I'm attempting to use some 3rd party libraries in my iOS app, as recommended by the SoundCloud API. I followed their tutorial, running git submodule add on each of the required dependencies.
However, when compiling, I had to make some tiny tweaks to the dependency projects in order to get them to link correctly - purely in the project settings.
I have never used submodules before, but from what I've heard, the parent repo tracks a particular commit of the submodule, right? If I want to include the little tweaks to the project files of the 3rd party libraries, so that a team member can pull it from origin, does that mean I will have to fork each of the dependencies first and commit each of the little project settings, just so that they can be included in the main repo? Or can I make "local" changes to the 3rd party libraries, and then push the main repo to origin?
This is quite frustrating, since I'm not actually changing the 3rd party libraries per se, it's purely a setting I've had to change so that they work correctly with my specific project. Is there a way I can include tweaks in the main repo without forking each library in their entirety?!
Thanks!!
You will have to put your modifications somewhere so that others can get them. This gives you two options, both of which start with the word "fork".
Fork the repo and maintain it.
Fork the repo and then make your changes so that everyone could benefit from them (eg, make the option you had to change into done sort of configuration parameter), then send a pull request back to the original. After it gets accepted, you can get rid of your fork, and others in your situation won't need to do this dance.