Cocoapods: Podspec options that would streamline the use of private specs.

[jaredsinclair]

Podspec linting for private specs really falls short of the ideal, streamlined experience. There are several areas for improvement:

Suggested Changes for Private Podspecs

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). Similarly, a homepage should not 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 warnings all linting of private specs using SSH source URLs, you have to include 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

When 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 protected]:/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).

[segiddins]

@jaredsinclair on master, there's already a --private option that addresses (1) and (2).

As for the others, I think we'd accept contributions to those effects, but they're not our primary focus at the moment (be warned though, 5 would be tough since it touches the dependency resolver).

[orta]

4, should be done too already, so long as the (HTTP/git) source is private trunk will deny the pod.

[jaredsinclair]

Neat! I'll check those out.

[jaredsinclair]

@segiddins Is --private in the Podspec docs? I can't find it.

[segiddins]

No, it's only on master, it hasn't shipped yet

[jaredsinclair]

Yeah, (5) could get hairy if overlapping/nested dependencies had incompatible source: modifiers. Considering the intended use case, though, I'd have the resolver fail if the same pod has non-matching (non-nil) source:-es anywhere in the dependency graph.

[jaredsinclair]

Re: --private would you consider a PR that did something like this:

def run
          UI.puts
          podspecs_to_lint.each do |podspec|
            validator                = Validator.new(podspec, @source_urls)
            validator.local          = true
            validator.quick          = @quick
            validator.no_clean       = !@clean
            validator.fail_fast      = @fail_fast
            validator.allow_warnings = @allow_warnings
            validator.no_subspecs    = !@subspecs || @only_subspec
            validator.only_subspec   = @only_subspec
            validator.use_frameworks = @use_frameworks
            validator.ignore_public_only_results = @private || isPrivate(podspec)
            validator.validate

A command line option is a transient way of indicating a permanent status. I really think private belongs in the spec.

[orta]

Hrm, I don't feel too strongly on the private attribute, but I think it's purpose does convey the idea better than --private. It works well for when there's multiple people, and there's a little bit less of this.

[segiddins]

I personally dislike adding attributes to the podspec that dont describe how the pod is built, but I feel that might be a losing battle

[neonichu]

I agree with @segiddins here regarding the private attribute, the CLI switch makes much more sense, because it is actually about changing the behaviour of the lint command and not about the Pod itself.

[jaredsinclair]

I think that including private in the spec is both closer to the truth, and easier to adopt.

A private flag is closer to the truth because the privacy of the pod doesn’t change between lintings; it’s part of the definition of the pod. Privacy is unlikely to change, or at least will not change often.

Indicating privacy via a CLI argument skews from the truth in two ways:

a) The CLI approach is opt-in, contrary to the fact that the pod’s author intends it for private use.
b) The CLI approach is transient, contrary to the fact that the pod’s privacy status remains constant between lintings.

A CLI argument approach also obligates every team member to remember to include the argument for any command that triggers a spec linting. In contrast, a private flag in the spec would allow the principle author to indicate this once and in a canonical fashion.

Sidenote: I agree with the sentiment about wanting to keep metadata about a pod separate from how to build it, but that ship has sailed since homepage etc. are in pretty much every spec in existence.

[neonichu]

This issue has been inactive for a long time and will be closed because we want to move forward with a clean slate after our 1.0 release.