You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After watching @supermarin's talk tonight at the CocoaPods SotU in which he suggested that you shouldn't really ever need to use a private Specs repo (right after @mtitolo recommended the contrary), I spoke with @orta about what the "official" recommendation should be from CocoaPods. He said this would be a great point to discuss in an issue here.
In my experience, setting up and maintaining a private Specs repo has been a point of contention on teams in which I've done so in the past. For those that are less knowledgable about what CocoaPods does / is responsible for, it's a weak point in the development process where a lot of stuff can go wrong (users trying to push directly to it, confusion over pod repo add, and so on). However, it does force users to lint their specs before pushing, which is a good way to catch pod/podspec issues before they're committed.
What do you guys think the official recommendation from CocoaPods should be for this? Does lowering the barrier to entry and making internal updates simpler beat out the loss of required linting?
The text was updated successfully, but these errors were encountered:
Michelle has given a great intro on how to start and explained how this works. My talk was more on 'optimizing' and daily use-cases from the real life.
Personally - maintaining a private spec repo seemed like an overhead, because we always needed to push both source code and specs every time we updated any of the shared code. There's 15+ developers working on the code daily, so you can have an idea of how often does this happen.
Your quote has the same point:
In my experience, setting up and maintaining a private Specs repo has been a point of contention on teams in which I've done so in the past. For those that are less knowledgable about what CocoaPods does / is responsible for, it's a weak point in the development process where a lot of stuff can go wrong (users trying to push directly to it, confusion over pod repo add, and so on). However, it does force users to lint their specs before pushing, which is a good way to catch pod/podspec issues before they're committed.
We are still using private pods, but directly accessed via :git => 'path'.
For the linking part, we do have all the unit tests that would catch any failure with it.
After watching @supermarin's talk tonight at the CocoaPods SotU in which he suggested that you shouldn't really ever need to use a private Specs repo (right after @mtitolo recommended the contrary), I spoke with @orta about what the "official" recommendation should be from CocoaPods. He said this would be a great point to discuss in an issue here.
In my experience, setting up and maintaining a private Specs repo has been a point of contention on teams in which I've done so in the past. For those that are less knowledgable about what CocoaPods does / is responsible for, it's a weak point in the development process where a lot of stuff can go wrong (users trying to push directly to it, confusion over
pod repo add
, and so on). However, it does force users to lint their specs before pushing, which is a good way to catch pod/podspec issues before they're committed.What do you guys think the official recommendation from CocoaPods should be for this? Does lowering the barrier to entry and making internal updates simpler beat out the loss of required linting?
The text was updated successfully, but these errors were encountered: