CocoaPods: Handle the `sources` property from `Podfile`

[fviernau]

Currently the sources property is ignored and as repositories only the default repository [1] or rather it's faster replacement [2] is used. Change the implementation to use the repositories exactly as specified. Probably still [2] has to be used as replacement of [1] as neither cloning [1] on-the-fly nor adding it to the docker image or azure setup is feasible due to its large size.

[1] https://github.com/CocoaPods/Specs
[2] https://cdn.cocoapods.org

[rbieniek]

As pointed out in the Podfile specification for source property, this property is supposed to carry a reference to a GIT repository which stores Pod specifications.
Therefore supporting this property will need to involve a git clone operation on-the-fly at some point in time, probably as part of the bootstrap process, before any actual pod resolution is going to happen.
In case of a private pod repository which hosts just some company internal pods, this approach might be just fine. However, if the source property points to a private mirror of the public pod repository (for performance reasons perhaps), there will still be a slow checkout involved before any pod resolution, just because of there is no way to determine up-front what the content of the referenced repoistory actually is.

AFAIK the pod tool is lacking any kind of functionality to extract the source property value from a given Podfile. Therefore, the cocoapods scanner would need to somehow evaluate the Podfile itself in order to extract the value(s) of the source property

Furthermore, given a multi-module project setup with multiple independent Podiles, there might be some scoping issues to be sorted out.
For example, given two projects with Podfiles containing source properties pointing toiwards different pod spec repositories. Let's say:

• Project A sources in https://acme.com/pods.git
• Project B sources in https://foobar.com/pods.git
  What is the expected behavior in such a case?
• Merge all referenced pod spec repositories and resolve Project A and B against this union of pod spec repositories? In case both referenced pod spec repositories have a spec with same name and version but with different content, which one takes preference?
• Checkout each referenced pod spec repository individually and resolve each Podfile against only the pod spec repository referenced?

It also needs to be considered if the value(s) of the source repository should replace the default spec repositories [1] and [2], or if it is added as just another source for pod spec resolution alongside with the default spec repositories [1] and [2].

[sschuberth]

Some general remarks from my side:

Our current CocoaPods implementation exclusively relies on / parses Podfile.lock files. So we'd need to find out which Podfile.lock entry reflects a Podfile's source entry.

Therefore supporting this property will need to involve a git clone operation on-the-fly at some point in time

Maybe we could avoid a full clone by downloading only the single Podfile.lock file via HTTP... however, that would not work if the repository required e.g. SSH access.

[bs-ondem]

The Podfile.lock contains a SPEC REPOS section that lists all source repositories along with the pods fetched from each repository. This section is currently not parsed. For example:

SPEC REPOS:
      https://github.com/Artsy/Specs.git:
        - Aerodramus
      trunk:
        - Alamofire
        - ISO8601DateFormatter

I believe that parsing the SPEC REPOS section and adding the repositories using pod repo add-cdn or pod repo add <name> <url> (depending on whether the repository is a standard Git source or a CDN) should be sufficient to make it work.
We already have the function getPodspecPath, which returns then the correct path to the podspec file inside the repository.