On Tue, 12 Mar 2013 20:49:18 GMT, Robert wrote:

You are right, modules in the root package are certainly a problem. Also the app.d file would have to be taken out of the equation.

There should definitely be no warning about the app.d file, maybe just being explicit on what to put into the import path is enough? (See below)

But maybe just counting packages with actual modules + top level modules would work. I just try to get in that direction because I think that detecting just module conflicts is a bit too relaxed and it would be good to come as close as possible to the restricted system in that regard (without introducing child packages, which could of course still be done, even if just for different reasons).

Ok, I'll think about it. The problem is just, that the moment you go looser than the module level, it is very much dependent on how things are organized, for detecting what is ok and what not. That is why I introduced the child packages concept. My current thinking is, that you were probably right and we should rely on people being smart and that packages of "dumb" developers would not be used any way. Meaning it would be enough to provide a way of seeing which namespaces are already claimed by what packages and issuing a warning if you really happen to accidently introduce the exact same module as someone else did already.

You are right. The good thing is that with only warnings (or even just an informational query in the registry) instead of errors, that we can always make the rules stricter (or looser) without breaking anything. So we can lean back and observe how things will look in practice before deciding on concrete improvements.

I think I got your sentence mixed up a bit. Rereading it, I really don't know what I was talking about exactly and need to apologize for the slightly rude tone. I just think the commit hook is not any more or less needed than for the restricted case - just that the restricted case could just check the package name instead + verify locally that no forbidden name space is used.

Actually the proposal was a bit different. There was no need to verify locally, instead any D package found, named like the package name, would just be put into a separate import directory, which is then added to the -I paths, instead of the source directory itself (solving the issue with app.d and other not to be exported files). In fact something like that might still be a good idea, only that now it would have to be specified explicitly what packages should be put in the import directory. We might also need this for supporting multiple packages from a single repository. The beauty of the proposal was just, that no additional configuration was necessary, as the package name already included all the needed information (in the simple case, that the library is pure D), but adding something like "exportedPackages"=["vibe"] to the package.json would do the trick too. If no "exportedPackages" is given, dub could just continue to export the whole source tree, for both backwards compatibility and keeping configurations of trivial packages simple.

I see, I missed that. It could be a little problematic with IDEs, although doable. But let's just see how things turn out over the coming months and then we can decide which additional features or checks we really need. I'd say we document the recommendation to use a single root package with the same name as the package manager package (we really need a unique name for those ;)) in a prominent place and then see how well reality fits that recommendation. If issues crop up, we put additional measures in place (only warnings, never errors) and if all packages get along nicely, we could as well stop with the global package tree database (btw. it's really nice to have that because then we can finally take some objective statistics about the problem domain :)).

Sorry, I can observe myself loosing track of the message while still reading it sometimes as my head is spinning with loads of other things (things like a HDD crash of my mail server didn't help there either). I severely need to get some things done to get my head free...

I understand, to be honest I am pretty amazed on how many things you seem to handle at the same time. vibe, dub, newsgroup/forum activity, bug fixing, user support, ... and those are only the ones that are publicly visible. So no problem at all, if you don't answer for few days because you have more important things to do, I would not mind either.

It's just always tempting to continue the discussion, as it is actually quite a bit more interesting than some of the other (more) important things ;) But well, we'll be doing a small "project vacation" next week to dedicate a block of time purely for one or two topics to get them off the table. It that turns out well, it will make things much more comfortable again (improving automation is one of the topics and that will help to save a big chunk of regular amounts of work).