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
.netrcfile 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!