-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
don't load packages into Main
by default?
#17997
Comments
+1 for changing it to Root. Right now, writing PyCall = 0
module B
using PyCall # LoadError: invalid module path (PyCall does not name a module)
end |
I also believe it makes more sense to separate Root and Main. |
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. |
|
Something like that may be necessary. Seems unfortunately long-winded though. |
We've discussed the following design: |
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 haveIf I do
using A
at the prompt, I also seeB
defined. However when other modules dousing A
they don't seeB
at all. (Note this does not have the same effect asusing B
at the prompt; you only see the symbolB
itself, and still can't see things from insideB
.)In the original implementation of modules in 2012 there was a module called
Root
where packages were loaded, and interaction happened inRoot.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.
The text was updated successfully, but these errors were encountered: