

CocoaPods announces Auth Server - orta
http://blog.cocoapods.org/CocoaPods-Trunk

======
orta
It's a long post but the auth server (trunk) is important for the community,
it has taken about a year to make and should make it super easy for library
authors to update their own libraries without our intervention.

We're really glad to remove the human aspect, some of us can finally get some
sleep again.

~~~
alloy
While on the topiZZzzzZzzzzzzzzz…………

------
neilkimmett
Massive congrats and thanks to all the CocoaPods team for this. Such an
important project in the Cocoa community. New way of publishing pods looks
much smoother.

------
AshFurrow
This is a serious win for the iOS community. A huge step forward in terms of
the maturity of the ecosystem. Congrats!

------
mikeash
While we're talking about it, can anyone explain why CocoaPods is so popular?
I don't understand the appeal at all. Adding third-party libraries is
something I don't do frequently at all, and it's not difficult to do manually.
Automating the process doesn't seem to be even remotely worthwhile.

~~~
alloy
You assume that any code installed through CocoaPods will be created by
‘third-parties’, this is incorrect. Dependencies are simply that. You can use
your own, like many companies have been doing successfully internally. E.g.
[http://dev.hubspot.com/blog/architecting-a-large-ios-app-
wit...](http://dev.hubspot.com/blog/architecting-a-large-ios-app-with-
cocoapods)

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.

~~~
mikeash
It shouldn't be time consuming to manually integrate a dependency either. Add
it to your project and go.

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.

~~~
alloy
> It shouldn't be time consuming to manually integrate a dependency either.
> Add it to your project and go.

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-...](http://guides.cocoapods.org/using/faq.html#cocoapods-is-bad-for-the-
community-because-it-makes-it-too-easy-for-users-to-add-many-dependencies)

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.

~~~
mikeash
I don't understand your "build settings" comment. Why would there be any build
settings originated from a library?

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.

~~~
quesera
> third-party code tends to be of low quality and interact with other third-
> party code in interesting ways.

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.

~~~
mikeash
I don't really see how CocoaPods helps the ecosystem of third-party code or
promotes higher quality libraries over time. The cost of using third-party
libraries is high, so they need to be worth the cost if I'm going to use them
at all, and the vast majority of that cost is _not_ in the stuff that
CocoaPods helps with.

