5 ms·

CocoaPods announces Auth Server

32 points by orta 12y ago

neilkimmett 12y ago
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.
orta 12y ago
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 12y ago
  While on the topiZZzzzZzzzzzzzzz…………
AshFurrow 12y ago
This is a serious win for the iOS community. A huge step forward in terms of the maturity of the ecosystem. Congrats!
mikeash 12y ago
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.
- quesera 12y ago
  Just convenience, I think. Auto-updating rather than re-cloning and dragging files back into your project. This is fraught, of course. 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.
  - al_gore 12y ago
    > Auto-updating rather than re-cloning and dragging files back into your project 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).
    - alloy 12y ago
      Yes, CocoaPods can’t fix API breaking changes, but as we use semantic-versions and encourage authors to follow those, it can at least be mitigated more easily. E.g. A version requirement of: ‘~> 1’ should then install the latest v1.x.x, but not v2 which has API breakage. Obviously this is not fool-proof and many are still getting used to it.
  - alloy 12y ago
    > 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.
    - quesera 12y ago
      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 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.
- alloy 12y ago
  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-with-cocoapods http://dev.hubspot.com/blog/architecting-a-large-ios-app-wit... 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.
  - kylef 12y ago
    http://supermar.in/modular-objective-c/ http://supermar.in/modular-objective-c/ is a great article too.
  - mikeash 12y ago
    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.
- deleted 12y ago
  [deleted]

32 points by orta 12y ago

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.

orta 12y ago

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 12y ago
While on the topiZZzzzZzzzzzzzzz…………

AshFurrow 12y ago

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

mikeash 12y ago

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.

quesera 12y ago
Just convenience, I think. Auto-updating rather than re-cloning and dragging files back into your project. This is fraught, of course. 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.
- al_gore 12y ago
  > Auto-updating rather than re-cloning and dragging files back into your project 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).
  - alloy 12y ago
    Yes, CocoaPods can’t fix API breaking changes, but as we use semantic-versions and encourage authors to follow those, it can at least be mitigated more easily. E.g. A version requirement of: ‘~> 1’ should then install the latest v1.x.x, but not v2 which has API breakage. Obviously this is not fool-proof and many are still getting used to it.
- alloy 12y ago
  > 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.
  - quesera 12y ago
    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 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.
alloy 12y ago
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-with-cocoapods http://dev.hubspot.com/blog/architecting-a-large-ios-app-wit... 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.
- kylef 12y ago
  http://supermar.in/modular-objective-c/ http://supermar.in/modular-objective-c/ is a great article too.
- mikeash 12y ago
  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.
deleted 12y ago
[deleted]