SE-0292 revision 2

[mattt]

Changes from the original proposal:

• Adopts a new @mona/LinkedList mona.LinkedList identity scheme to replace package URLs in dependency declarations
• Adds new package-registry set|unset <url> subcommands for managing local and global package registry configuration
• Renames the archive subcommand to archive-source
• Adds a new GET /identifiers{?url} endpoint

[mmarston]

I didn't see anything that describes the client behavior when the client is configured with a registry URL (not a scope-specific one) and the client encounters a dependency in a Package.swift that refers to a package URL rather than an id (@scope/name)?

I see that the GET /identifiers{?url} API was added to the registry to aid with Module name collision resolution. But will the client only use this API to resolve name collisions or is it also used when the client figures our where to download the package from. For example, will the client pass the URL to the registry and then if the registry responds with a package id will the client then fetch that package from the registry instead of from the URL? (And what if the registry knows about the mapping URL <-> ID mapping but doesn't actually host that package? Should the registry proposal say that the registry should only respond to GET /identifiers{?url} with the package ID if the registry hosts that package?)

If the registry doesn't know about the URL then does the client fetch the package by URL?

[mmarston]

A couple other questions related to my last comment:

1. If I have 10 different registries configured for 10 different scopes and the client encounters a Package.swift with a package URL which of those 10 registries will the client make a GET /identifiers{?url} for that URL? Or will the client only make this request for the registry that is configured without a scope?
2. How can a user configure the Swift Package Manager to only fetch packages from a custom registry? (i.e. when the client encounters a URL in a Package.swift and the registry can't resolve it then fail instead of fetching from that URL).
3. Is the registry allowed to modify the Package.swift? For example, if the source code of a release contains a dependency on https://github.com/mona/LinkedList and the registry knows that URL map to @mona/LinkedList then as part of publishing a release can the registry modify the Package.swift to use @mona/LinkedList instead of https://github.com/mona/LinkedList.

[mattt]

@mmarston Thanks for all of your feedback, by the way! Some answers to your recent questions below:

I didn't see anything that describes the client behavior when the client is configured with a registry URL (not a scope-specific one) and the client encounters a dependency in a Package.swift that refers to a package URL rather than an id (@scope/name)?

If the registry doesn't know about the URL then does the client fetch the package by URL?

Yes, that's the intention. The exact behavior is an implementation behavior on the client's end, but my understanding is that URL-based package dependencies will continue to coexist alongside registry identifiers, at least initially.

A couple other questions related to my last comment:

1. If I have 10 different registries configured for 10 different scopes and the client encounters a Package.swift with a package URL which of those 10 registries will the client make a GET /identifiers{?url} for that URL? Or will the client only make this request for the registry that is configured without a scope?

This is another implementation detail, but my intention is for only the default / unscoped registry to be consulted.

2. How can a user configure the Swift Package Manager to only fetch packages from a custom registry? (i.e. when the client encounters a URL in a Package.swift and the registry can't resolve it then fail instead of fetching from that URL).

This proposal doesn't cover that, but I'd imagine that this behavior could be controlled by a command-line flag.

3. Is the registry allowed to modify the Package.swift? For example, if the source code of a release contains a dependency on https://github.com/mona/LinkedList and the registry knows that URL map to @mona/LinkedList then as part of publishing a release can the registry modify the Package.swift to use @mona/LinkedList instead of https://github.com/mona/LinkedList.

No. Any changes to the package source code would break the checksums computed by the client.

[tomerd]

cc @neonichu @abertelrud @yim-lee: are these general enough?

[yim-lee]

I think 39 chars limit is too low but open to see what the community thinks.

[tomerd]

cc @neonichu @abertelrud @yim-lee: are these general enough?

[yim-lee]

I might be wrong, but I believe this is the same as what SwiftPM uses for package names today?

I think scope and name should support the same characters but given the thread on removing name from the manifest I am ok with leaving this as is.

[neonichu]

SwiftPM places no restrictions on package names, AFAIK.