Challenges setting up a Swift Package Registry Server generated with swift-openapi-generator

Hi,

I’m currently trying to setup a Swift Package Registry(SE-0292 / SE-0321) server using swift-openapi-generator based on the official YAML file: registry.openapi.yaml. The goal is to securely store and share our internal .xcframeworks across teams, we didn't succeed with .netrc because Xcode seems to ignore them. And using a GitHub PAT in the url is a no go from our security team.

We are encountering several issues and would appreciate guidance on the following points:

  • Is there a public test suite available to validate that a server complies with Swift Package Registry expectations? The swift-package-registry-compatibility-test-suite seems non-functional.
  • Can swift-openapi-generator generate example data as part of its output?
  • Are there any recent updates on GitHub’s support for Swift Package Registries?
  • Is the Swift Package Registry still relevant to the Language Server Group (LSG)? Or is it a dead end ?
  • Is there another way to force Xcode to load .xcframework that are hosted on a private GitHub repo without using a PAT in the URL ?
  • It appears that swift-openapi-generator doesn’t fully generate a working Swift Package Registry implementation based on the provided YAML. Specifically, the “downloadSourceArchive” endpoint seems unreachable and instead, the server always responds from the “fetchReleaseMetadata” endpoint.
  • Are there any plans from LSG or SSWG to release a Docker image that implements an implementation of the Swift Package Registry server?
  • The Output types generated by swift-openapi-generator are not always practical to use for exemple for Operations.listPackageReleases.Output, instead of using OpenAPIObjectContainer in the JSON it would be better to have a real type like the one bellow. A type that have not been generated by swift-openapi-genertor? (after thinking more about this it might be due to the registry.openapi.yaml that didn't declare the format of this model.)
struct ReleasesResponse: Codable {
  let releases: [String: Release]
  
  struct Release: Codable {
    let url: String?
    let problem: Problem?
    
    struct Problem: Codable {
      let status: Int
      let title: String
      let detail: String
    }
  }
}
  • When OpenAPIObjectContainer is used it could be great to have the option to use our own Data.

I encountered an error when using the command swift package update.

error: failed fetching mona.LinkedList releases list from https://127.0.0.1:8080: server error 500: {"error":true,"reason":"Server error - cause description: 'Unexpected Accept header: application/vnd.swift.registry.v1+json', underlying error: Unexpected Accept header: application/vnd.swift.registry.v1+json, operationID: listPackageReleases, request: GET /mona/LinkedList [accept: application/vnd.swift.registry.v1+json; accept-encoding: gzip, deflate, br; accept-language: fr-FR,fr;q=0.9; connection: keep-alive; user-agent: SwiftPackageManager/5.10.0-dev], requestBody: OpenAPIRuntime.HTTPBody, metadata: Path parameters: [\"name\": \"LinkedList\", \"scope\": \"mona\"], operationInput: Input(path: swift_package_registry.Operations.listPackageReleases.Input.Path(scope: \"mona\", name: \"LinkedList\"), headers: swift_package_registry.Operations.listPackageReleases.Input.Headers(accept: [OpenAPIRuntime.AcceptHeaderContentType<swift_package_registry.Operations.listPackageReleases.AcceptableContentType>(contentType: swift_package_registry.Operations.listPackageReleases.AcceptableContentType.other(\"application/vnd.swift.registry.v1+json\"), quality: OpenAPIRuntime.QualityValue(thousands: 1000))])), operationOutput: ok(swift_package_registry.Operations.listPackageReleases.Output.Ok(headers: swift_package_registry.Operations.listPackageReleases.Output.Ok.Headers(Content_hyphen_Version: swift_package_registry.Components.Headers.contentVersion._1, Content_hyphen_Length: nil), body: swift_package_registry.Operations.listPackageReleases.Output.Ok.Body.json(swift_package_registry.Components.Schemas.releases(releases: OpenAPIRuntime.OpenAPIObjectContainer(value: [\"1.1.1\": Optional([\"url\": Optional(\"https://swift.pkg.github.com/mona/LinkedList/1.1.1\")])])))))"}

For context, I have tested on a local server configured with HTTPS.

swift-driver version: 1.90.11.1
Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)
Target: arm64-apple-macosx14.0

In this case the swift package update is sending the Accept header as application/vnd.swift.registry.v1+json, which is expected as a Content-Type according to the registry.openapi.yaml file. Do you plan to release registry.openapi.yaml that have the same version as the swift release to have server that works with the issues or feature release with swift version ?

Has anyone successfully implemented a Swift Package Registry server? Any insights or advice would be greatly appreciated!

Thank you!

1 Like

Hi @mackoj,

I'm currently on vacation, so I'll reply to more of your questions when I'm back, just wanted to call out one right now - the issue with the two conflicting endpoints is likely caused by the underlying server transport - which one are you using? Not all support mixed path components (a variable with a static suffix).

cc @beaumont

1 Like

Thanks, the transport used is swift-openapi-vapor. I basically followed the tutorial to set everything up.

Another question regarding the Swift Package Registry is this normal that the login part is not inside the openapi file ?

Right, I think if you try Hummingbird v2, that one should handle the mixed component correctly, cc @adam-fowler

I did start implementing a swift package registry with Hummingbird 2 a while back. I found the OpenAPI document distinctly lacking in detail, so ended up not using it.

You can find my implementation here. The barebones are there, uploading/downloading packages, getting manifests, listing available packages, a very basic user authentication for publishing. It certainly isn't finished, I haven't look into package signing, asynchronous publishing.

Thanks :pray:

Haha just found out it’s not compiling. I’ll fix it tomorrow.