Speaking of CocoaPods, I’ve been running into some irritations when using CocoaPods with a private specs repo. I jotted down some suggestions in a GitHub issue. I’ll repost them here for good measure. I appreciate any advice you have if you’ve used private specs repos extensively.
Podspec linting for private specs really falls short of an ideal, streamlined experience. There are several areas for improvement:
1) Don’t Require Irrelevant Metadata.
Private specs should not be obligated to provide an open-source license. They should not have to provide both descriptions and summaries (and ideally neither one should be required). Nor should a homepage should be required. These fields should only be required for public specs as they exist solely to aid in discovery by the general public.
2) Remove the HTTPS Requirement for Source URLs.
Private specs should be allowed to use SSH source URLs. As the linting warning reminds us, the enforcement of HTTPS is a matter of hospitality to the general public who might be behind firewalls that disallow SSH. It doesn’t make sense to apply this requirement to private specs. The HTTPS requirement is especially irritating for anyone who has TFA enabled on their GitHub account. To skirt the SSH warning, you have to disable all warnings via the
--allow-warnings flag. I should be able to leave all unrelated warnings untouched. Ignoring every warning as a means of ignoring a single warning is suboptimal.
3) Provide Explicit Metadata Options to Indicate that a Podspec is Private
I’d like to be able to workaround issue #1 and #2 (and any other issues that I’ve neglected to mention) by an option like:
s.private = true
private is present and equals
true, this would indicate to the spec linter to skip linting steps that are only appropriate for public specs.
4) Disallow Pushing a Private Spec to the Public Trunk
It is extremely easy to accidentally publish a private spec to the public trunk, and difficult to fix the mistake after it occurs. Any Podpec with
s.private = true should not be allowed to be pushed to the public trunk.
5) Allow Podspec to Indicate a Private Specs Repo in Which to Search For a Dependency
In some cases a private specs repo contains a spec with the same name as a spec in the public trunk. If a Podfile has a
pod dependency that seems to appear in multiple repositories, running
pod install will result in error logs about the duplicate specs. The Podfile of the host app bears the responsibility for making sure that custom specs repos are listed in the correct search order.
It would be preferable for a Podspec to be able to declare that a dependency can only be searched for within a given private spec repo url, e.g:
s.dependency 'AFOAuth2Manager', 'repo: email@example.com:/jaredsinclair/private-specs.git`
This would address cases where a public repo has to be forked into a private spec to fix incompatibilities with other third-party dependencies (long story).