Private Spec Repos

[mtitolo]

Moved from CocoaPods/CocoaPods#2217

@eric-horacek asked:

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?

@supermarin: Michele 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.

[mtitolo]

This is one of those things where an "official" recommendation will not solve everyone's problems. I think the best case here is to have both, and list some pros/cons. The section on using private pods with :path and :git I think could be expanded.

[AliSoftware]

Just my two cents here: we are using private specs repos in our company because we are developing some internal components that we keep on the shelf to reuse in some projects, but those components are private to the company and not OpenSource so we don't want to put them in GitHub and push their specs on trunk & CocoaPods/Specs.

Those components don't evolve that much (once we have a stable version, we of course have some enhancements and evolutions but maybe monthly, so far from daily).

We use the GitFlow branching model, the master branch is locked on our GitLab and users are submitting evolutions with Pull Request, so that I (the designated iOS expert) or some other qualified iOS devs can review the code and validate (or not) the evolution. When someone submit a PR with changes in the code, they also modify the podspec file (at the root of the same repo), and when we accept and merge the PR, we simply have to create the GIT tag and run pod repo push right after the merge and we are done, the podspec is pushed on our private spec repo within seconds.

As a conclusion, Private Specs Repos are then a really useful feature for us. If we were to change the codebase every day or so, sure we wouldn't tag each new commit and create a new podspec version each time, but use :git => ... in our Podfile as @mtitolo recommends. But as we are using it for components on the shelf that change only monthly or so, tagging and pushing a new version of the spec in our Private Specs Repo works pretty well.

[erichoracek]

@AliSoftware I was doing things the same way until I saw @supermarin's talk. He brought up the following point:

What is the benefit that your private Specs repo brings you over having your private pods defined as follows in your App's Podfile:

pod `CompanyPrivateLibrary`, :git => '[email protected]:Company/PrivateLibrary', :tag => '1.0.0'

By having a private Specs repo, there's a lot of unnecessary redundancy. Your .podspecs are copied there, but they already exist in the root of the PrivateLibrary git repo as PrivateLibrary.podpec. Your tags are pushed there as folders, but they already exist as tags in the PrivateLibrary git repo as well. Your library name is pushed there as a folder, but it already exists as a repo on GitHub (or wherever you host it). What's the benefit of having them in a private Specs repo when CocoaPods allows for you to specify all of the above right inside of your Podfile and private git repo?

Especially if you're using CI as @mtitolo mentioned, if you run a pod spec lint on pushing to master in your PrivateLibrary, you can even duplicate the functionality of .podspec linting on push that a private specs repo has.

Perhaps the one downside of getting rid of the private Specs repo is dependency resolution. It would seem that you can't specify tags as follows:

pod `...`, :git => '...', :tag => '~> 1.0'

[segiddins]

Right, you give up almost entirely on the power of dependency resolution, and I don't think that loss should be understated.

[AliSoftware]

@eric-horacek I have multiple benefits:

1. Users of our private libs don't need to specify the whole path to our GitLab repository with :git => https://gitlab.ourcompany.com/ios/PrivateLib in their Podfiles each time they need one
2. We can use semantic versionning and version constraints, like pod 'OurLib', '~> 1.2' which cannot be done when we point directly on a specific tag
3. Users don't have to know the tag name and more especially which is the latest version of a given pod to use it, they can simply pod 'OurLib' in their podfile, and they can update to the latest version of those pods with a simple pod update when it suits them.

On the contrary when binding the Podfile to a specific and pinned tag, they have to know the exact tag, they can't use open restrictions on the version to use (~> or whatever operator), and more importantly they have to be aware that a new version of a given lib has been published on our repos or check manually / regularly if new tags have been pushed in order to know it they should update some libraries, and if wo they have to manually specify the exact tag. Without our Private Specs repo, they cannot use the capabilities like pod outdated or pod update, which is a big loss IMHO.

For us, CocoaPods is sure a library manager that ease the integration of external libraries, but is also and most especially a dependency manager and resolver. When specifying explicitly a repo and tag instead of relying on a Private Specs repo, we loose all those features that are what makes CocoaPods such a great tool.

Especially if you're using CI as @mtitolo mentioned, if you run a pod spec lint on pushing to master in your PrivateLibrary, you can even duplicate the functionality of .podspec linting on push that a private specs repo has.

We never pod spec lint. We pod lib lint to check that everything is alright locally (without having to download the code, just checking that we didn't forget to add a new dependency or a new source file), then we tag and pod repo push (which in turn does pod spec lint itself). When using the master Specs repo (which is now trunk), I have the exact same process (which is thus not bound to the fact that the spec repo is private or public): always pod lib lint our libs to check locally that everything is alright before tagging, then tag, the pod trunk push.

[AliSoftware]

[ @segiddins ] Right, you give up almost entirely on the power of dependency resolution, and I don't think that loss should be understated.

Exactly my point. That is what makes all the power of CocoaPods, and I wouldn't miss these features for all the world.

[erichoracek]

This may be question larger than the scope of this conversation, but why should a Specs repo be required for dependency management & resolution? Why can't the tags on the repo be interpreted as semantic version numbers? Is it simply because they aren't forced to follow the semantic version specification format? If that's the case, can ones that don't follow this specification format simply be ignored?

[segiddins]

Because cocoapods is not git specific.

-Samuel E. Giddins

On Jun 4, 2014, at 2:07 PM, Eric Horacek [email protected] wrote:

This may be question larger than the scope of this conversation, but why should a Specs repo be required for dependency management & resolution? Why can't the tags on the repo be interpreted as semantic version numbers? Is it simply because they aren't forced to follow the semantic version specification format? If that's the case, can ones that don't follow this specification format simply be ignored?

— Reply to this email directly or view it on GitHub.