My group uses RStudio Server Pro. We like the idea of the "shared projects" feature. However, after some testing our biggest complaint is that, while the script editor is collaborative, the environment is not--each user has their own R session and object environment.
Is there a plan to support two or more users sharing the same environment (or adding a setting to allow it)? This would be especially useful when pair programming or teaching on projects with large-ish datasets. Having the users' session state out-of-sync can cause confusion that could be avoided by having both users "sharing" an R session.
@Tanner, @thomas, wanted to make sure you see this thread.
Thanks for bringing this up and sharing the feedback! I for one have definitely experienced this frustration. It is good to hear that you are using the shared projects feature and it has value for you, though!
In particular, I think it'd be helpful if you could clarify:
are you mostly concerned with sharing packages? I.e. different users could have different packages, different versions of packages, etc. loaded?
are you mostly concerned with sharing objects? i.e. user A has defined some random object, and user B does not have that object defined in their session?
I think the two problems are related, but the former has been a bigger problem in my experience and (by my guess) would be a smaller tackle feature-wise.
I'll let Vergil elaborate if he wants, but in short, I think it's the object-sharing that's the biggest concern for us. We have developed a pretty good (internal) solution for ensuring users on the same project are using the same package versions.
Thanks! That's definitely helpful feedback. That gets much trickier since both users essentially need to either share the R execution environment or have some snazzy way to intermittently write things to disk / read from disk / etc.
It's definitely a useful case to have in mind, though! I'll be sure to share it with the IDE devs!
One random thought if you want to poke at an implementation - you could try creating an RStudio Add-in that maps a shortcut to save your environment to a specially named (i.e. not *.RData that gets loaded on startup) file, or syncs to that file, or something. The diffs are going to be the hairy part, though... what do you do if both of us have defined a different version of an object?
You can share R console among multiple users fairly easily by using one of the terminal multiplexers - GNU Screen or tmux (especially using wemux script). Launch screen or tmux/wemux in the Terminal tab then launch R there. You can submit R code to the terminal session by clicking Ctrl-Alt-Enter. Note that there is no way to see the R objects from that session in your Environment tab because you will still have your regular RStudio console session which is not shared. I wonder if the upcoming RStudio 1.2 Pro with its Job Launcher and API for plugins would help to make such shared sessions more seamless.
Great suggestion @alexv! I hadn't considered leveraging the terminal with one of the linux utilities like tmux or screen but I can see how that would work. This is a decent workaround for now but with the limitations you already mentioned. I agree--it would be cool if the new Job Launcher features can somehow be leveraged to have shared projects with a synchronized object environment and sharing one console.
@cole, your suggestion for saving separate .Rdata files is an interesting one though likely fraught with difficulties like you say. What I'm envisioning is something more like simul-viewing of the same R session while the users are simul-editing (and executing) code, just like what alexv suggested. Really, it's not practical to be editing/submitting code from two different parts of the script at once, and most likely one person will be "driving", but it would make passing control back and forth more real time and collaboration more engaging.
Ideally it would be like two programmers sitting at the same computer, each with a dedicated keyboard and mouse, but with a single session going. Two people, one session.
Yes, these are great thoughts! My brain went to Job Launcher as well, although I know little of how such a solution would be implemented. This is definitely something we will keep in mind! I passed along to some RStudio devs for noodling
