On Sat, 09 Mar 2013 20:10:12 GMT, Jonathan M Davis wrote:
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.
In some cases I think it can be good to have some kind of enforcement, but I tend to agree here - it has a lot of implications and I'm still not sure of the actual practical benefit (maybe a conflict indeed never occurs because everyone is careful enough, or libraries that conflict are never actually used together, or only one of the conflicting packages is used at all).
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.
I think this case could be handled by Robert's proposal of multiple sub packages inside of a single package description. He wanted to get something up on a wiki shortly.
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.
Agree, that was also one of my concerns (2.).
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.