On Mon, 11 Mar 2013 13:05:52 GMT, Robert wrote:

  • 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 see a number of issues with the build process and cyclic dependencies. As one example, just assume that both such dependencies are compiled as a shared library and think about how linking will work.

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.

But if the registry could instead just tell you which namespace(s) a package occupies or vice versa, you have a very similar effect (just that the user would have too look at a namespace list instead of a package list to see if a particular namespace is already occupied).

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.

The length of the proposal gives a hint of what I mean with complexity. Even if some of it is just examples and some parts are specific to our discussion, it still contains a number of new concepts that every user has to understand on top of what is already there.

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.

I really would prefer such a system, where there is a clean relationship between package and name space, too. But at this point I would consider the issues that it creates plus the still unknown benefit as more serious. The fact that we haven't seen an existing system that works like this is another sign of warning.

But I think that just storing a list of occupied name spaces for each package in the registry will lead to nearly the same practical result even without the restriction, so things should not be much worse.

(Off topic: Did you send any mail today or yesterday by chance? I'm asking because my server had a harddrive failure after a power outage and I had to use a one day old backup)