SE-0292: Package Registry Service

You can see the latest working implementation in this PR to apple/swift-package-manager.

You're correct in pointing out that the fixed cost of downloading the entire history of a project by cloning its source repository may, under some circumstances, may be less than the sum of downloading multiple releases through a registry. However, in practice, I believe a registry will be as fast if not faster than a repository for a few reasons:

  • We can see all of the available releases for a package from a single endpoint
  • We define a separate endpoint for downloading Package manifests at individual versions, without downloading the full archive
  • In general, globally-distributed CDNs are faster at serving Zip files over HTTP than repository hosts are at serving code via Git (even if that's Git over HTTP)

Ultimately, these are empirical claims that will have to be verified by real-world usage. I have a benchmark harness that you can use to try it out for yourself. At the moment, the results are promising:

$ bundle exec rake clobber benchmark
time ./spm run
       57.70 real        87.12 user        10.88 sys
time ./spm run --enable-package-registry
       16.24 real        35.85 user         4.75 sys

If a repository-based external dependency itself has external dependencies that can be resolved through a registry, then SPM will attempt to do so.

This came up in a previous discussion thread, but you're right — this isn't mentioned in the proposal or specification.

Alternatively, you can provide credentials through a .netrc file.

These features have been developing in parallel, and the current draft implementation of registry support doesn't support the system-wide cache. That said, I think it'd make a lot of sense to add support eventually.