URLs as Swift Package Identifiers

[mattt]

@johannesweiss

The core of my argument however is: Much like with opaque identifiers, in the URI-based scheme I cannot just trust what I see in the URI. I need to also trust that everything is set up correctly and I didn't configure a malicious registry/intermediate registry proxy.

So from a trust point of view I see no difference: URIs may look like I know where the code comes from but I don't actually know unless I audit the full configuration too. The same applies to opaque identifiers but at least it's more obvious that this is the case.

Here's another way you could say it:

• A URL is routed directly unless you change the configuration, either by setting a mirror or setting an intermediate registry. This is the same as how things work now with external dependencies and mirrors.
• An opaque identifier is meaningless on its own; how that's routed is entirely dependent on configuration.

I agree that in both cases, configuration can confound expectations. To that end, I started to write up a swift package discover command that would help end users understand how packages are resolved — as well as other useful information, like time spent downloading and size on disk.

@johannesweiss

Which would mean that we'd be relying on source code host (eg. GitHub) having implemented that feature as well as allowing the package maintainer to use it.

Yes, correct.