make `using .A` syntax work

[Pangoraw]

not sure what we did here

fixes https://github.com/fonsp/Pluto.jl/issues/1795.

[github-actions[bot]]

Try this Pull Request!

Open Julia and type:

julia> import Pkg
julia> Pkg.activate(temp=true)
julia> Pkg.add(url="https://github.com/fonsp/Pluto.jl", rev="wat")
julia> using Pluto

[fonsp]

How is this PR going?

[disberd]

@fonsp, @Pangoraw,

What would be required still to test/merge this? I tried to make a more recent PR on my fork to check if tests pass after latests changes in main and everything seems to pass (see https://github.com/disberd/Pluto.jl/pull/327)

The amazing thing about this PR (for me at least) is that it would allow me to move most the evaluation I do in PlutoDevMacros to runtime rather than compile time, which will allow me to have progress bars and simplify quite a few things. At the moment with everything happening at compile time, and with macro expansion not being reactive to logs (and not showing runtime in pluto) it can be sometime weird to wait for potentially long without anything clearly happening.

I still do not understand why, but with the very small change in this PR using local modules work and it also respects exports that are added at runtime using Core.eval, as shown below:

https://github.com/user-attachments/assets/2d6d770f-70c7-4dd4-bc4e-ccb4c21b7ccc

This is actually mind blowing 🎉

Notebook Code

# ╔═╡ d699cc81-bbd9-43f4-90f0-869a01a54d71
using PlutoUI

# ╔═╡ 79152609-ac03-4e55-8222-cb8329c06763
random_names = map(Symbol, 'a':'z') 

# ╔═╡ 8a20fbe5-9130-4e5c-8c80-a8b39d667c37
@bind wat Slider(random_names; show_value = true)

# ╔═╡ b7d4beda-6547-11ef-0a87-6bf0adbc0817
begin
	@eval module ASD end
	Core.eval(ASD, :($wat() = (; $wat = rand())))
	Core.eval(ASD, :(export $wat))
	using .ASD
end

# ╔═╡ 4a914dd9-7550-4fbe-b408-9feaeb8238aa
let
	m = @__MODULE__
	whatdefined = filter(n -> isdefined(m, n), random_names)
	@info "WAT" m wat whatdefined
	Core.eval(m, wat)()
end

[Pangoraw]

After giving it a new look, this seems like a sane approach.

• For packages doing the reimport after moving variables will not affect the result since packages are not looked in the module environment.
• This enable using .A globally because the A module is now moved before running the global using.

I would like to add tests for the behavior.