So over the last days we have had a long discussion initiated by Robert Klotzner about how a package manager for D should look like. One of the controversial topics was if each package should be restricted to have all source files inside of a single D package. The idea is to allow no conflicting packages to be created, so that all public packages are guaranteed to not cause conflicts during compilation.
I think this approach has some obvious merits to it and would facilitate a very clean way of laying things out as packages. I would also happily adjust my packages to such a system. However, I still struggle with the idea because of some issues:
Existing projects would often violate this constraint and would have to be restructured in one way or another. I think that this might drive some people away and some important libraries may in turn not be available as packages.
It hampers forking projects or crafting alternative implementations since all modules need to be renamed first before publishing as a package. It would also mean that all packages that now depend on the forked package instead of the original need to be adjusted accordingly. This could be mitigated to some degree by meta packages that switch to different implementations conditionally, but those would also need to be maintained by someone and, if they should have a pretty name, it would imply that their existence was planned already before the first original library appeared. Furthermore it would mean that it's author would be the one who solely decides which implementations get supported.
One idea was to force the name of a package to be equal to the root name space for the package (e.g. a "derelict.gl" package would only contain modules below
derelict.gl). There are some precedents where the name differs, so this would be another case of 1. It also would require to rename a number of already existing packages. (As a technical detail, dots are not allowed in package names, but that can be resolved in one way or another)
It would considerably increase the implementation complexity of the registry if it is supposed to be enforced reliably. It would also require more education for people who want to create packages and thus also increase the perceived complexity of the system.
Orphaned packages would clutter up the available name space and some kind of manual intervention would be required to remove those packages. This may be a difficult judgement call as people might still be using those packages (except, if the replacement is supposed to be 100% compatible). Similarly, the first who gets a name space, owns it. Should someone register "derelict" or "deimos" and use it for something else, who decides what happens?
The strict enforcement breaks down with multiple registries as they have no way to know which name spaces are already in use on other registries. This may not be much of an issue though, as long as there is only one main public registry.
There may still be conflicts, for example for string imports or runtime resources. However, these conflicts might even be desirable (e.g. overriding of Diet templates).
How much weight each point has compared to the benefits of this approach varies a lot with personal preferences and available work force. My main concern is number 1. It would be great to get some more opionions on this, especially from people affected by 1 and also to look at how many popular projects would actually have to be restructured.