search

wit-ai / wit-ios

Wit.ai iOS client
Other
222 stars 71 forks source link

Limit the use of CocoaPods or fix ReactiveCocoa #4

Closed KyleLeneau closed 10 years ago

KyleLeneau commented 10 years ago

Using CocoaPods limits the number of developer who can or want to fix your library. I am in that camp since I think CocoaPods are un-necessary in the world of Git and Git submodules. Follow github's objective-c API's (OctoKit) and using Submodules and a script instead.

I am really noting this because I can not clone your repo and see the source because of this CocoaPod error:

"An error occurred while processing the pre-install hook of ReactiveCocoa/Core (1.3.1).

invalid byte sequence in US-ASCII"

blandinw commented 10 years ago

Will getting rid of ReactiveCocoa fix your issue? CocoaPods seems to be quite popular among iOS developers, and I am still not convinced we should get rid of it. I'll look at OctoKit later today, thanks!

KyleLeneau commented 10 years ago

Probably but my point about CocoaPods is that if you are going to just publish a framework for people to download and install/use then CocoaPods only benefits the developers working on this SDK. Since your dependencies should be to a minimum (if any) then I don't see the benefit of CocoaPods.

KyleLeneau commented 10 years ago

Oops, I might be wrong about that. I guess I'm not sure how you are producing the Framework to upload. Are you using Archive or just Build?

blandinw commented 10 years ago

We use Build and follow the steps in https://github.com/jverkoey/iOS-Framework

hactar commented 10 years ago

I definitely vote against any dropping of CocoaPods. It has become the defacto standard of iOS based development and offers many advantages that I won't list here but can easily be googled. Kyle is right though about making sure to only use minimal dependencies. I'm about to submit a pull request which reduces the AFNetworking dependency to only the required submodules.

blandinw commented 10 years ago

We ought to be able to satisfy everybody here!

Regarding AFNetworking, I have a commit almost ready that removes the dependency and directly uses NSURLConnection. Hope you guys can comment on the correctness when it's live.

Regarding CocoaPods, my experience from other ecosystems is that many people expect every popular lib to be available in the defacto package management system (be it RubyGems, npm...). As long as it doesn't hinder integration for other users, I think that's the way to go.

blandinw commented 10 years ago

I pushed 3145654. The SDK has no dependencies now. I also fixed a bug in the recording/streaming code.

I'll close the other related issues to centralize the discussion here. I'd be glad to hear feedback and comments.

Thanks to both of you!

KyleLeneau commented 10 years ago

As for CocoaPods I should note that I am just not a fan of them. Everything that you are doing here can be done with submodules especially since you are producing a static library that you expect people to use/download. If you were like other open source projects where a developer would consume and build you source then CocoaPods make perfect sense. It's only my opinion to remove as many barriers to contributing developers in the open source world as possible.

Either way, as long as this project stays active and static libraries keep getting produced (incurred maintenance cost) than I don't see an issue in how any project manages it's own dependencies.

hactar commented 10 years ago

I hope this doesn't turn into a submodule vs CocoaPods debate, yes there are people who don't like it, but you'll always find someone who doesn't like something, and he may even have a valid point, but the advantages of CocoaPods, and its popularity, clearly outweigh the very limited disadvantages. Calling "CocoaPods" a barrier is like calling "apt-get" a barrier. Why use apt-get on linux when you can download the source files yourself? CocoaPods is a barrier remover, it allows you to safely rely on other peoples code (and it doesn't even have to be on github) so that you don't have to write every little bit of the framework yourself - thus allowing you to make bigger strides in your framework, quicker. It greatly reduces the overhead in creating a new iOS project.

But don't take my word for it. Have a look at the top trending objective-c github projects this month (specifically, the iOS projects): https://github.com/trending?l=objective-c&since=monthly

Bolts: Uses CocoaPods CRToast: Uses CocoaPods CCHMapClusterController: Uses CocoaPods AFNetworking: Uses CocoaPods

The list goes on and on. Some depend on other CocoaPods, some just provide a podspec. But chances are that anyone planning to contribute is using CocoaPods already, hence the barrier would be to force people that want to contribute here to not use other CocoaPods.

hactar commented 10 years ago

BTW just to add, and because this is the internet and misunderstandings quickly occur: I respect @KyleLeneau's opinion, and yes, submodule only has it's advantages too, I just don't agree with it, and I'm sure there are lots of others who in turn don't agree with me. Don't want to start a flame war, just adding my two cents, will shut up now when it comes to this subject and abide by any decision the Wit team decides to make, especially since this is open source and anyone can fork and do what ever he or she wants anyway :)

blandinw commented 10 years ago

Thanks for your inputs, gentlemen! I'm glad everyone could express their opinion. For now, we think the best compromise is to keep using CocoaPods and provide .framework releases, despite the maintenance cost.