The 3rd review of SE-0292 has concluded. The review has been generally quiet with feedback focused on making the OpenAPI spec more robust to explicitly highlight the support for redirecting proxies which have been one of the focus points of the 2nd review. As such, the proposal has been accepted with a few minor revisions:
- Refine "A client SHOULD verify the integrity of a downloaded source archive" to "A client MUST verify the integrity of a downloaded source archive"
- Include the checksum of the source archive in the Package release metadata, and/or refine OpenAPI spec to make it clear it should include
- Make the support for redirecting proxies more explicit by explicitly listing 30x response code in the OpenAPI spec.
The proposal and its approval mark an important step forward in the evolution of the Swift package ecosystem. The proposal went through a long review cycle and reflects important feedback from many members of the community. I would like to thank everyone who participated in the review and the proposal authors for their patience and hard work getting this proposal over the finish line.
Just noticed that the entry for this on the Swift Evolution web site is still listed as being under active review.
Did any work on binary packages end up being done as part of this proposal? I saw there was a note under "Future directions" so I'm assuming not.
I'm doing research right now on archiving binary libraries and doing security related dependency audits using tools like Artifactory. Artifactory doesn't have any support for SPM today but I'm just gathering the current state for stakeholders.
We have some sensitivities around source distribution. So while the work around Github is interesting, we're looking at the future directions of this proposal. Has any work been started or are there any new proposals being worked on?
Has anyone ever implemented a package registry service? I remember GitHub announcing it few years ago, but it seems like the project went silent.
Does Xcode support this?
No, there is no support, from Xcode or anyone else. This standard seems dead.
That’s a bummer, as the standard seems really well defined.
I’m dealing with super modularized projects that have 30-50 Swift packages, so resolving the package graph with so many repos takes a while even on M1, not to mention the infamous SPMRepositoryError error 5 on every second attempt.
Yeah, it's pretty bad. Hopefully Xcode 14's SPM integration is more reliable, but SPM's performance problems are foundational, so I don't think we'll see any improvements there.
I think we can expect it in swift 5.7: make registry dependencies available in 5.7 by tomerd · Pull Request #4244 · apple/swift-package-manager · GitHub.
No idea if Github will implement the proposal as it seem to me that Mattt withdraw at the very end (it took ~2 years to get it in SPM).
Chiming in representing the SSWG and stuff we're aware of here:
@Jon_Shier @Srdan_Rasic this is far from dead actually! It just takes time to adopt and implement such standards across the board.
Today (!) during swampUP 2022 @tomerd and the Artifactory folks have just announced that Artifactory implemented the registry APIs I could not find a concrete documentation page about it yet, but I'm sure all that will follow very soon.
And SwiftPM has just finished implementing the client-side features necessary for this in preparation for Swift 5.7 (make registry dependencies available in 5.7 by tomerd · Pull Request #4244 · apple/swift-package-manager · GitHub).
Such "ecosystem wide" features take some time to kick off, so don't claim them as as dead while the teams are still very actively working on making them happen and adopted throughout
That's good to hear. Hopefully we hear something from Apple in two weeks as well.
@daveverwer @finestructure What's the status on Swift Package Index supporting the registry service? I know y'all were a big voice in the proposal's review
Adopting a registry API is certainly something we're considering for the Swift Package Index. However, it also comes with quite a few extra responsibilities and so we want to be careful when and how we're going to commit to it.