don't load packages into `Main` by default?

[JeffBezanson]

This came up recently and there doesn't seem to be an issue about it.

The problem is that Main is both the default interactive namespace, and the "root" namespace used for loading packages. For example, say we have

module A
using B
end

If I do using A at the prompt, I also see B defined. However when other modules do using A they don't see B at all. (Note this does not have the same effect as using B at the prompt; you only see the symbol B itself, and still can't see things from inside B.)

In the original implementation of modules in 2012 there was a module called Root where packages were loaded, and interaction happened in Root.Main. We decided this was more complex than necessary and changed it pretty quickly, just a couple months later I believe.

I don't feel like I have tripped over this issue much myself, but it bears discussing.

[cstjean]

+1 for changing it to Root. Right now, writing X=0 will mess up any package Y that imports X.

PyCall = 0

module B
using PyCall   # LoadError: invalid module path (PyCall does not name a module)
end

[TotalVerb]

I also believe it makes more sense to separate Root and Main.

[StefanKarpinski]

There's a somewhat trickier problem to consider: with federated registries, different projects can consider the same top-level package name to refer to different packages. Thus, having a top-level root namespace at all becomes problematic. I'm not entirely sure how to best handle this, but it's pretty crucial for Pkg3.

[TotalVerb]

Root.Metadata.Foo vs. Root.MyFederatedRegistry.SubRegistry.Foo?

[StefanKarpinski]

Something like that may be necessary. Seems unfortunately long-winded though.