Warn if working directory has changed since loading the package?

[krlmlr]

Inspired by jennybc/here_here#3 (comment): Perhaps dr_here() should tell the user that the working directory has changed since the package was loaded? Or at least print the w.d. that was effective when the package was loaded?

@jennybc: What do you think?

[jennybc]

I have definitely felt this pain, although not recently. But agree it would be great to have a helping hand / warning flag.

[kmishra9]

Is there a reason here() isn't just reactive to the current working directory? Like that part makes here a pain to use in some cases and I have to actively use setwd() before using library(here), which almost defeats the purpose of not having to think too much about file paths.

To me this is by far the biggest issue with the here package -- it is otherwise a pretty great solution.

[krlmlr]

You shouldn't have to use setwd() at all, as long as your working directory is somewhere below the project directory. Use symbolic links or junctions to create, in your project directory, a directory-like pointer to an external location.

# Linux, OS X
file.symlink(here("path/to/local/link"), "/mnt/some/remote/location")

# Windows
Sys.junction(here("path/to/local/link"), "S:/Ome/Remote/Location")

If you have a use case that doesn't work for you, would you mind asking at https://community.rstudio.com or on StackOverflow?

[kmishra9]

My issue is that I'm collaborating on a GitHub repo with some other researchers and we're working on RStudio-Server together. Any time we log in, our r-session starts our working directory off at the top level of of our home folder (i.e. ~/).

I have directory X at the path ~/dirX/. But my colleague has the same cloned GitHub repo at their ~/dirY/dirX.

If we run our scripts without doing anything, we both get that the data cannot be found, since here::here() returned ~/ in both of our cases. So then we setwd() to our respective GitHub repos (i.e. setwd("~/dirX") or setwd("~/dirY/dirX"), but running library(here) doesn't do anything anymore, so we're forced to quit the RSession. Restart it, setwd() to our respective GitHub repos, then proceed as we had.

We use here to access files in directories of our GitHub folders, relative to the top level of that GitHub folder. It should remain agnostic to the rest of our file structure and configuration.

At the very least, I wish library(here) worked to reset here::here() and begin searching for the top level "project directory" starting with the current working directory. As it is, there's no good way without quitting the R session which is a pain.

[krlmlr]

Can you use a project file (.Rproj) and open it? This will make the initial working directory start at ~/dirX or ~/dirY/dirX, respectively, and that will be your project root too.

In RStudio, choose File/New Project/Existing Directory, this will create an .Rproj file. Commit it to Git, and ask your colleagues to pull and then to open that project in their RStudio session.

[jennybc]

It seems like there should be a way to re-initialize here's state.

[krlmlr]

@jennybc: I'd say this is out of scope for here -- there's rprojroot that can do this and much more.

[kmishra9]

Either way, is there a reason why library(here) doesn't or can't refresh the initial starting state of here?

I hope there's also a good reason for here::here() not using the current working directory to start its search for what constitutes a project repo -- I'm having a tough time wrapping my mind around why here::here() can't use that, or like, what using that as the default would break

[krlmlr]

here is a simple wrapper around the much more powerful rprojroot package. I intend too keep the functionality very limited but still useful for many use cases.

To use here effectively with RStudio or RStudio Server, it helps a lot if you work in projects (.Rproj files) -- even if there's only a single project you work on with R. The project makes sure R starts in the right working directory, and then you don't need setwd() at all -- here knows where to start.

here is stubborn about its notion of the project root. This means that once it has picked up the project root, it stays unchanged -- once you have set it up in a way that it works in your session, no abuse of setwd() will disturb it. This allows converting a project gradually to here.

[kmishra9]

Understandable. Still think it'd be worth having library(here) run through the process of finding the project root again, but maybe that's just me.

[krlmlr]

here isn't notified about a second call to library(here), we'd need an exported function as Jenny suggests, but I'm not convinced we really need one.

Have you tried an RStudio project (.Rproj file) yet?

[kmishra9]

I have -- it works fine, just using projects isn't typically part of my workflow. I think I'll be sticking to my existing solution as its not too much of a pain to deal with, but I'll just +1 the exported function idea.

[jennybc]

This feels like usethis::proj_get() and usethis::proj_set(). We have a preferred workflow in mind, in which a user would never call these, i.e. their habits would guarantee that the project is set correctly.

And yet they are exported because you just can't account for every use case and sometimes people don't have all the control they would like over a project.

[krlmlr]

@kmishra9: here::i_am() offers a new way to declare the project root, each script and report declares its own path relative to the project root. Does this help with your scenario?

Read more at: https://here.r-lib.org/articles/here.html#declare-the-location-of-the-current-script-1

[kmishra9]

The solution sounds pretty good! I've also done a 180 on using R Projects and can't imagine living without them, so there's that as well 🤷

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue and link to this old issue if necessary.