On Sat, 09 Mar 2013 12:11:07 GMT, Sönke Ludwig wrote:

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.

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.

While I definitely think that it would be good practice for projects to use a single package hierarchy, I don't think that it's a good idea to require it. D generally takes the approach of encouraging the safe path while not stopping you from going the unsafe one if you feel that you need to. Granted, this isn't a discussin on @safe, but I think that the same, basic principle applies. Good pratice should be encouraged but not enforced, because sometimes it's not the best way to go.

And think about this: Phobos currently has both the std and etc packages. If it were ever to switch to dub (which I wouldn't expect it to, but if dub were ever to become D's official package manager, maybe it would), it would be screwed by this suggestion. And while it may be better in general to put all of the code for a library in a package named after that library, why should I have to create two separate projects to be able to have two separate package hierarchies? Maybe I want to put two related package hierarchies in the same project but have them be separate (and on that count, it should be possible to create multiple libraries from the same dub package as some projects will need that). As long as the names are unique enough, it shouldn't be a problem at all. And if two projects end up with conflicting packages, then that can be sorted out when it happens. It's unlikely to be common anyway, particularly as most projects should and probably will have a base package named after the project.

Another thought. What if I had two libraries that had the same API but just had different implementations? I could then have two projects with exactly the same package hierarchy and swap one out for the other simply by changing the dub configuration file for my project (or even base it on the configuration - though depending on how dub installs stuff, that may not work). There are other ways to handle that which may be cleaner (e.g. using different version identifiers), but that might be something that someone would want to do. In particular, if a project got forked, the fork may want to keep exactly the same package layout in order to make it easy for other projects to switch over to it, whereas if they were forced to have a base package named after the project, that wouldn't work.

But really, I just think that it's a bad idea to create artificial restrictions on package layout. Sure, there are certain things that would be best practice and should be done normally (e.g. having a single node for a library's package hierarchy, and have that base package be named after the library), but I think that enforcing that is going too far.