URLs as Swift Package Identifiers

[mattt]

Thank you so much for thinking more about this and sharing your solution. In my opinion, this is the only viable alternative that I've seen so far.

I'll take some more time to review this tonight, but here are some of initial thoughts #hottakes:

@benrimmington

The package manifest would have a new namespace parameter:

 // swift-tools-version:6.0

 import PackageDescription

 let package = Package(
+  namespace: "com.apple",
   name: "swift-nio",

I wonder if having this in source would cause problems for forks. Consider the following scenario:

• Alice forks github.com/mona/LinkedList
• Alices makes changes to the package, including the namespace so that she can use her fork
• Later, Alice submits changes upstream, forgetting about the diff in Package.swift
• Mona accepts the PR, overwriting the old namespace
• ???

Another scenario:

• Bob publishes a tutorial with sample code for how to publish your first package
• Carol forks the project and tries to publish the package, but forgets to change the namespace argument
• ???

@benrimmington

External dependencies, on other packages and their products, would have fully-qualified names:

 dependencies: [
   .package(
+    name: "com.apple.swift-nio",
     url: "https://github.com/apple/swift-nio.git",
     from: "3.0.0"
   ),
 ]

 dependencies: [
   .product(
-    name: "NIO",
-    package: "swift-nio"
+    name: "com.apple.NIO",
+    package: "com.apple.swift-nio"
   ),
 ]

Would this impact the import statement at all? Is it still import NIO or import com.apple.NIO? If the former, how would we resolve module name collisions?

---

Taking a step back: One of the main arguments I've heard in favor of reverse-DNS is that it has a long history of use in Java, going back to the late '90s. Back then, there were only a handful of TLDs. From Wikipedia:

The initial set of generic top-level domains, defined by RFC 920 in October 1984, was a set of "general purpose domains": com, edu, gov, mil, org. The net domain was added with the first implementation of these domains.

It occurs to me that we have many more TLDs today (at least 310 according to DNSimple). If a requirement of the design is that identifiers not be confused as URLs, this may be a problem since popular packages overlap with generic TLDs. If Alice publishes a package named tools at example.com (com.example.tools), Mallory could register example.tools and create a subdomain com that resolves to https://com.example.tools.

If the trend for more gTLDs continues, does this start to become a problem?