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.
somecrate = { git = "https://...." }
other-crate = { version = "1.0", registry = "my-registry" }
https://doc.rust-lang.org/cargo/reference/source-replacement...
crates.io could be updated to support alternative registries.
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.
https://maven.apache.org/guides/mini/guide-naming-convention...
These problems simply wouldn't exist.
Java and .NET have a couple of good ideas even if they aren't fashionable any longer.
For extra bonus points, the Java directory structure being built around it is just silly, related code ends up far away in the directory tree, just because you went through a rebranding or a merger.
Seems to be working for multiple decades without issues ?. If an organization is acquired (like Sun), they still have access to their namespace. It doesn't magically go away.
> For extra bonus points, the Java directory structure being built around it is just silly, related code ends up far away in the directory tree..
This is just your opinion. Many people like this systematic nature of directory hierarchy for segregation. Also, you do not require to follow this source language convention in case you don't like it. It is only required that the compiled class be in a nested directory structure for class-loader pickup
Ie You can still you put custom_src/foo/MyClass.java with package com.bingo.tringo;, it’ll still compile, and Maven will output: target/classes/com/bingo/tringo/MyClass.class
It doesn't matter what you call it, and what the files are called; two COM objects could both be FFMPEG.DLL or whatever (obviously not installed in the same directory).
When it comes to packages, users interact with the names and are used to writing names into their code when they specify dependencies, so it's not a complete no-brainer solution; but maybe some idea from that solution space could be worked into a package management system.
Wouldn't reusing the name of a package that is no longer maintained create chaos for programs that use the discontinued package.
Maybe it's not simply one-sided gatekeeping from the former managers of the package?
It's just like giving external users self-modifing code access - asm, lisp, js - let's they upload it and we execute ;)
#DONOTSENDCODE Manifesto, where ?