Thanks for stepping forward, Bryan: having GitHub involved in a package registry seems like a really fantastic addition to the Swift community!
In particular, I’m really pleased to see that GitHub is invested in the idea of registries being abstracted away by a web API. This is a direction many other language communities have taken and it allows for a lot of flexibility. For example, it lets enterprises run “internal” package registries that let their developers use packages that haven’t been open sourced. Or, my personal favourite, allows developers to run a daemon on their machine that can act as a caching proxy for the registry, allowing a full SwiftPM workflow even in a situation where they have no network access.
Below are some of my initial thoughts in response to your question. I’m looking forward to helping this process move forward!
My understanding of the shape of your pitch is that you consider a package registry to be a combination of the following things:
- A package versioning, dependency, and metadata specification that allows packages to express these properties about themselves.
- An API specification that allows a client to query a service about packages, in order to locate their source code or other artefacts.
- An implementation of 2, where one example will be provided by GitHub.
My view here is that the Swift package manager provides part (1), so my recommendation would be that the GitHub registry should follow the lead of many other package registries in extracting this information from the language-specific package manager manifest. In the case of Python, for example,
PyPI are built on top of the metadata specified by setuptools.
In cases where GitHub or the community identify a need for extra metadata, that metadata could either be specified in the
Package.swift object itself, or in a static file alongside the
Package.swift. In general I’d prefer to keep this stuff together, but I understand the desire to be able to evolve the metadata without evolving the build tool, so in the cases where this metadata does not affect the build process (e.g. license specifications) it seems reasonable to have a declarative file alongside to carry this metadata.
For (2), I think it would be most productive for you to prepare a sacrificial first draft of what you think this API should look like. This would let the community take advantage of your experience running other registries to get an idea of what a general shape for an ergonomic API would be, and then to provide concrete feedback to evolve that proposal. Otherwise the design space for possible APIs is huge and we’ll be at risk of discussing at cross-purposes forever.
A sad note on part (3) is that it’s unfortunate that the initial implementation will use Go, and not Swift. Of course I understand that you have your own operational realities to deal with, but still, a Swift implementation would be nice, and I expect the Swift server community will rapidly spin up several, if only to satisfy the needs of local resolver caching and other things.