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.
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.
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.
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).
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.