assert_here()

[jennybc]

It would be interesting to consider an assert_here() function.

Inspired by this Twitter conversation with Emile Latour (@emilelatour).

Problem: you use Projects and the here package and life is awesome. But your collaborator still clicks on an Rmd in the Finder and it just opens in RStudio, in whatever Project (or non-Project) they happen to have open. Now all the path-building code doesn't work as planned when they run chunks interactively (knitting the whole document still works fine for them).

If you want to make a .R or .Rmd file more resilient to this and you feel like the Project's name is pretty stable, you could put here::assert_here("PROJECT_NAME") at the top as a way of raising an alarm when the workflow violates expectations.

assert_here() would be something like assertthat::assert_that(identical(basename(here::here()), “PROJECT_NAME”)).

[nacnudus]

A collaborator just fell into this trap. See the RStudio behaviour when opening by file association:

When launched through a file association, RStudio automatically sets the working directory to the directory of the opened file. Note that RStudio can also open files via associations when it is already running—in this case RStudio simply opens the file and does not change the working directory.

In their case they wound up in their home directory, which seems a good candidate for a message: Did you mean to set the working directory to your home directory? Check here for common solutions [url]

[krlmlr]

We could also look for a specific file/directory in the project, and give a nicer error message. Need to mull over it.

[krlmlr]

I prefer solving this with documentation.

[krlmlr]

I added a section to the "Getting started" article, feedback welcome.

[nacnudus]

Thinking about this again, any solution appears to make library(here) redundant.

I'm not sure what to suggest. Perhaps if here("foo.csv") checks for the existence of foo.csv, and if it can't be found, prints a warning that includes the current working directory as a clue.

[krlmlr]

I'm not sure about the redundancy.

here("foo") works even if the file doesn't exists, it's easy for the user to check that the file doesn't exist (and any ingestion function will fail too).

I think this is about failing early, failing fast, failing clearly. Does the text at https://here.r-lib.org/articles/here.html#enforce-project-oriented-workflow-1 need more clarification?

[nacnudus]

Even if you always work inside a project, your collaborators may not be aware. here() falls back to the current working directory when no project can be found. This means that your code does not find the correct files even if you use here() everywhere.

I don't think this describes the situation in this thread, but I might not have fully understood it. I think the steps to reproduce this behaviour are as follows.

.
├── proj1
│   ├── data1.csv
│   ├── .here
│   └── script1.R
└── proj2
    ├── data2.csv
    ├── .here
    └── script2.R

# proj1/script1.R
getwd()
library(here)
file.exists(here("data1.csv"))

# proj1/script2.R
getwd()
library(here)
file.exists(here("data2.csv"))

1. Close all instances of RStudio.
2. Open proj1/script1.R in a new instance of RStudio by file association. RStudio automatically sets the working directory to proj1.
3. Run the script proj1/script1.R. library(here) doesn't change the working directory, because it's already correct.
4. Open proj2/script2.R by file association. It opens in the existing RStudio session, and RStudio doesn't change the working directory.
5. Run the script proj2/script2.R. library(here) does nothing, because the package has already been loaded. file.exists("data2.csv") returns FALSE because the working directory is proj1, not proj2.

The advice in the documentation is to use a project-oriented workflow, along with some defensive code. I think this advice makes the use of the {here} package redundant, because:

1. If you use projects, RStudio sets the working directory correctly without the need for library(here).
2. If you don't use projects, library(here) isn't reliable (as demonstrated above), so defensive code has to be written anyway.

I do think a project-oriented workflow should be encouraged when all collaborators use RStudio, and {here} should be encouraged when no collaborators use RStudio. But I would find it difficult to persuade people to use {here} if they still have to write defensive code, hence my suggestion to make here() itself more defensive -- although even that doesn't seem like a great solution.

[krlmlr]

Thanks. Your described workflow is consistent with my understanding of the problem. Both the starting directory and here's notion of the project root could be anything. Scripts that rely on {here} will fail in varying degrees -- from failure to open a file for reading to silent failure after writing a file to an unexpected location. Ideally all scripts using {here} would fail loudly.

1. The working directory may not be the root of the project, see https://here.r-lib.org/articles/rmarkdown.html . This was the motivation for implementing {rprojroot} and the {here} wrapper. I agree that if you can guarantee that the w.d. is the project root you don't need {here} -- in practice this is "sometimes" true but not always.
2. Agree that defensive code makes sense. I decided to solve with documentation for now, I could be persuaded to implement a function that makes these checks simpler.

This coincides with the problem that there's no well-defined way for an R script to know its own path. The kimisc and rprojroot packages have functions that now moved to {whereami} (thanks @yonicd), and {this.path} seems to reimplement this (on CRAN since yesterday).

The suggested assert_here() (or maybe declare_here() or i_am_here() or ...) could fill that gap, and {whereami} and the other functions could use this info to find the active script more reliably if the info has been set?

[nacnudus]

Thanks for reconsidering this. Maybe another option would be for the contents of .onLoad() to be exported, so that every script can reassert its location, regardless of the prior state of the R session. Bad idea, sorry, because there's no way to know the path of the script being run.