I see, I missed that. It could be a little problematic with IDEs, although doable.

How come? The code would only be also made available in an import directory, which is used for -I.

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.

I'd love that.

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

I think having such a tree available is always a good idea, except all packages adhered to the D package = package rule, but in this case we could as well have implemented my proposal ;-) Of course this tree could be factored out onto a different server and would not have to be part of the registry (also any automatic conflict check could be dropped, if they never seem to happen). But having a reliable way to determine what name spaces are in use seems to be valuable, also mapping files to packages and vice versa is a functionality that comes in handy at times.

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

I know what you mean, I should be learning now and not discussing stuff I care about on the internet ;-)

Best regards,
Robert