Relative paths based on Rproj like here::here?

[dereckmezquita]

I have a project structured as such:

• main_project
  • main_project.Rproj # here uses this as an anchor for paths
  • utilities
    • some_R6_module # this has an R6 class I want to use in other places in my projects and sub-projects
  • sub-project1 # I want to use the R6 class from here without having to do ".."

Sometimes I work from my main project open in vscode and sometimes I open a sub-project up in a separate vscode window.

I tried to understand how relative paths work for box:

1. If I open the main project up and do box::file I get the top level of the project this is logical - main_project
2. If I open the sub-project and do box::file I get the top level of the sub-project
   1. here::here gives main_project as root since it detects the Rproj file

I want to be able to write code in my projects and sub projects and not have to modify the paths based on which project I have open in a window.

# now from main_project I have to do this
box::use(./utilities/some_R6_module[ R6_class ])
# but from a sub-project I have to do this
box::use(../utilities/some_R6_module[ R6_class ])

# here solves this by keeping the root relative to where the rproj is
here::here(".") # always returns main_project as root
box::file() # returns the top level of the current window open in vscode

Can I use box::use with a string; can use it in conjunction with here::here.

[klmr]

I’m trying to understand the problem you are experiencing but unfortunately I am having trouble with that. From your description, everything seems to work as expected.

I think the issue boils down to a mismatch in the mental model — and please correct me if I am wrong. Here’s what I think the situation is: you have an R project with several submodules, and you treat that project as a single unit. By contrast, ‘box’ has no concept of projects, only of modules. That’s because R itself does not have a concept of projects. RStudio does, but not everybody is using RStudio, and RStudio projects are not suite for all types of R code.

As a direct consequence of that, ‘box’ resolves all paths relative to the current (= calling) module. This behaviour is consistent across box::file() and box::use() (when using relative imports). The advantage of this is that we don’t need a project infrastructure. ‘box’ modules work regardless of the circumstances.

So if you want to use module import declarations relative to the project root I’m afraid you can’t, since there’s no such thing as a “project root” in R. ‘here’ uses error-prone heuristics to detect the project root¹ and ‘box’ intentionally does not rely on it. Think of (sub)modules as packages, not as projects. Inside a package in R you cannot call here::here() to find other packages, or files inside the package. You would rely on R’s import mechanism and on system.file(). ‘box’ modules are the same.

The correct, intended way of loading related modules is therefore via relative paths, indicated by the prefixes ./ and ../.

To answer your concrete questions:

1. “ Can I use box::use with a string” — No, because the parameters of box::use() are intended to be static (think of them as code, not data). It is possible that future versions of ‘box’ will support dynamic parameters to box::use(), but this is reserved for very rare scenarios, and should definitely not be used in the current situation.

2. ”can use it in conjunction with here::here” — No, see explanation above, and footnote. To be clear, this isn’t a limitation of ‘box’; if ‘here’ worked properly, ‘box’ would use it. But ‘here’ is fundamentally unsuited to be used in reusable code since it assumes (incorrectly!) that the location of the code being executed is related to the value of getwd().

3. Will ‘box’ support projects in the future? — There are currently no plans for this: everything that would work with projects currently already works, just via a different route. Rather than specifying the path of a module relative to the project root, it’s specified relative to the current module. As far as I am concerned, one way works as well as the other (in fact, the current way works slightly better). However, I am open to counter-arguments. If somebody can present a case for supporting R projects in ‘box’, such support might be added. But because of the reasons outlined here, it won’t use here::here() (nor RStudio specific files, at least not by default).

---

¹ To illustrate why, here::here() relies on the value of getwd() to detect the project root. This works in RStudio projects that you are executing from within RStudio and a few other scenarios. But it fails in general. For example, consider an R application my_r_app, which is stored on a POSIX system under $HOME/.local/bin/my_r_app. This application will never be executed from inside the $HOME/.local/bin path. Instead, users will execute this app from other directories, e.g. from $HOME/my/project. In this scenario, if my_r_app calls here::here() this won’t just fail, it it will silently return a wrong value! And for the same reason it also fails when used in a reusable module which is not part of one specific project (but instead installed globally). box::file() is the equivalent of system.file(), not of here::here(). And here::here() must not be used in reusable code.