URLs as Swift Package Identifiers

[mattt]

@tomerd

The implication of location-based identifiers is that we would be asking SwiftPM users to manage URL mapping files, or set up proxies and other infrastructure to resolve dependencies deduplication issues. In our opinion, this is not practical at a significant scale and time horizon, and will cause continuous pain down the road.

In other words, location-based identifiers land the complexity on the end user, while opaque identifiers land the complexity on the package registries. From where we stand, putting the complexity on the registries would be setting the stage better for a future where we can reliably deduplicate packages and solve the module name clashes in the vast majority of cases.

I disagree with this characterization and assessment.

Because Swift packages can be forked, mirrored, and duplicated in the wild, automatic migration isn't always possible. The user must be able to intervene. Our proposal acknowledges this fact and provides mechanisms for users to resolve any conflicts directly.

Pushing this complexity to the registry doesn't solve any problems, but instead adds a level of indirection that will make it harder for users to resolve their issues. A cursory look at other systems, like Maven, reveals that central registries and opaque identifiers face the same problems.

Dealing with "Xerces hell" in Java/Maven?

Maven dependency resolution (conflicted)

Nor do opaque identifiers guarantee stable identity over time, as seen in Google's Best Practices for Java Libraries guide (e.g. junit.framework (versions 1.x-3.x) → org.junit (version 4)) as well examples like the left-pad incident and the renaming of libupskirt.

@tomerd

This thread gathered a lot of attention, and has provided insight into the practical advantages and disadvantages of the two approaches. At this point, it seems like the technical arguments have all been laid out. While there are still different opinions, there is little new information coming from the ongoing discussion.

To the contrary, I think this thread has lead to important new insights that haven't been addressed by the Core Team.

As @mmarston points out, this discussion has been framed as "URIs vs. opaque identifiers", but it's actually a discussion about whether or not to move from a decentralized system to a centralized registry. None of the feedback I've received from the Core Team so far acknowledges this change, or the necessity of a registry of record for opaque identifiers to function.

Our discussion has also lead to some good solutions to address challenges of package relocation, like this idea from @hisekaldma:

@hisekaldma

let package = Package(
movedTo: "https://mona.dev/LinkedList"
)

---

Our team has been working on this proposal for over a year now, and we believe that it's the best solution available to the long-term health and prosperity of the Swift ecosystem. We've strived to be transparent and responsive to feedback from the community throughout the process, so it was both surprising and disappointing to get feedback about such a fundamental aspect of our proposal only after formal review, some 7 months after our original pitch and 3 months after submission.

If the Core Team insists on migrating our decentralized ecosystem to use opaque identifiers in a central registry, please understand that your decision is made over our strong technical objections. Nonetheless, we agree that SE-0292 is critical to the success of the Swift ecosystem, and will work with you to find the best solution that meets your requirements.