Eric Hanson

Here is the context btw: https://discourse.julialang.org/t/decomposing-an-eeg-signal-from-scratch/115904/6

ah, right, 90 days: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow I think that makes this idea untenable; we need persistent state and artifacts don't give that.

The problem is we can’t see through macros to know new names are being defined. We could probably special case some macros that we know about though. prior art: https://github.com/julia-vscode/StaticLint.jl/blob/master/src/macros.jl...

MWE: ```julia module TestMacro using EnumX: @enumx using LinearAlgebra @enumx ApplyStrategy Transpose Inplace function my_method() ApplyStrategy.Transpose end end #TestMacro ``` yields ```julia julia> print_explicit_imports(TestMacro, "test/test_macros.jl") Module Main.TestMacro is relying on...

I think by doing a fully-dynamic introspection of the module as you suggested in #76, I can probably handle dynamic includes for-free, since there may be no parsing needed anymore!...

This is pretty tricky, since the second `norm` (the default arg) should not really be see as inside the scope of `f`. BUT if we had `f(norm=norm, b=norm) = b`,...

often it means dynamic include statements, but I don't see any there. If you do `print_explicit_imports` it should show which modules aren't analyzable. Also try setting `ENV["JULIA_DEBUG"] = "ExplicitImports"` first....

interesting, I have a test for extensions but it doesn't include submodules in the extension, so something must be going wrong there, thanks for the report

Thanks Tim, this is really helpful! I will give it a try.

Is there a way to get lowered top-level code in a module? I'm having trouble finding a way to do that, which would be nice since then we might be...