Skip to content
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

Closed
JeffBezanson opened this issue Aug 12, 2016 · 6 comments · Fixed by #23579
Closed

don't load packages into Main by default? #17997

JeffBezanson opened this issue Aug 12, 2016 · 6 comments · Fixed by #23579
Assignees
Labels
breaking This change will break code design Design of APIs or of the language itself modules needs decision A decision on this change is needed
Milestone

Comments

@JeffBezanson
Copy link
Sponsor Member

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.

@JeffBezanson JeffBezanson added needs decision A decision on this change is needed breaking This change will break code design Design of APIs or of the language itself modules labels Aug 12, 2016
@cstjean
Copy link
Contributor

cstjean commented Aug 12, 2016

+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
Copy link
Contributor

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

@StefanKarpinski
Copy link
Sponsor Member

StefanKarpinski commented Feb 8, 2017

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
Copy link
Contributor

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

@StefanKarpinski
Copy link
Sponsor Member

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

@JeffBezanson
Copy link
Sponsor Member Author

We've discussed the following design: using Foo resolves Foo to some identifier like a UUID or absolute path, depending on the environment the using Foo occurs in. We keep a table mapping those to modules, and creating named bindings for modules is de-coupled from that. So packages will not get bindings in Main or any other module by default.

JeffBezanson added a commit that referenced this issue Sep 4, 2017
JeffBezanson added a commit that referenced this issue Sep 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This change will break code design Design of APIs or of the language itself modules needs decision A decision on this change is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants