[Returned for revision] SE-0292: Package Registry Service

Evolution Announcements
1

The second review for SE-0292 concluded on April 5th 2021, and the core team decided to return the proposal for revisions.

Before diving into further details, the core team would like to acknowledge it took unusual long time to provide feedback to this proposal given Swift's concurrency model proposals, which taken precedence over other proposals including SE-0292. The core team would like to thank the authors of SE-0292 for their patience and reiterate the importance of SE-0292, especially given its potential role in defining how Swift module disambiguation could work.

Most reviewers, as well as the core team, felt the 2nd iteration made significant progress towards acceptance. With that said, the core team would like to see the following points addressed before putting the proposal into a narrowly scoped third review:

  • Include the OpenAPI spec for the server API as part of the proposal body.
  • Relax scope and name constraints on diacritic‐insensitivity. Further, confirm the proposed constraints are a superset of Swift module name constraints such that they do not prevent a future in which package identifiers (i.e scope + ”.” + name) are used as module prefixes for the purpose of module disambiguation.
  • Credentials should not be embedded in URLs of the new SwiftPM registry configuration, and instead should be read from separate location, ideally the .netrc file which SwiftPM already uses for similar purpose.
  • Explore the utility of adding an API to enumerate all files that are included in a package version. The feedback / request to adding such API came from reviewers with background in the enterprise / private registries space and should be discussed further with the community (in the forums) in effort to reach a conclusion, then amend the proposal if necessary.

Several reviewers brought up the point that SE-0292 does not specify a default registry. Moreover, there were concerns that without a default registry, or a means to encourage multiple public registries to coexist, that a bias could be created towards the first vendor to bring a public registry online. The core team recognizes these concerns, and believes that the means to encourage multiply registries to co-exist (e.g., through a naming service or proxy) can be addressed in later discussions and proposals. The APIs proposed in SE-0292 do not preclude such later inventions, and encourage the creation of package registries that would be immensely valuable to the Swift ecosystem.

Thanks to everyone who participated!

Tom Doron,
Review Manager

9 Likes
2

I have an additional question: would the core team support creating a default list of registries?

One of the issues that I have with the previous proposal is that it doesn't work out-of-the-box: you'll see instructions to add a package dependency on "mona.linkedlist", or maybe one of your dependencies declares its dependencies using a package ID, but that will only work if you first added the necessary registries. Otherwise, SwiftPM and the entire package ecosystem would basically be broken to you.

In order to make this usable, both for Apple's SDK toolchains and the Swift.org toolchains, I think it will be necessary to create a default registry list. This still allows for multiple registries to exist, and presumably registries will need to agree to some minimum standards for things such as privacy to be on it.

Given the apparent reluctance (which I sympathise with) to have a default registry maintained by Swift.org, I find it hard to see how we will maintain a usable toolchain experience without at least adding some kind of default list. Is that something the core team would be open to, as an alternative to a full registry?

3

The goal is to make progress while leaving the door open to future components that fill gaps SE-0292 leaves undefined. The core team feels that defining the API between the client and server (which is the focus of SE-0292) is an important stepping stone towards a transition to registries based ecosystem. Solidifying such API enables teams to make concrete technical progress in the implementation of the client side (SwiftPM) and creation of server components, such as registries and intermediates like proxies and naming services.

1 Like