CocoaPods announces Auth Server • Hacker News Board

Re: CocoaPods announces Auth Server

#21

Post by mikeash » Thu, May 22, 2014, 12:12 AM UTC

quesera wrote: post #19

mikeash wrote: post #18

Earlier quoted context omitted.

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…

> 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…

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.

Re: CocoaPods announces Auth Server

#22

Post by mikeash » Thu, May 22, 2014, 12:16 AM UTC

alloy wrote: post #20

mikeash wrote: post #18

Earlier quoted context omitted.

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…

> I don't understand your "build settings" comment. Why would there be any build settings originated from a library? 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 > […] > Yo…

I don't refuse to use third-party libraries out of hand. If something is good, I'll use it. However, my assessment of the cost/benefit tradeoff differs from others. Take, for example, AFNetworking. It seems to be the gold standard for any iOS app that makes web calls, to the point where it's practically a default first step when making a new project for many programmers. Me, I don't understand the appeal. The cost is enormous due to adding a huge quantity of code (and therefore bugs) to your app, and the benefit over using what Apple provides is tiny.

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.

Re: CocoaPods announces Auth Server

#23

Post by Manfred » Thu, May 22, 2014, 5:59 AM UTC

quesera wrote: post #16

alloy wrote: post #12

Earlier quoted context omitted.

> editing my Xcode project files underneath me creeps me out 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.

In fairness to CocoaPods, I should clarify: 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 thi…

Unfortunately this is a problem with most monolithic tools. The only sensible solution is to keep points of integration as minimal as possible so you can adapt when there are changes.

Minimalism combined with the fact that CocoaPods has a pretty large active community we should be able to adapt if large changes do occur.

Re: CocoaPods announces Auth Server

#24

Post by al45tair » Thu, May 22, 2014, 11:52 AM UTC

mikeash wrote: post #22

alloy wrote: post #20

Earlier quoted context omitted.

> I don't understand your "build settings" comment. Why would there be any build settings originated from a library? 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 > […] > Yo…

I don't refuse to use third-party libraries out of hand. If something is good, I'll use it. However, my assessment of the cost/benefit tradeoff differs from others. Take, for example, AFNetworking. It seems to be the gold standard for any iOS app that makes web calls, to the point where it's practically a default first step when making a new project for many programmers. Me, I don't understand the appeal. The cost is…

Agreed. CocoaPods might be useful if there were a lot of high quality library code out there that we could use, but right now, like Mike, I just don't see it.

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.

Re: CocoaPods announces Auth Server

#25

Post by escoz » Thu, May 22, 2014, 2:55 PM UTC

al45tair wrote: post #24

mikeash wrote: post #22

Earlier quoted context omitted.

I don't refuse to use third-party libraries out of hand. If something is good, I'll use it. However, my assessment of the cost/benefit tradeoff differs from others. Take, for example, AFNetworking. It seems to be the gold standard for any iOS app that makes web calls, to the point where it's practically a default first step when making a new project for many programmers. Me, I don't understand the appeal. The cost is…

Agreed. CocoaPods might be useful if there were a lot of high quality library code out there that we could use, but right now, like Mike, I just don't see it. 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 pos…

>> incompatible license...

You can always just continue to use the same version of the library you always used.

Re: CocoaPods announces Auth Server

#26

Post by alloy » Fri, May 23, 2014, 11:46 AM UTC

al45tair wrote: post #24

mikeash wrote: post #22

Earlier quoted context omitted.

I don't refuse to use third-party libraries out of hand. If something is good, I'll use it. However, my assessment of the cost/benefit tradeoff differs from others. Take, for example, AFNetworking. It seems to be the gold standard for any iOS app that makes web calls, to the point where it's practically a default first step when making a new project for many programmers. Me, I don't understand the appeal. The cost is…

Agreed. CocoaPods might be useful if there were a lot of high quality library code out there that we could use, but right now, like Mike, I just don't see it. 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 pos…

CocoaPods has been generating aggregated lists of licenses of libraries that you use in your app since a very long time, I don’t know of any other system that people use to pull-in dependencies that does this.

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.