URLs as Swift Package Identifiers

[benrimmington]

Within manifests, package identity could be improved as you've suggested, possibly by updating Target.Dependency.product(name:package:condition:) to accept a package URL.

There are also subcommands which take package names:

• swift package edit
• swift package resolve
• swift package unedit
• swift package update

Should these subcommands be updated to accept package URLs? Would this affect a package which has already been put into editable mode?

Xcode has an alternative to swift package edit. A package dependency can be overridden, by adding a local package with the same name:

• Editing a Package Dependency as a Local Package

Should this be replaced by proper edit/unedit commands within Xcode? Or fallback to using the git remote URLs of the local package?

@mattt

There are a few different ways that .well-known could be used, and I'd very much welcome a more developed proposal that could be workshopped and debated.

I'll try to give a more detailed example, but I only discovered RFC 8615 recently (for this thread).

If the package manager/registry wants to verify that a com.apple::swift-nio-* package or com.apple::NIO* module is allowed to use the com.apple::* namespace, it could make a request to:

https://apple.com/.well-known/swift-package-collection

This can redirect to a subdomain:

https://www.apple.com/.well-known/swift-package-collection

If the response is an error (e.g. 404 Not Found), then the com.apple::* namespace isn't restricted available (which might give a warning/error by default).

If the response is a package collection, then the com.apple::* namespace is restricted to package URLs in the collection.

Alternatives:

• The well-known URIs registry needs a specification of the format, which is why I suggested using a package collection, but a simpler format is possible.

• GitHub uses a DNS TXT record to verify an organization's domain.

@mattt

This could work for individuals or a single organization with a small number of packages. However, enumerating a complete list of packages would be infeasible for hosts like GitHub or GitLab.

GitHub or GitLab wouldn't need to put the packages of other organizations/users in a collection.

@mattt

Another consideration is that requiring a host to enumerate a complete list of packages could leak information about the existence of a package.

The com.apple::* namespace would only be used for public, open-source packages. Perhaps the org.swift::* or com.apple.opensource::* namespaces are more suitable? (Existing closed-source system frameworks have com.apple.* bundle identifiers.)