Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warn if working directory has changed since loading the package? #18

Closed
krlmlr opened this issue Mar 28, 2018 · 16 comments · Fixed by #62
Closed

Warn if working directory has changed since loading the package? #18

krlmlr opened this issue Mar 28, 2018 · 16 comments · Fixed by #62

Comments

@krlmlr
Copy link
Member

krlmlr commented Mar 28, 2018

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
Copy link
Member

jennybc commented Mar 29, 2018

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

@kmishra9
Copy link

kmishra9 commented Jul 2, 2018

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
Copy link
Member Author

krlmlr commented Jul 3, 2018

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
Copy link

kmishra9 commented Jul 5, 2018

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
Copy link
Member Author

krlmlr commented Jul 5, 2018

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
Copy link
Member

jennybc commented Jul 5, 2018

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

@krlmlr
Copy link
Member Author

krlmlr commented Jul 5, 2018

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

@kmishra9
Copy link

kmishra9 commented Jul 5, 2018

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
Copy link
Member Author

krlmlr commented Jul 5, 2018

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
Copy link

kmishra9 commented Jul 6, 2018

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
Copy link
Member Author

krlmlr commented Jul 7, 2018

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
Copy link

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
Copy link
Member

jennybc commented Jul 10, 2018

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
Copy link
Member Author

krlmlr commented Nov 15, 2020

@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

krlmlr added a commit that referenced this issue Nov 15, 2020
- `dr_here()` shows the initial and current working directory (#18).
@kmishra9
Copy link

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
Copy link

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.

@github-actions github-actions bot locked and limited conversation to collaborators Nov 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants