possible fix for unable_to_load_module x in path y

[zackarno]

I get this type of error every time I restart my R-session and first try to load a custom module. After the first error, it tends to go away.

Error in box::use(./module_name) : 
  unable to load module “./module_name”; not found in “/directory/path”

@caldwellst @hannahker - do you get this also? I guess the GH runner doesnt!?

@caldwellst I remember we talked about this somewhere , but don't think we came to a clear solution and I wasn't able easily find the discussion.

Anways, the {box} FAQ page describes a very similar, but slightly different (I think) error message and the solution proposed it just to run this:

box::use(r/core[...])

This does stop the error from occurring on my computer as well. It seems kind of annoying to put at the top of every script though. If this is in fact a good solution, I wonder if it could possibly make sense/work to have some sort of onLoad() type deal for it .

[caldwellst]

That's not what using the core functions does. box::use(r/core[...]) solves the error you find if you try to run functions like View() or read.csv(), because they are not attached by default in {box}. So, you have to do:

box::use(utils)
utils$View()
utils$read.csv()

The error you describe above is one that I get when I am interactively running line by line through a script in RStudio into my R console. It seems to be an error with not recognising the relevant pathing, but has nothing to do with the solution above, hence why there are never errors if you run the scripts from your terminal or on GitHub Actions. I've tried to look for this issue on the {box} repo before, but haven't found anything. Will have a look again and post something on there.

[caldwellst]

klmr/box#365

[zackarno]

yea interesting, but I wonder why box::use(r/core[...]) does fix it!? I wonder if one of those non-base, but core packages that are typically loaded in R-sessions somehow help?

glad you opened an issue though - that should be informative!

Two additional things I noticed:

• Don't think it has to do w/ command + enter workflow. Happens if you just copy paste into the console.
• Does not happen if you are working in script saved to root .rproj directory.

[zackarno]

A consequence of this error that is probably more significant than needing to run in 2x when running interactive is the fact that it makes the {reprex} package unusable. Wonder if this has been documented

box::use(./src/utils/get_iso_sf)
#> Error in box::use(./src/utils/get_iso_sf): unable to load module "./src/utils/get_iso_sf"; not found in "/private/var/folders/61/cp06zhcj4y76q7rfx0qlm06c0000gn/T/RtmpXLAzDs/reprex-1642952289f88-bad-grub"

^{Created on 2024-05-28 with reprex v2.0.2}

[caldwellst]

Don't think it has to do w/ command + enter workflow. Happens if you just copy paste into the console.

You can't use those relative imports in the console, because it will only source based on the working directory, not where the file is source.

Does not happen if you are working in script saved to root .rproj directory.

Yep, because as above the search dir is the working directory.

A consequence of this error that is probably more significant than needing to run in 2x when running interactive is the fact that it makes the {reprex} package unusable. Wonder if this has been documented

You have to specify the directory in reprex::reprex() using the wd parameter, so that box::use() relative sourcing works.

[caldwellst]

yea interesting, but I wonder why box::use(r/core[...]) does fix it!? I wonder if one of those non-base, but core packages that are typically loaded in R-sessions somehow help?

I doubt that this actually helps! For me, what I have noticed and flagged in that issue on the {box} repo itself is that it seems to be an error in the RStudio API detecting the path of the file being sourced. But that seems to go away if I run other pieces of code at the same time or re-click into the file and click run. So maybe running something else first helps the RStudio API locate the file path accurately each time, but there's no reason that importing core should work.

[caldwellst]

Closing, and we can hopefully get some information in klmr/box#365. However, may be an issue outside of the control of {box}, remains to be seen what the maintainer of {box} thinks.