On Sun, 10 Mar 2013 10:39:39 GMT, Sönke Ludwig wrote:

On Sun, 10 Mar 2013 10:03:21 GMT, Robert wrote:

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.

In that case I dont' see how anything is to be enforced here? The only thing would be that e.g. vibe-core and vibe-ext both share a common prefix with their D packages, but technically the name now tells nothing about conflicts anymore.

It does, first of all you are only allowed to used vibe.core because it is specified in the vibe package to be a sub-package, so the vibe package explicitly gave away this part of its namespace (if you created a vibe/core directory later it would be part of the vibe.core package not vibe). Second any package may pull in dependencies, regardless whether it is empty or not, this does not prevent you from looking up in the registry whether a particular name is already taken. The point is, that it suffices to look at available packages and you know what name spaces are already claimed. Also a user won't get surprised because some package he uses, exports an completely unrelated (even undocumented) D-package. There is no problem if a package claims a name space that is effectively not used.

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.

As said, this was just an example that I quickly put together. However, the thing with all the vibe-ext packages is that I would like to have them completely separated out at some point (the JSON/BSON stuff would actually great to have in Phobos), but don't want to break backwards compatibility now. So at some point they would not even live in the vibe.* namespace - to me it doesn't make much sense to split this up now and create the impression that those are good to use outside of the vibe context - they are, but only after they have been properly extracted.

If vibe.data depends on std.stream you would just add it to its dependency list. Sub-packages which are not really standalone or are just tiny, would remain part of the vibe package.

Note that this kind of fine-grained splitting of packages would have been a PITA back when vibe started and no package manager was available, which is why all the common functionality today is concentrated in vibe.d itself. If one had been available, I would have separated them out right from the start.

You don't have to put stuff in a separate repository to make it a separate package. In the easiest case, a single line added to package.json would suffice to create a sub-package.

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.

As said in my mail, this public sub-package concept adds some complexity and I'm really not sure about the value it actually gains. It's quite possible that I'm wrong on that, but up to now I still can't see the compelling argument. I also fear that the registry might end up with a plethora (exaggerated) of small sub-packages that have no actual use by themselves (e.g. I may be wrong, but I think nobody would use those org.* DWT sub-packages in isolation, but always as a whole, no point in making them all so prominent in the registry).

The only reason where you would get "unwanted" sub-packages would be that you have more than one group of sub-packages to be published separately and even in this case I don't really see a problem with small packages if you have automated dependency resolution, also the creation of sub-packages is trivial for the developer. You only have to specify the name and dependencies.

Having said this, you are right that this is an actual drawback of the proposal: If you want to split up a package in smaller ones and those sub-packages don't match your D-packages, you end up in having some packages in the registry which might never get used standalone.

So no restructuring needed, it would just work.

I'm looking forward to the new proposal, as I obviously got a bit behind with your latest ideas. I'll have time in the evening to read through it properly.

I hope to have an updated/improved version online by then.