Obviously we can't publish our own rune-XXX sub-crates because it'll confuse the users of both projects and there are also a couple direct naming conflicts so publishing as-is just wouldn't work.
How would you go about this problem?
One thing I thought of was prefixing the crate's name with our organisation (e.g. hotg-rune-cli) but the names start getting a bit unwieldy for crates like hotg-rune-proc-block-macros.
Note: I'd prefer to avoid talking about hypothetical crates.io features if I can. The topic of namespacing (e.g. @hotg/rune-cli) has gone around in circles with no resolution for at least the 5 years I've been in the community, and there is no need to keep beating a dead horse. Hypothetical features are also no help because they don't exist.
I think if it were me, I would go the clunky route by prefixing the name with your org's name if I really liked the rune name for the project. Otherwise, I might try to pick a different name for the project itself. Changing the name of a project sucks though, so that's not a great choice either.
With respect to crate names becoming unwieldy, I would note that hotg-rune-proc-block-macros isn't that much worse than rune-proc-block-macros. The latter name is kinda already clunky on its own.
While this doesn't help your situation now, whenever I think of a name for a project, I check to make sure it's available on crates.io first. If it isn't, then I look for another name until I'm able to actually reserve it on crates.io.
You can theoretically also put the name of the organisation on the end of the crates name, like rune-proc-block-macros-hotg. In this way it doesn't matter how long the name of the organisation is. Also, like @BurntSushi said to rune-proc-block-macros:
But if the original name would be more like rune-cli, and just the name of your organisation is very long, like the future of rust programmer, then you should think about a short way for your organisation, if possible.
Have people experimented with having the crates.io package name separate from the crate name? There must be both pros and cons with that. Since cargo supports renaming deps, it shouldn't cause any problems for rdeps.
I would consider topic-rune-part instead of company-rune-part. The rune currently on cargo seems to be an embeddable dynamic language, while yours seems to be about containerized machine learning. So maybe ml-rune-part or ai-rune-part or something?
That's a good idea. We could tell people to use something like this in their Cargo.toml.
rune-syntax = { package = "hotg-rune-syntax", version = "1.0" }
That's a good point. I guess another option is to copy numpy and matplotlib from the Python world and tell people to use an alias when importing (e.g. use rune_proc_blocks as rune_pb). I'm fine with a longer name as long as people don't need to type it out in full every time.
I think that would be very harmful for new rust programmers when they are trying to understand the ecosystem. In the worst case, you could end up with crate A having package name B, and crate B having package name A, which would make referring unambiguously to either almost impossible. You could also end up with a project that depends on two crates with the same name, because uniqueness is no longer enforced. I know there are workarounds and it wouldn't entirely break the language, but I think it adds an unjustifiable amount of complexity given the small magnitude of the problem it fixes.
It took me some time to understand feature flags at first, I thought adding the dependency in cargo.toml was all I needed to do and it made no sense why my code wouldn't compile. This sounds like that kind of confusion, but 1000x worse.
