On Sun, 10 Mar 2013 08:16:44 GMT, Sönke Ludwig wrote:

I've just discovered that the "package name" equals "name space" convention would actually be quite painful for what I intended to do with vibe.d. That is, I want to split it up several sub packages (the actual split is not yet decided). I really wouldn't want to have to split them up into one package per vibe.* sub package, not even if it is possible to define multiple sub packages within the same repository and directory hierarchy. That's just not the right level to split things up. And the alternative would be to break all dependent code and restructure everything (e.g. for vibe-core: vibe.core, vibe.core.inet, vibe.core.utils), which is also not the intention.

Example split:

vibe-d -> vibe-http, vibe-mail, vibe-db
 - vibe.vibe
 - vibe.d

vibe-core
 - vibe.core.*
 - vibe.inet.*
 - vibe.utils.*

vibe-ext -> vibe-core
 - vibe.data.*
 - vibe.stream.*
 - vibe.templ.*
 - vibe.textfilter.*

vibe-http -> vibe-ext
 - vibe-http.*

vibe-db -> vibe-ext
 - vibe.db.*

vibe-mail -> vibe-core
 - vibe.mail.*

Hmm, first of all you don't have to create a subpackage for each sub-D-package in vibe, you can have some be included in the vibe package and some being extensions. Second, to take vibe-ext as an example. You have an awesome JSON framework in vibe.data, much better than the one in phobos. If I wanted to use it, I would have to pull in also vibe.stream, vibe.templ? Even if I don't do any vibe based website? To me it seems that the split up per D-package is also in this example a good idea. On the other hand having something like a taskset "vibe-ext" which pulls in a number of sub-modules might of course be good idea and could easily be achieved without even a single extension to my design (which still needs to be published), just create an empty vibe.ext package, which just depends on the corresponding sub packages. Simply put a sub-package in your package.json named "vibe.ext" without a vibe/ext folder actually existing so the package would be empty but you can specify arbitrary dependencies to be pulled in. This way you get the desired grouping, but with the additional benefit that the user can actually also just use a subset you might not even have thought of to be useful.

So no restructuring needed, it would just work.

Best regards,

Robert