Account for RStudio Cloud in create_*() functions and use_course()

[ijlyttle]

Follow-on from #685:

This is adjacent to #466, but I wonder what should be the default "conspicuous place" on RStudio Cloud. Currently, it seems to be home/rstudio-user, which I think is meant for dotfiles and the like. I wonder if the default conspicuous-place for RStudio Cloud should be /cloud/project.

To me, the "simplest" solution would be to add path_real("/cloud/project") to the top of the vector of paths, here:

https://github.com/r-lib/usethis/blob/274902535ea489dbaa4b57e56ad8c6d81e62a988/R/course.R#L290-L297

Questions:

• this would introduce a problem if someone happens to have that path, but not be on RStudio Cloud, but I don't know how to ask is_this_rstudio_cloud(). Thoughts?

• would path_real() be the right path-creator?

I will start a PR along these lines, subject to your guidance.

[jennybc]

Notes from Slack conversation with the Cloud Team:

• Current best way to detect that we're on Cloud: "keying off of the existence of /cloud/project".
• Project-switching (while in a Cloud project) goes against the RStudio Cloud paradigm. They generally think of 1-1 relationship between an RStudio Cloud project and an RStudio Project. And the current Cloud project is the one and only project.
• Most logical location for use_course() to write to is within the project, i.e. within /cloud/project. However, it is not logical to attempt to open any .Rproj file found within the payload.
• The use of create_*() functions is somewhat illogical within RStudio Cloud. It's conceivable we just shouldn't do it? If we do it anyway, it's not blindingly obvious whether the target dir should be below /home/rstudio-user or /cloud/project. Again, it would not make sense to attempt to activate the new project.

[jennybc]

cc @mine-cetinkaya-runde @cwickham @hadley l in case you have any relevant experience or thoughts.

Have you taught something where you used or wanted to use create_*() functions on Cloud? It seems like a clash of paradigms, i.e. if you're designing a learning experience you would either provide the scaffold via a Cloud Project or participants would use their own computer (or an RStudio server instance) + create_*().

[jennybc]

let me try that again: cc @mine-cetinkaya-rundel

[ijlyttle]

My use case, which may not be typical, revolves around a package-development workshop followed by an unconf.

All being well, everyone's computer is ready-to-go with R, git, the devtools packages, and Rtools (for those who need it). In case we have a few folks who arrive with some not-easily-fixed problems, we could start them up on an RStudio Cloud machine, with all the foundational packges installed. They would have to go through the use_git_config() and browse_github_pat() steps themselves, to personalize.

Otherwise, this would be a blank slate where they could create_from_github(), create_package(), etc. for whatever packages they might be working on, either in the workshop or during the unconf.

It's entirely possible that I am not thinking about RStudio Cloud in the right way; perhaps this can help illuminate the right way to go.

[cwickham]

I've struggled with this in the context of teaching package development as well. Like @ijlyttle, this is usually just to try to accommodate the few people that for whatever reason can't work locally on the day and the cloud is their only option.

I would generally have set up a project on the cloud beforehand with the materials (to avoid any need for use_course()), but they still might need create_package() for the full experience. In this case I've suggested that they create the new project/package below /cloud/project. This violates "don't put projects inside other projects" but in practice works OK on the cloud, and the student can still navigate between the projects using the Files pane.

[ijlyttle]

I am relieved to hear that @cwickham has been down this path, thanks!

Given that things may be under development and discussion, I am happy to hold off on making a PR.

In the meantime, should someone need to use Cloud, we can encourage them to do something like:

create_from_github("jennybc/bingo", destdir = "/cloud/project")

I think this presents a "good enough" solution for the time being.

Of course this is up to the usethis authors, but I propose to leave this issue open until a firmer conclusion is reached.

[jennybc]

Yeah. I'm going to submit to CRAN today/tonight and this is clearly not going in this version.

But I do want to improve things and it's helpful to document the current best way to use the create_*() functions on Cloud, if you have to.

[ijlyttle]

Yikes! On it!

[jennybc]

Oh this wasn't a call to action! I was just explaining that we will address this but not in v1.5.0. I suspect we'll need another patch release before useR! so it's good to just get this one out there. It's massive already.

[ijlyttle]

I was just about to make a PR with the current advice in function-documentation for the path and destdir arguments. If it can be useful for this round, great (but it sounds like your plate is full)! If it can be useful next round, great!

Just wanted to make sure you have it available if/when it can be useful to you.

[mine-cetinkaya-rundel]

Re: the question above "Have you taught something where you used or wanted to use create_*() functions on Cloud?"

My answer is no. The reason being that I use Cloud where I assume no R background, and in that case I'm trying to simulate, as best as possible, the experience of using RStudio IDE locally where you also have everything you need locally (which we do by placing the necessary files in the RStudio Cloud project initially, and students copy the project with the files all in the right places).

• In this setting I haven't taught package making, so I never tried to use create_package() in Cloud.
• I also haven't used create_project() since students do this by copying a project or starting an assignment.
• Ditto for create_from_github() since "New Project from GitHub" does this on Cloud.

I don't think I would ever have them create a new project from GitHub while in a project in Cloud. I'd have them go back to the "homepage" and use the UI to do it.

My students also do use use_git_config(), though we haven't done browse_github_pat() -- we cache the password, or they use their browser keychain to do so.

I can see the appeal of create_package() working within an existing RStudio Cloud project for the purpose of teaching package development.

I'm not sure I see the appeal of create_from_github() working within an existing RStudio Cloud project when there is the alternative of "New Project from GitHub" from the UI. Am I missing something?

[jennybc]

I'm not sure I see the appeal of create_from_github() working within an existing RStudio Cloud project when there is the alternative of "New Project from GitHub" from the UI. Am I missing something?

What I'm about to say is a general sales pitch for create_from_github(), not Cloud specific.

create_from_github() is smart about cloning vs fork-and-cloning (and will also accept user's directions re: this). And if we've forked, we go ahead and setup the origin and upstream remotes correctly.

[AmeliaMN]

Just wanted to chime in here and say I've now taught some package development stuff on the Cloud and ended up with many students with RStudio Cloud projects that were pretty borked... This is probably mostly my fault in a) not forcing them to work locally at this point in the semester b) not providing clear enough instructions about how to avoid weird paths in RStudio Cloud

I'm trying to remember all the problems I created, but here are a couple off the top of my head:

• if your RStudio Cloud project is already hooked up to git/GitHub (like many of my students' were, because they take notes in .Rmd and push to GH), then doing something like create_from_github() introduces confusion about remotes. The remote you're pushing to depends on the active project, and of course with the project-in-a-project it's sometimes hard to tell.
• if you don't specify a path for your project (and, since create_from_github() works without that argument) it gets generated in the /home directory, a place you don't usually see in RStudio cloud. I was able to walk students into it with the ... button in the top right of the Files pane, but of course you then can't use the checkbox-and-move way of moving files. I guess you could still use cp in the Terminal, but I ended up telling students to copy and paste from files that were in /home to new versions in /cloud because I didn't want to go down that rabbit hole.
• not exactly related, but when I'm debugging git and GitHub issues on the cloud, I will often try to get RStudio to realize there is a git repo associated with the project by doing stuff in the Terminal. On the desktop app, this is usually enough to get the git pane to appear in the GUI, but it doesn't work the same way in Cloud. After some googling today I was able to figure out that rstudioapi::openProject() will get the GUI to reload and include the pane, but it's odd to me that reloading the page in the browser won't do it, nor will switching to another project and then back. Is there a better way to get the GUI to recognize git repos? Is githug still a thing? Any thought of making it a dependency of usethis? Since usethis comes with pr_push I always expect to be able to git_commit() to commit without going all the way to the Terminal.

[jennybc]

Note to self: now have a proper way to detect if operating in an RStudio cloud context. It sets R_CONFIG_ACTIVE to "rstudio_cloud".

https://github.com/rstudio/lucid-images/pull/112