On Sun, 10 Mar 2013 21:14:42 GMT, Sönke Ludwig wrote:

After reading the latest proposal, I'm a bit surprised that it works exactly (except for the new :slot concept) like I thought and my assumptions are actually true. So in particular in my example the following things would be illegal:

  • the main package must not be named "vibe-d", but just "vibe" (bad that it is already named "vibe-d")

True.

  • vibe-core may not have that name because vibe.inet and vibe.utils are also contained in it. In fact there is no way to group these name spaces together in one (really just one) package. Note that I'm not talking about repositories here.
  • vibe-ext has the the same problems as vibe-core

So I would have to actually create one package for each of vibe.* - all of them would be publicly visible in the registry, even if using just vibe.inet or vibe.utils makes not much sense. Moreover I discovered that there are a few cyclic dependencies between some modules (yeah, those should be fixed) - how would I handle those? Allow cyclic dependencies for packages? Seems like no good idea on that level.

If you want to sub-package your vibe package exactly this way, probably, except for those sub D packages which are included in the vibe package itself.

Cyclic dependencies always sound bad, but in this case I don't know what the actual problem of cyclic dependencies is? All it means is that you always get both packages, just like if it was a single one. Reasonable argument: "Why not just make it a single one?" My question: "Why does it need to be a single one?" If this in practice is not the exception, but the rule then of course my proposal sucks! :-)

I have a few comments on the new proposal, but before going further with this, I want to ask again (to use Andrei's words): Does it pull its own weight?

Frankly, I see no problem that would hinder a system to exist that can sufficiently represent the existing library landscape and at the same time enforce that package name/name space restriction in some way. And your solution (although I still see some issues) may well be able to do that or be extended to do that. But that is not the important question.

The real question is, what is better:

  • Relatively complex(*) system, but (also just partially) enforced rules

  • Simple system with just convention

(*) And I don't (just) mean implementation complexity

Also, if you think about it, the :slot solution is basically not much different than allowing arbitrary names, just that there is a prefix that coincides with the name space.

Exactly and this nice property makes it straight forward to see what name spaces are already claimed by just looking at available packages. It also makes it easy (for both tools and humans) to find the package belonging to some import. Conflicts can easily be avoided and especially can not be introduced by accident and if they occur they are already detected by the package manager and don't simply cause the compiler to use the wrong module(s) silently.

About complexity: One nice property of my proposal is, that creating multiple packages from a single repository is as easy as specifying a name, which causes the corresponding D package to be a package-manager package.

Do we want repositories to export multiple packages in the future? And if yes, how would you do it?

I am of course biased, but I still don't consider the proposal to be complex, rather straight forward. Of course, good reasons why one would like to have a package-manager package which is not a single D-package, would cause the proposal to be doomed. Your example based on vibe, is in fact quite a good one, if having non standalone packages and cyclic dependencies are considered a problem.

Having said this, as I don't know how to enhance this proposal any further, neither on a technical basis nor on a marketing/explanatory basis, I reached a point where I can say if I haven't convinced you yet and users don't like it either, I am good to drop it and accept that D-packages don't map as nicely to package-manager packages as I thought they would.

The proposal builds on the assumption that the D-package is the natural way of grouping things together, if in practice this is not the case and it is frequent that you want to group things differently, then this proposal is in fact just making things more complex, instead of making them easier and should by all means be dropped.

Best regards,

Robert