5 ms·

Cocoapods: An Objective-C library package manager

67 points by jamesjyu 15y ago

samsoffes 15y ago
I am crazy excited about this. With the growing number of Objective-C libraries, this will make things so much better.
gfodor 15y ago
I wonder why the author didn't go for the obvious pun, Cocoabeans? Oh, wait, I think I know why. :)
- alloy 15y ago
  Starts with “J” and ends with “ava” ;)
aphexairlines 15y ago
There are already package managers that have been developed for years (ie: hard problems solved and bugs ironed out), can track dependencies across languages/runtimes, and have large cross-language communities. Cocoapods isn't even cross-platform. It's only for iOS libraries, which means it only works on macs, which means it won't offer much beyond mac package managers. So use macports, or fink, or homebrew, or nyx.
- jballanc 15y ago
  You're missing the point. This is not a tool for end-users, but rather for developers. iOS/OS X already have a means of distributing third-party libraries with projects (the "./Frameworks" directory), there just has not, until now, been a good way for developers to find and organize these libraries during development. The goal of this project is to give developers that way of sharing, discovering, and resolving dependencies of libraries, but at the end of the day everything will still get packaged up as a "*.app" that is distributed via the App Store. Also, the reason to create a custom tool for this instead of repurposing one of the many existing package managers is that it allows for the tool to be specialized for the specific case of developing App Store apps. Sure, you can install a third-party library via macports, but how do you tell macports to compile the library and place the resulting frameworks into the right directory in your Xcode project?
- protomyth 15y ago
  That seems to be the whole point is to provide a specialized manger For libraries on a Mac. Some people don't want a general solution to a specific problem.
- adamjernst 15y ago
  iOS libraries need to be cross-compiled and statically linked. (Dynamic linking is not allowed in apps submitted to the store, IIRC.) I'm sure macports or whatever CAN be forced to do both of these, but it's easiest just to make something new, lean and efficient.
zbowling 15y ago
WOW. you created my idea I posted a few days ago here! http://news.ycombinator.com/item?id=2997247 http://news.ycombinator.com/item?id=2997247
- alloy 15y ago
  ZOMG, indeed! You’re welcome! :D On a more serious note, I had been trying not to create this for about a year now. The release of the boilerplate project made me decide it’s time to finally scratch that itch.
- alloy 15y ago
  Also, please please please start contributing specifications: https://github.com/alloy/cocoapods-specs https://github.com/alloy/cocoapods-specs :)
tomwilson 15y ago
So glad someone has finally done this...
Aqua_Geek 15y ago
Out of curiosity, why the dependency on MacRuby? The only thing I've seen in the digging I've done thus far is the CFUUID stuff, but that is easy enough to recreate in Ruby so I think I must be missing something...
- jballanc 15y ago
  I suspect that you'll see many more benefits of using MacRuby for the project going forward. For example, think about the sorts of things that Bundler (being written in Ruby) can do for Ruby gems that rvm (being mostly written in shell script) cannot.
- alloy 15y ago
  Good question, it’s because of reading and writing the project.pbxproj file through NSDictionary: https://github.com/alloy/cocoapods/blob/master/lib/cocoapods/xcode/project.rb https://github.com/alloy/cocoapods/blob/master/lib/cocoapods....
stevejohnson 15y ago
Without better documentation I can't really evaluate this. Who runs the central repository? How is it kept up to date? I feel my skepticism is warranted for a week-old project.
- alloy 15y ago
  * Yes, good documentation is needed. Patches are very welcome :) * The community. The idea is that once you have one patch accepted you get push access. This applies to both https://github.com/alloy/cocoapods https://github.com/alloy/cocoapods and https://github.com/alloy/cocoapods-specs https://github.com/alloy/cocoapods-specs. * “How is it kept up to date?” Can you explain what “it” is?
  - stevejohnson 15y ago
    "It" being the package repository.
    - alloy 15y ago
      If you mean on the end-user's machine: $ pod repo update
signalsignal 15y ago
This is very interesting. I will be watching this project.
steipete 15y ago
Anyone tried Zimt? https://github.com/zimt/zimt https://github.com/zimt/zimt - looks similar to cocoapods, looks more mature.
- alloy 15y ago
  Is there a specific feature that makes you say that? Or is it the age?

67 points by jamesjyu 15y ago

samsoffes 15y ago

I am crazy excited about this. With the growing number of Objective-C libraries, this will make things so much better.

gfodor 15y ago

I wonder why the author didn't go for the obvious pun, Cocoabeans? Oh, wait, I think I know why. :)

alloy 15y ago
Starts with “J” and ends with “ava” ;)

aphexairlines 15y ago

There are already package managers that have been developed for years (ie: hard problems solved and bugs ironed out), can track dependencies across languages/runtimes, and have large cross-language communities. Cocoapods isn't even cross-platform. It's only for iOS libraries, which means it only works on macs, which means it won't offer much beyond mac package managers. So use macports, or fink, or homebrew, or nyx.

jballanc 15y ago
You're missing the point. This is not a tool for end-users, but rather for developers. iOS/OS X already have a means of distributing third-party libraries with projects (the "./Frameworks" directory), there just has not, until now, been a good way for developers to find and organize these libraries during development. The goal of this project is to give developers that way of sharing, discovering, and resolving dependencies of libraries, but at the end of the day everything will still get packaged up as a "*.app" that is distributed via the App Store. Also, the reason to create a custom tool for this instead of repurposing one of the many existing package managers is that it allows for the tool to be specialized for the specific case of developing App Store apps. Sure, you can install a third-party library via macports, but how do you tell macports to compile the library and place the resulting frameworks into the right directory in your Xcode project?
protomyth 15y ago
That seems to be the whole point is to provide a specialized manger For libraries on a Mac. Some people don't want a general solution to a specific problem.
adamjernst 15y ago
iOS libraries need to be cross-compiled and statically linked. (Dynamic linking is not allowed in apps submitted to the store, IIRC.) I'm sure macports or whatever CAN be forced to do both of these, but it's easiest just to make something new, lean and efficient.

zbowling 15y ago

WOW. you created my idea I posted a few days ago here! http://news.ycombinator.com/item?id=2997247 http://news.ycombinator.com/item?id=2997247

alloy 15y ago
ZOMG, indeed! You’re welcome! :D On a more serious note, I had been trying not to create this for about a year now. The release of the boilerplate project made me decide it’s time to finally scratch that itch.
alloy 15y ago
Also, please please please start contributing specifications: https://github.com/alloy/cocoapods-specs https://github.com/alloy/cocoapods-specs :)

tomwilson 15y ago

So glad someone has finally done this...

Aqua_Geek 15y ago

Out of curiosity, why the dependency on MacRuby? The only thing I've seen in the digging I've done thus far is the CFUUID stuff, but that is easy enough to recreate in Ruby so I think I must be missing something...

jballanc 15y ago
I suspect that you'll see many more benefits of using MacRuby for the project going forward. For example, think about the sorts of things that Bundler (being written in Ruby) can do for Ruby gems that rvm (being mostly written in shell script) cannot.
alloy 15y ago
Good question, it’s because of reading and writing the project.pbxproj file through NSDictionary: https://github.com/alloy/cocoapods/blob/master/lib/cocoapods/xcode/project.rb https://github.com/alloy/cocoapods/blob/master/lib/cocoapods....

stevejohnson 15y ago

Without better documentation I can't really evaluate this. Who runs the central repository? How is it kept up to date? I feel my skepticism is warranted for a week-old project.

alloy 15y ago
* Yes, good documentation is needed. Patches are very welcome :) * The community. The idea is that once you have one patch accepted you get push access. This applies to both https://github.com/alloy/cocoapods https://github.com/alloy/cocoapods and https://github.com/alloy/cocoapods-specs https://github.com/alloy/cocoapods-specs. * “How is it kept up to date?” Can you explain what “it” is?
- stevejohnson 15y ago
  "It" being the package repository.
  - alloy 15y ago
    If you mean on the end-user's machine: $ pod repo update

signalsignal 15y ago

This is very interesting. I will be watching this project.

steipete 15y ago

Anyone tried Zimt? https://github.com/zimt/zimt https://github.com/zimt/zimt - looks similar to cocoapods, looks more mature.

alloy 15y ago
Is there a specific feature that makes you say that? Or is it the age?