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

variables imported via using in previous notebooks are not visible #11

Closed
disberd opened this issue May 8, 2023 · 2 comments · Fixed by #48
Closed

variables imported via using in previous notebooks are not visible #11

disberd opened this issue May 8, 2023 · 2 comments · Fixed by #48

Comments

@disberd
Copy link
Owner

disberd commented May 8, 2023

Right now the package relies on Base.names to find out all the variables that are defined in the submodule containing the target of @frompackage.
This unfortunately does not expose the names of the variables that are imported in a module when simply using other packages.
See https://discourse.julialang.org/t/get-all-names-accessible-from-a-module/98492

This means that the behavior of @frompackage can not exactly mimic the chain of inclusions inside of the target Package source code.

Take as example the two notebooks inner_notebook1.jl and inner_notebook2.jl in the TestPackage

While inner_notebook2.jl should still se BenchmarkTools as it's imported within inner_notebook1.jl, this does not happen inside Pluto:
image

The current workaround is to also explicitly use the package also inside inner_notebook2.jl. So translate the macrocall from

@fromparent import *

into

@fromparent begin
    import *
    using >.BenchmarkTools
end
disberd added a commit that referenced this issue May 8, 2023
@disberd
Copy link
Owner Author

disberd commented Jul 8, 2023

It seems this also applies to names explicitly imported with the synthax using Package: name. Doing import Package: name does instead make the imported name visible also when calling using * in @fromparent

@disberd
Copy link
Owner Author

disberd commented May 25, 2024

Will be closed when #48 is merged. Check the PR for details.

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

Successfully merging a pull request may close this issue.

1 participant