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

Can't track modules with same name as existing packages #747

Open
bencelder opened this issue May 9, 2023 · 2 comments
Open

Can't track modules with same name as existing packages #747

bencelder opened this issue May 9, 2023 · 2 comments

Comments

@bencelder
Copy link

bencelder commented May 9, 2023

Making a module with the same name as an existing package throws an error. For example, in "test.jl" I have

module Test
using BenchmarkTools

function test()
    @btime rand()
end

end

Now at the REPL if I do

> using Revise
> includet("test.jl")

I get an error:

ERROR: ArgumentError: Package Test does not have BenchmarkTools in its dependencies:
- You may have a partially installed environment. Try `Pkg.instantiate()`
  to ensure all packages in the environment are installed.
- Or, if you have Test checked out for development and have
  added BenchmarkTools as a dependency but haven't updated your primary
  environment's manifest file, try `Pkg.resolve()`.
- Otherwise you may need to report an issue with Test

Doing the same thing without Revise, and just using include("test.jl") works without any problems.

This issue goes away if we rename the module Test to something else, like Test2. I think this is happening because of a name collision with the unit testing package Test.jl. I'd just generally expect includet to behave more like include in this instance, or at the very least for the ERROR message that gets thrown to be more informative as to the real source of the issue.

@timholy
Copy link
Owner

timholy commented Jan 1, 2024

This is really hard to fix. It's running up against two factors:

  • JuliaInterpreter's ExprSplitter code, which is a crucial tool for resolving world-age issues. Specifically, you can see that we work really hard to resolve names that match those of stdlibs, because that's the REPL approach. At the REPL and specific other places in Julia's internal C code, the world age updates at each Julia prompt, but we don't have that luxury in ordinary compiled Julia functions. Since Revise is written in Julia, we have to use slightly different techniques, and this is one way it shows.
  • Revise ends up re-evaluating code that has already been loaded. That is why we can't take module Foo ... end at face value and always create a new Foo module, because we might be re-parsing code that has already been loaded.

Fixing this might require a complete redesign of how Revise works, which can't happen until JuliaLang/julia#31162 is fixed.

@timholy
Copy link
Owner

timholy commented Jan 1, 2024

I added a test for this issue in #788 but that can't be merged until it gets accompanied by a fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants