Relevant paths when using source()

[caldwellst]

Hello, I have a project stucture like so:

├── box_test.Rproj
├── run.R
├── src
│   └── a.R
└── utils
    └── help.R

Some various modules are in utils, as a simple example we might have:
help.R

#' @export
summer <- function(x, y) x + y

I can easily use relevant pathing to refer to the utilities folder in a.R.

a.R

box::use(../utils/help)
help$summer(1, 2)

This works when running interactively in RStudio or calling the script directly from the terminal with Script src/a.R.
However, I want to have a file to run everything, in this case I'm using run.R. When using source(), it generates an error because the path is searching from the top of the directory.

run.R

source("src/a.R")
#> Error in box::use(../utils/help) :
#>     unable to load module "../utils/help"; not found in "..."

Is there a way to source or run files so that the module relevant paths are done directly from the sourced file? I have tried using local = TRUE and local = new.env() in the source() call, and using sys.source(), and nothing has worked.

Interestingly, if I instead switch the entire project to use {renv} I have no issues using run():

box::use(renv)
renv$run("src/a.R")
#> [1] 3

However, I am looking for a way to do this without requiring {renv} and wondering if I am missing something simple.

[klmr]

Is there a particular reason you are using source() rather than box::use()? In general the use of source() in conjunction with ‘box’ modules is not supported.

As a workaround you could use box::set_script_path() to explicitly tell ‘box’ about the path of your script. But this function is intended only for unforeseen circumstances which ‘box’ should handle but doesn’t. I’m not sure whether I would count using source() in that scenario.

See also: FAQ: Can I call library/require/source inside a module?

[klmr]

I should add for completeness: ‘box’ could handle this (it just currently doesn’t). If there’s a good reason why using source() is needed, I will add support. However, absent a good reason I am very reluctant to do this, since it would slightly slow down every call to box::use().

[caldwellst]

I was hoping there might be a solution similar to Python's subprocess module, but even the R {subprocess} package has been archived a few years ago. In this case, I can easily do what I want by simply calling the scripts individually from bash rather than R. Given the issues with source() that go beyond box::use() and your response, I think I'll rely on that. Thanks for the reply!

[klmr]

Regarding subprocess execution, R has two equivalent packages:

• ‘processx’ provides the general functionality of spawning and communicating with subprocesses.
• ‘callr’ builds on that to provide convenience functions to spawn R subprocesses.

It’s worth noting that ‘callr’ messes with the system environment in the R subprocess, which may in some cases lead to issues with ‘box’ specifically, which is unfortunate. The related ‘box’ issue — #199 — is still open because I couldn’t find a good solution so far (ideally it would be fixed in ‘callr’ but that won’t happen because it would require massive architectural reworking). The workaround at the moment is to call box::set_script_path() with the calling code’s path in the child process.