After reading the latest proposal, I'm a bit surprised that it works exactly (except for the new :slot concept) like I thought and my assumptions are actually true. So in particular in my example the following things would be illegal:

  • the main package must not be named "vibe-d", but just "vibe" (bad that it is already named "vibe-d")
  • vibe-core may not have that name because vibe.inet and vibe.utils are also contained in it. In fact there is no way to group these name spaces together in one (really just one) package. Note that I'm not talking about repositories here.
  • vibe-ext has the the same problems as vibe-core

So I would have to actually create one package for each of vibe.* - all of them would be publicly visible in the registry, even if using just vibe.inet or vibe.utils makes not much sense. Moreover I discovered that there are a few cyclic dependencies between some modules (yeah, those should be fixed) - how would I handle those? Allow cyclic dependencies for packages? Seems like no good idea on that level.

I have a few comments on the new proposal, but before going further with this, I want to ask again (to use Andrei's words): Does it pull its own weight?

Frankly, I see no problem that would hinder a system to exist that can sufficiently represent the existing library landscape and at the same time enforce that package name/name space restriction in some way. And your solution (although I still see some issues) may well be able to do that or be extended to do that. But that is not the important question.

The real question is, what is better:

  • Relatively complex(*) system, but (also just partially) enforced rules

  • Simple system with just convention

(*) And I don't (just) mean implementation complexity

Also, if you think about it, the :slot solution is basically not much different than allowing arbitrary names, just that there is a prefix that coincides with the name space.

But really, before going further into details, I really want to have basis to estimate how much we'd actually (in practice) gain from the whole thing. I have the feeling that all of this solves a problem that doesn't exist in the first place (i.e. I want a proof that these conflicts, not counting forks of the same library, actually happen in reality, in any other package system that doesn't have such rules).

Sorry, I really don't want to simply turn this down, but my gut feeling that all this may do more harm than good has actually grown, even though some issues are resolved by your latest proposal. I want be sure that this is not just wasting time because some precondition was wrong.