Child Thread: Survey of registry namespace designs for Cargo and Crates.io

[epage]

@kornel

Renaming is super useful from user perspective. If you ever add renaming, then please don't allow reclaiming old names as easily as GitHub. It has the downside of keeping old names occupied/wasted, but otherwise all names lose their uniqueness. Alternatively, give crates some ID/GUID behind the scenes that can be looked up and used as the real permanent identifier that survives renames.

DIsallowing reclaiming is under the requirements at Survey of organizational ownership and registry namespace designs for Cargo and Crates.io. Solutions like UUIDs are being discussed at Child Thread: Survey of alternative identifier designs for Cargo and Crates.io - #6 by dlight.

@kornel

They can have many different teams/departments/divisions/subsidiaries/regions and half-merged acquisitions, making them behave like multiple different orgs that operate separately (publishing things of varying importance and visibility, by different teams, at different schedules), but externally share one namespace.

From my understanding, the feedback received that you are responding to included very large, complex organizations.

@kornel

It's technically quite similar to private registries in Cargo, but Homebrew's user interface makes all the difference. It's trivial to add a tap without editing any config files, so installing packages from taps doesn't feel more complicated or second-class compared to installing core Homebrew packages. It feels more like just installing namespaced Homebrew packages.

Thank you for sharing for getting more insight into how others deal with things.

There had been past discussion along these lines but I felt they were too far out from the existing design that I marked them out of scope. Discussing this further is likely better for Survey of organizational ownership and registry namespace designs for Cargo and Crates.io.