Im in the process of trying to make vscode available for our users via RStudio Workbench. All of the basic configuration is working as expected but I would like to make the extensions available on OpenVSX discoverable / installable via the extensions marketplace tool.
Based on the OpenVSX docs it seems like this should be possible but it is not clear where the necessary settings would go (i.e. I'm not sure where to locate product.json or the extensionsGallery mentioned in the docs).
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.
If you have a query related to it or one of the replies, start a new topic and refer back with a link.
Configuration of VS Code sessions is handled via the config file /etc/rstudio/vscode.conf. The following table lists the various configuration options that are available to be specified in the vscode.conf configuration file:
Due to differences between code-server versions, Posit Workbench needs to know the versions of code-server that is in use. It can be automatically detected by Posit Workbench on start up by running the code-server command, or can be specified by using the version setting in /etc/rstudio/vscode.conf. Automatic version detection is done if the default value of auto is used.
If you are running VS Code in a remote cluster like Kubernetes, you will need to manually specify the version of code-server if it is not locally installed or is not running the same version as the remote cluster. Due to version differences, running against multiple different versions of code-server in different Launcher clusters simultaneously is not supported - the versions must match in all clusters.
When running VS Code sessions in containers, such as by using the Kubernetes Job Launcher plugin, you will need to ensure that the image(s) used to launch VS Code sessions contain, at minimum, the following:
In some cases, the path to code-server might be different depending on where the VS Code session is running. For example, the path to code-server might vary from container to container. By specifying a WORKBENCH_VSCODE_PATH environment variable in your container build, you can ensure that the desired code-server installation will be executed by Workbench. The WORKBENCH_VSCODE_PATH can also be set in the launcher-env file as described in the Launcher environment section. Workbench will resolve which code-server executable should by used with the following priority:
Please note that code-server must still be installed at the location configured in vscode.conf on the Workbench host. Additionally, the same version of code-server must be installed on the Workbench host and in the containers or on the session hosts.
RStudio Workbench allows you to launch VS Code sessions from the home page via the Job Launcher, if configured. Users can start VS Code sessions that allow them to work with VS Code while still working within the administrative framework provided by RStudio, such as authentication, PAM session management, etc.
VS Code sessions are intended to be used with the RStudio Workbench VS Code extension installed. The extension provides users with a button to open RStudio Workbench homepage in a new tab and enables users to easily and securely proxy Shiny, Dash, and Streamlit web servers. If the extension is not installed, VS Code sessions will launch but without the additional features; users working on these types of apps will not be able to access the servers they are running on.
In order to add VS Code integration to RStudio Workbench, you must first install the open-source code-server wrapper, available at -code-server. This wrapper allows access to VS Code via a web server in a browser, allowing Workbench to create VS Code sessions and proxy them through the browser.
To install, simply run the command rstudio-server install-vs-code . This will install the code-server binary, and automatically configure /etc/rstudio/vscode.conf. The default configuration will allow users to manage their own extensions; if use of a global extensions directory is desired, then it may be passed as an option to the install-vs-code command. Alternatively, vscode.conf can be manually updated to include --extensions-dir after it has been created. For example, to install everything at /opt/code-server with per-user extensions directories:
Any arguments after the installation directory will be added to the args entry in vscode.conf, which is supplied to the code-server binary when the session is started. Note that if a global extensions directory is provided this way, this command will also automatically install the RStudio Workbench VS Code extension as described in the Installing the RStudio Workbench Extension section.
The RStudio Workbench extension requires code-server 3.9.3. While later versions may work as expected, compatibility is only guaranteed with version 3.9.3. The install-vs-code-ext command can upgrade code-server automatically for you if you include the -d flag with the directory that code-server should be installed in. For example, your command may look like this:
If using a global extensions directory, the install-vs-code-ext script can be used to install the latest version of the extension. This script is run while upgrading RStudio Workbench, but may fail with a warning if the version requirement is not met.
When VS Code sessions are configured with a global extensions directory, users without write access to this directory will not be able to install extensions and the extensions marketplace will be disabled. Otherwise, users are able to manage their own extensions, and installs must be performed on a per user basis by the user. There are three ways in which extensions can be installed:
Configuration of VS Code sessions is handled via the config file /etc/rstudio/vscode.conf. Note that this file is not automatically created by RStudio and must be created before being configured, as VS Code sessions are disabled by default. The following table lists the various configuration options that are available to be specified in the vscode.conf configuration file:
Currently, RStudio Workbench supports code-server 3.9.3. Due to differences between code-server versions, RStudio Workbench needs to know the versions of code-server that is in use. It can be automatically detected by RStudio Workbench on start up by running the code-server command, or can be specified by using the version setting in /etc/rstudio/vscode.conf. Automatic version detection is done if the default value of auto is used.
If you installed VS Code via the sudo rstudio-server install-vs-code command, a simple template is created for you automatically which instructs VS Code to use the bash shell by default and to disable automatic extension updates. The generated file looks like the following:
Multiple VS Code windows with distinct processes and projects can be opened within the same VS Code session in separate browser windows. Closing a VS Code session window causes the processes associated with that window to exit, while other processes associated with the same session will remain running.
After a user closes all windows associated with a session, restarting the session from the RStudio Workbench homepage will open the last project that the user opened in this session. The order in which the windows are closed does not impact this. Reopening the VS Code Workspace or folder the user was previously working in will return the window to the state that it was left in.
If you experience issues related to running VS Code sessions, you can use the Launcher verification tool which will attempt to launch VS Code sessions and provide diagnostic output about what could be going wrong. For more information, see the Troubleshooting section for the Job Launcher integration documentation.
I recently completed a project to add RStudio addins to the Visual Studio CodeR extension. In this post I explain thetechnical sleight of hand that makes this work, and share some of my selecthighlights from the project.
Emacs and RStudio facilitate this in different ways, but ultimately they bothallow you execute code on data taken from the text editor and shove the resultof that into an R function called in your R session. 2
And I guess I was mulling over what unsatisfying options these were when Irealised that what the VSCode R extension really needed was something like theRStudio API - HOLD ON. Can I port the RStudio API? Can I make fnmate,datapasta and other popular addins work with VSCode with no changes to theircode?! I think I know how to do this!
I was pretty jazzed about the idea and it occurred to me that it was so goodthat I was probably not the first person to have it. A GitHub searchrevealed that my intuition was correct: In May of 2020, VSCode-R extensionmaintainer Andrew Craig had created an issue discussing the possibility.
I offered to contribute and was invited to start working on the idea.3 Once I had a proof of concept - 1 working API call - I decided to email the authors of rstudioapi to let them know what we were planning to do.
The RStudio response was all class. You can see for yourself in the issuethread. JJ Allaire wrote backwith encouraging words, a heads up on future API directions, and an offer totalk about the API. Kevin Ushey did likewise, filling out some more detail onfuture plans, and invited questions and feedback on the API. When I did have aquestion about the API, Kevin answered it quickly.
3a8082e126