[vocx2tx]

The real issue here is Rust's flat namespace. In Go, for example, there's no ffmpeg crate, there's github.com/someone/ffmpeg and gitlab.com/someone-else/ffmpeg, and so on. There's no blessed, unique 'ffmpeg' package, you can't squat names, and if the first package gets abandoned, you can fork it under a new path while keeping the 'ffmpeg' name. Only the import path changes.

[stmw]

How does having more namespaces address the other half of the issue, of having multiple incomplete ffmpeg crates and having to decide which one to use and to support?

[kazinator]

In a hierarchical namespace, two different flavors of ffmpeg would fall into the same branch of the hierarchy.

It would be confusing and counterproductive to introduce, say multimedia_libs/ffmpeg because codec_libs/ffmpeg was discontinued.

A level of hierarchy does when projects in genuinely unrelated categories share a package name.

[burnt-resistor]

Not entirely true. Rust (cargo) supports git-based crates and more crate sources than just crates.io (registry = "crates-io"), however crates on crates.io doesn't currently support dependencies with crates in other registries.

    somecrate = { git = "https://...." }
    other-crate = { version = "1.0", registry = "my-registry" } 

It also supports source replacement downstream:

https://doc.rust-lang.org/cargo/reference/source-replacement...

crates.io could be updated to support alternative registries.

[kevincox]

Now instead of having the 2nd and 3rd packages have ugly names all of them have ugly names!

There are advantages to systems like this such as trust (I can tell that you.example/pkg1 and you.example/pkg2 are owned by the same person) and decentralization. But I don't think it helps with the later packages having ugly names.