{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigd2yi4zyuz5qez43imjxpvjqjfpf4ocdjyfopynzmb5tz5brxosy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkk66djvxpk2"
  },
  "path": "/t/pre-rfc-dns-domains-as-package-namespaces/24202?page=2#post_29",
  "publishedAt": "2026-04-28T07:27:13.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "[2]",
    "↩︎"
  ],
  "textContent": "Is there any reason not to be able to use an already published crate as a namespace(parent)? That way we don't need a separate naming system and in many cases this is also what you want (e.g. `tokio-util` could be at `tokio@util` [1]). In that case namespaces would be more like child-crates (possibly even allowing `parent@child@subchild` if desired.\n\nThis would avoid issues like \"I have had my crate published for years now but now can't use the namespace with the same name to put other crates in\".\n\n* * *\n\nRandom thought I had to post (I have no idea if this would actually be a good system):\n\nWhat if a crate author could simply choose a namespace, even if it is already used by someone else, then store a unique number (or a hash) in Cargo.lock [2] that clearly identifies which one should be used (set on first use and cargo warning loudly if you are adding a crate from a namespace with the same human readable name, with an escape hatch if you really want to use the other one.\n\nExample: Given two namespaces called tokio, one with hash/unique identifier \"AAAA\" and the other with \"BBBB\":\n\n  * `tokio@tracing`: defaults to the first one that was published (or uses the namespace in Cargo.lock)\n  * `tokio@tracing: {version = \"*\", namespace_hash = \"BBBB\"}`: Select which one to actually use, making it possible to use them but with some friction.\n\n\n\n* * *\n\n  1. Imports would probably stay `tokio-util`, not using the namespace at all. ↩︎\n\n  2. Not always committed to git, I know. ↩︎\n\n\n",
  "title": "[Pre-RFC] DNS domains as package namespaces"
}