CocoaPods announces Auth Server
blog.cocoapods.org
blog.cocoapods.org
We're really glad to remove the human aspect, some of us can finally get some sleep again.
CocoaPods also functions as a discovery engine. The experience is very unpolished, but it will surface the code that other people have written with the explicit intention of offering as a library to other people. Which is a subset of "code other people have released on github", obviously.
I'm a skeptic too. I've played with it, but requiring a couple dozen additional ruby gems and editing my Xcode project files underneath me creeps me out, so I won't use it for personal or client work.
I've been hired into existing projects that used it though, and it works fine as long as you manage it as a glorified drag-n-drop. You can blow yourself up if you trust it like a vendor-approved auto-upgrade mechanism. That's as much a factor of the ecosystem as the tool, and I hope Pods and Pod authors will coalesce around a level of maturity that's useful in shipping code environments.
That's the least usable way to do it, though. Use static library projects in submodules and a workspace/nested projects, and updated submodules will Just Work (unless there are breaking API changes, but Cocoapods can't help you there).
The main advantage of Cocoapods is shared dependencies. If you don't have those, it doesn't offer you much besides a non-git-native way to manage dependencies. Also, not having to manually edit your Xcode project to get the correct, single component path (instead of an absurd relative one) for a static library after changing to BUILT_PRODUCTS_DIR (why this has never been fixed, I have no idea).
Obviously this is not fool-proof and many are still getting used to it.
You can use the `--no-integrate` flag and it never touches your project, leaving integration of the Pods Xcode project up to you as you see fit.
It's not simply that Xcode project files are edited that creeps me out. Cocoapods is actually trying to solve a complex problem, more so than other package managers like RubyGems or Pip or CPAN. Project files will therefore need to be edited.
It's really the fact that Xcode makes it inconvenient to do the work CocoaPods is trying to accomplish. I do trust you guys to do things right, I do not trust that Apple will keep your needs in mind when they make changes to Xcode.
There are features of CocoaPods that I just don't use, preferring to perform things manually. I don't use those features mostly due to the concerns described above, and my comfort level with doing them myself. If I did break my habits and use those features, the convenience might outweigh the complexity introduced.
I'd love to see Apple explicitly target CocoaPods compatibility as a beta testing goal.
I hope to see the day that they will sanction a small format around clang modules, we can always hope :)
Minimalism combined with the fact that CocoaPods has a pretty large active community we should be able to adapt if large changes do occur.
Regarding “it’s not difficult” to do; Indeed it’s not, but it can be time consuming when you do want to quickly try out some libs. Especially once you have committed them to SCM and later on decide to remove them, because they weren’t what you wanted after all. This becomes even more a factor if you want to see a community that builds stuff together, instead of everybody re-inventing the wheel and/or vendoring their dependencies inside their lib leading to the mess that brings (at linker and runtime level), because then you need actual transitive dependencies and calculate a graph.
It is my experience that the lack of a tool and an ecosystem, such as CocoaPods, has led to the Objective-C OSS community staying minimal, in terms of working together. This can be noticed by the instant feedback people get on their projects when they release a library through CocoaPods and the decline of monolithic frameworks.
Whether or not your situation asks for this is another question. In consulting you’ll notice the benefit of quickly adding your dependencies, while on your own (single) product that’s probably a negligible amount of time. YMMV and all are fine.
I further don't understand how it's a problem if you commit them to SCM and then decide to remove them. If you decide to remove them, then remove them, and you're back where you were.
Perhaps this is the gulf in understanding: when you talk about transitive dependencies, my immediate reaction is that if you have so many different dependencies and dependencies-on-dependencies that it becomes difficult to manage by hand, you're doing something terribly wrong and setting yourself up for a world of pain.
I’m not going to play the yes-no game with you on this.
> I further don't understand how it's a problem if you commit them to SCM and then decide to remove them. If you decide to remove them, then remove them, and you're back where you were.
You will have to spend time to figure out which build-settings originate from which library. Or you do it properly upfront with a xcconfig, which also costs you time.
> Perhaps this is the gulf in understanding: when you talk about transitive dependencies, my immediate reaction is that if you have so many different dependencies and dependencies-on-dependencies that it becomes difficult to manage by hand, you're doing something terribly wrong and setting yourself up for a world of pain.
You’re simply making too many assumptions then. Also see: http://guides.cocoapods.org/using/faq.html#cocoapods-is-bad-...
I’m still planning to port that old blog post, by my then-colleague, to an iOS context and post it on our blog. This assumption you make is a common one and tends to leave sour tastes with everyone.
As for "making too many assumptions", it sure would be nice if you could, say, explain yourself instead of just saying I'm wrong and that my wrongness upsets people. Your FAQ link doesn't explain anything.
To explain my side: third-party code tends to be of low quality and interact with other third-party code in interesting ways. When things go wrong, and they always do even with the best programmers and the best code, the more bad third-party code you have, the more you have to dig through to find and fix the fault. This objection largely goes away if you only use dependencies of extremely high quality, but to be brutally honest, there aren't enough such projects out there to be able to make a mess from them.
Absolutely. There are less than a half dozen libraries I'll use without hesitation. The others get evaluated carefully on author, size, criticality, and my domain knowledge, with the default choice being: "no, don't want to deal".
But that's a criticism of all package managers everywhere, and I think it's clear that popular ones promote higher quality libraries, over time.
CocoaPods is young yet. Package management for compiled and linked executables might turn out to be too hard or wrongly marketed. But a strong ecosystem of third party Objective-C code is a laudable goal.
Your project might need to link against frameworks/libraries that the dependency requires. Your project might need certain search path. There are more, but I hope you understand what I mean now.
> As for "making too many assumptions", it sure would be nice if you could, say, explain yourself > […] > Your FAQ link doesn't explain anything
You hear “transitive dependencies” and you assume somebody is “doing something terribly wrong”. I’m saying that that’s not necessarily the case and in the FAQ item that I linked to I state that I’m against the scenario that you assumed.
The blog article that is linked to from that FAQ item goes into more detail about why it’s good to keep it to a bare minimum. (More on that below.)
> and that my wrongness upsets people
I wasn’t referring to you specifically, but rather to people on both sides (for/against) discussing this topic in general, which was the premise for me needing to ‘port’ that blog article. It was a side-node and I see how it could be taken the wrong way.
> To explain my side: third-party code tends to be of low quality and interact with other third-party code in interesting ways. When things go wrong, and they always do even with the best programmers and the best code, the more bad third-party code you have, the more you have to dig through to find and fix the fault. This objection largely goes away if you only use dependencies of extremely high quality
I already knew what you meant, this is not the first time I have this discussion :) But I should have been more explicit:
When we talk about dependencies that were created by a third-party, so _not_ dependencies per se, you are completely right and we are in full agreement. To quote from the blog post:
“Minimal dependency is not just about the number of libraries you use,
but also about the total amount of code you pull into your project.
Less code means less bugs.”
I doubt you checked all of them, but seeing as everyone makes mistakes in their own code, I think it’s fair to assume that there is a lot of code that could be improved.
Where we seem to differ, but tell me if I’m wrong, is that you in principle choose to not deal with any of them, probably because it wastes time (?). Whereas I prefer to choose a small one that does (almost) exactly what I need and (almost) is where I want it to be code-wise and then contribute to that project, instead of starting over.
To facilitate the mentality that I and many others have, it helps to have a tool and ecosystem that makes libs discoverable and ‘simple’ to build upon/together.
If the cost/benefit tradeoff appears worthwhile, taking into account the large cost from adding any third-party code, I'm happy to make it. It just doesn't happen very often.
To me, CocoaPods doesn't move the needle on the cost/benefit tradeoff, because the cost of what CocoaPods handles is extremely small compared to the total. Thus why I don't really understand the point of it. It takes something that's infrequent and already easy, and makes it a little easier.
The main use-case I can see for something like CocoaPods actually has to do with commercial library code---i.e. code that you purchase and for which you get proper support.
I'll also add this: CocoaPods, as it stands today, also creates a risk, in that it's possible that an updated version of some library you're depending on might have a different license---maybe one that's incompatible with the license for the software you're working on. As far as I can tell, CocoaPods has no mechanism to deal automatically with this issue, which makes its use in commercial projects dangerous IMO.
You can always just continue to use the same version of the library you always used.
We also only accept libraries that specify a license. This has lead to many more licensing issues being clear than before people used CocoaPods.
We are, however, definitely not going to build in functionality that would give you the green or red light, because it’s impossible to do this right in an automated fashion. In the end, any licensing issue is your responsibility regardless, of how you pull the code in.