I see a number of issues with the build process and cyclic dependencies. As one example, just assume that both such dependencies are compiled as a shared library and think about how linking will work.
I actually thought of this. The solution I had in mind was, as that packages with cyclic dependencies are virtually an inseparable entity they just would be a single shared library, if distributed, then in a single zip file, with both package names referring to the same file. (It would probably make sense to restrict cyclic dependencies to packages stemming from the same repository.) So issues are solvable, but it is really not worth the trouble if people don't package according to their D packages on a regular basis, it would only be acceptable if this was only necessary in some weird corner cases where someone needs to stay absolutely compatible with some legacies or something. The fact, that already you want to package your software not according to your D packages, despite knowing all my great good reasons why this is a good idea, is already proving that my proposal is not going to work for a public repository despite all its nice properties :-(
But if the registry could instead just tell you which namespace(s) a package occupies or vice versa, you have a very similar effect (just that the user would have too look at a namespace list instead of a package list to see if a particular namespace is already occupied).
Could be done, the thing is, with my proposal it would not have been necessary. Also to offer a reliable possibility to check for conflicts, the registry has to keep a database of all file names with information about which package in what version(s) installs it. This database could then also be used to find out what package installs a particular import and also my "easy scripting" feature would make use of it.
It is more work and less straight forward, but with a good infrastructure and the right tools it would not be too bad. I guess this is what computers are there for.
The length of the proposal gives a hint of what I mean with complexity. Even if some of it is just examples and some parts are specific to our discussion, it still contains a number of new concepts that every user has to understand on top of what is already there.
The basic concept is a one-liner: "Create a package by specifying its name, the corresponding D package in your source tree will be its contents."
If you know this you would already be set for most packages, another sentence about child packages and you are basically done. The document is long, because I am going quite a bit into details, including sample package.json files and because I am trying to prove my point, explaining why I do that and why I think it is a good idea. But ok I am biased, if it seemed to be complex to me, I would have dropped it before writing it even down.
I really would prefer such a system, where there is a clean relationship between package and name space, too. But at this point I would consider the issues that it creates plus the still unknown benefit as more serious. The fact that we haven't seen an existing system that works like this is another sign of warning.
But I think that just storing a list of occupied name spaces for each package in the registry will lead to nearly the same practical result even without the restriction, so things should not be much worse.
Except that we would need to store a list of all modules not only namespaces, as packages are no longer restricted to a particular namespace.
I have to think a bit more about the consequences of not implementing my proposal, but with the right infrastructure and tools available, most issues should be solvable. E.g. having an IDE showing me the containing package name when I hover over an import line, having a commit hook that calls dub with some parameter that checks for conflicts with the registry, ...
Just let me say it one more time, that this all wasn't necessary if only .... :-) Ok, I had to do it, it is hard giving up a baby.
(Off topic: Did you send any mail today or yesterday by chance? I'm asking because my server had a harddrive failure after a power outage and I had to use a one day old backup)
No, nothing. :-)