Add nested PackgeIdentity.Scope and PackageIdentity.Name types

[mattt]

Adds package identity scope and name types as defined by SE-0292 (according to updated naming rules proposed by #3624).

Motivation:

Implement SE-0292.

Modifications:

• Adds a new PackgeIdentity.Scope type and related tests
• Adds a new PackageIdentity.Name type and related tests

Result:

The types added by this PR are tested, but not otherwise used by other APIs, so this change has no immediate effect.

[mattt]

@tomerd I'm currently blocked on #3640 until I have a better idea of how we're going to adapt the current package identity code to support local, repository, and registry packages. This PR attempts to lay some groundwork towards that end goal, whatever that looks like.

[tomerd]

cc @yim-lee for another set of eyes on the validation logic

[neonichu]

I think the rough idea would be:

• Local dependencies will continue to use the last-path component as identity and will require explicit manual configuration by the user to give them a scope/name based identity for the purpose of overrides
• URL based dependencies can query the registry to get a scope/name based identity if available and there would also be explicit manual configuration by the user, similar to local dependencies. If none of this is present, they'd continue to use legacy identity
• Registry packages always have a scope/name based identity

I think this implies that prior to #3640 we have to implement a new, explicit override mechanism. We'll also have to figure out a good way to transition folks to explicit overrides.

Without the presence of an override, a dependency with legacy identity is always considered to be different from one with scope/name based identity. Implementation-wise, we could also think of all package with legacy identity to be part of a single scope (that's somehow not valid as an actual scope to avoid collisions) and the last path component becoming the name.

[yim-lee]

Can we use regex patterns to do the validation?

[mattt]

We could, but I can think of a few drawbacks to that approach:

• Less precise errors (a regex match is all or nothing, so you can't know why it's invalid)
• Somewhat worse performance (a regex engine is slower than Swift string APIs)
• More coupling (it creates a dependency on a regex engine, which could complicate cross-platform deployment)

On the plus side, a regex is a more obvious representation than string manipulation code. But with comprehensive testing, that's probably less of a concern.

[mattt]

I think the rough idea would be:

• Local dependencies will continue to use the last-path component as identity and will require explicit manual configuration by the user to give them a scope/name based identity for the purpose of overrides
• URL based dependencies can query the registry to get a scope/name based identity if available and there would also be explicit manual configuration by the user, similar to local dependencies. If none of this is present, they'd continue to use legacy identity
• Registry packages always have a scope/name based identity

@neonichu That sounds about right to me.

Implementation-wise, one approach to help us navigate the transition would be to change PackageIdentity to an enumeration (we should be able to do that while keeping the existing APIs stable). Instead of initializers setting a stored description property, the description becomes a computed property based on 1) the enumeration case, and 2) the chosen resolution logic (i.e. "legacy" vs. "canonical"). Something like this:

public enum PackageIdentity: Hashable {
   case synthesized(name: String)
   case local(path: AbsolutePath)
   case repository(url: String)
   case registry(scope: Scope, name: Name)

   /* ... */
}

[tomerd]

@swift-ci please smoke test