Handling a sess installed by conda / pixi #1854

roaldarbol · 2026-10-08T22:38:13Z

roaldarbol
Oct 8, 2026

Heyo!
I maintain rpix, an R interface to the pixi package manager, which installs R and R packages from conda-forge into per-project environments. I'd like VS Code users of rpix to get a working session watcher out of the box. To that end I've submitted r-sess (3.0.1) and r-jgd to conda-forge (conda-forge/staged-recipes#35105, conda-forge/staged-recipes#35104).

With 3.0.1 this works: the extension accepts an installed sess whose version is at least the bundled one. The source-revision check on main (#1819, #1840) changes that, and I'd like to raise it before it ships.

What will happen

A conda-built sess never matches. conda-forge builds from the release tarball (archive/refs/tags/vX.Y.Z.tar.gz), which has no Git checkout. So bootstrap.R can't run, and the installed DESCRIPTION keeps @VSCODE_R_SESS_SOURCE_REVISION@. sess_installed_source_revision() returns NULL, and the user is asked to install the bundled copy.
The bundled copy gets installed into a library the package manager owns. install_sess.R installs to .libPaths()[1] when it's writable. In a conda/pixi environment that's one of two places:
- With conda-ecosystem-user-package-isolation, which rpix adds by default, R_LIBS_USER points to a folder that doesn't exist. .libPaths()[1] is then $CONDA_PREFIX/lib/R/library. R CMD INSTALL overwrites the files of the conda-managed r-sess package, and conda/pixi no longer know what's on disk.
- Without it, conda-forge's R puts the user's personal library first (conda-forge/r-base-feedstock#37). The bundled sess then goes into a library shared by every environment and R version on the machine.
Even a matching stamp would not be enough on its own. The extension updates automatically, and the conda-forge package follows a few hours or days later. During that gap every conda user would see a mismatch, with the same result as in point 2.

Possible directions

These aren't mutually exclusive, and you'll know better which fit the design:

Accept a compatible sess from a package manager. sess_source.R describes the source revision as "deployment identity only", while runtime compatibility is checked by protocol_version during attach. One option is to skip the install prompt, or make it optional, when the installed sess has the same protocol_version but a missing or different stamp. A setting such as r.sessionWatcher.requireBundledSess, defaulting to the current behaviour, would also work.
Publish a stamped source tarball as a release asset, built from dist/resources/sess/. Downstream packagers could then build the exact same files with the same identity, without needing Git. It doesn't fix the timing gap in point 3, but it would make the conda package match whenever versions line up.
Don't install into a package-manager-owned library. When R runs from a conda environment (for example, file.exists(file.path(Sys.getenv("CONDA_PREFIX"), "conda-meta"))), the bundled copy could go into a private, extension-managed library instead of .libPaths()[1]. The Interactive runtime already does this via VSCODE_R_SESS_LIBRARY.

I'm happy to test any of these with pixi/conda environments, or to help with a PR if one direction looks right to you.

Environment

vscode-R: main at 2a6ab2a (behaviour described above); 3.0.1 is fine
R from conda-forge, installed with pixi
conda-forge r-sess 3.0.1 (pending in staged-recipes)

I drafted this with help from an AI assistant (Claude Code), which read the vscode-R sources to check the behaviour described. I reviewed it before posting.

eitsupi · 2026-10-08T23:17:41Z

eitsupi
Oct 8, 2026
Collaborator

Thanks for the proposal and your work on conda-forge!

I would prefer not to relax the source revision check.
It ensures that the installed sess matches the exact source bundled with vscode-R, which matters especially when switching between stable and pre-release versions. protocol_version alone does not guarantee this.
Missing source metadata should ideally be addressed in the conda-forge build recipe.

Also, sess installation is optional when starting an R terminal.
Users are prompted and can decline without preventing R from starting.
Manual session attachment is currently an exception that could be improved.

Longer term, I'd like to explore eliminating sess's R package dependencies entirely, potentially by moving backend functionality to an external executable such as arf.
Given this direction, I'd rather avoid investing in pixi-specific installation logic.

However, I agree that installing sess into user-managed R libraries is undesirable.
A more general solution would be to use an isolated, extension-managed library, as discussed in #1841.

Contributions toward that approach would be very welcome!

4 replies

roaldarbol Oct 9, 2026
Author

Thanks @eitsupi, that makes sense. Agreed on keeping the source revision check.

conda-forge side: I've updated the recipe (conda-forge/staged-recipes#35105) to stamp Config/vscode-R/source-revision at build time. It recomputes the Git tree hash of sess/ from the release tarball, then sets Config/build/bootstrap: FALSE as prepare-sess.js does. Testing against main (2a6ab2a) gives git-tree:01f79fd…, the same as git rev-parse 2a6ab2a:sess, and sess_source_revision() reads it back from the installed package. 3.0.1 has no field, so stamping only starts with the next release.

#1841: I'd be happy to work on this. Roughly what I have in mind, so you can say whether it fits:

When a terminal starts, keep the fast path: if the installed sess matches the bundled revision, use it.
Otherwise, prepare the private runtime that R Interactive already uses (installSessRuntime) and pass its library to the terminal, e.g. as VSCODE_R_SESS_LIBRARY. This replaces the install prompt.
R/profile.R loads sess from that library with loadNamespace(lib.loc = ...), the way interactive-worker.R does, without changing .libPaths(). The loading could move into a small shared helper.
Manual attach uses the same private library instead of installing into .libPaths()[1].

A few questions before I start:

Should terminals and R Interactive share one runtime, or keep separate ones? Today the Interactive install also checks the Interactive exports.
For manual attach, the R being attached may not be the one in r.rpath.*, and the runtime is per R version. Would you prefer to prepare it from the attach script itself (per R version, under extension storage), or fail with a clear message on mismatch?
If a user has their own non-matching sess, should we use the private copy silently, or show a one-time notice?
Is pruning old runtimes (one per extension build × R version) in scope here, or a follow-up?

If this direction works for you, I'll open a draft PR.

eitsupi Oct 10, 2026
Collaborator

Thanks for updating the conda-forge recipe! I'm glad we can preserve the source revision check.

I initially had no plans to implement this myself and welcomed contributions.
However, while investigating the issue, I realized that manually attaching to an existing R session could install sess without user consent.

I first considered adding a confirmation prompt to that path, but as I explored the solution, it seemed better to address isolated library installation at the same time.
So I ended up opening #1856.
Sorry for jumping into the implementation just after you offered to contribute.

The PR largely follows your proposed direction, with one key difference: sess preparation happens inside the actual R process, since the R selected by arf or radian may differ from the one detected beforehand.
For now, R Interactive and regular terminals will continue using separate runtimes, leaving the existing R Interactive implementation unchanged.
Pruning old runtimes is also out of scope.

I'd really appreciate it if you could review #1856, particularly testing it in a pixi environment and pointing out any design or implementation issues I may have missed.

roaldarbol Oct 10, 2026
Author

All good! I really don't mind - as long as it improves vscode-R and in the process deals with my issue, I'm perfectly happy ;)

Full disclosure, the review below was primarily the work of Claude - I have tried to understand as much as possible and have made some edits where I felt I could make it clearer.

I tested #1856 on macOS x86_64 with conda-forge R 4.5 from pixi, up to b30991f. Quick takeaways:

It solves my issue. In none of the scenarios was an environment's R library or .libPaths() modified.
A conda-forge r-sess stamped at build time (conda-forge/staged-recipes#35105) is used directly, with no prompt. Once there's a release with the stamp, pixi users can simply add r-sess.
Decline, approve and reuse all behave as described, and a non-matching conda r-sess is left untouched.
The only gap is the documented one: an environment without sess's Imports fails on reuse with there is no package called 'ps'.

Thanks for the reasoning on eitsupi#2. Agreed, dependency repair is better left for a separate discussion. I'll leave two small suggestions on the PR, including the clearer error message you mentioned.

eitsupi Oct 10, 2026
Collaborator

Thank you for testing!

I agree that the R package dependency issue you pointed out is quite complex.
Ideally, sess should have no hard dependencies at all, like jgd...

Navigation Menu

Repository navigation

Handling a sess installed by conda / pixi #1854

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 4 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Handling a sess installed by conda / pixi #1854

Uh oh!

roaldarbol Oct 8, 2026

What will happen

Possible directions

Environment

Replies: 1 comment · 4 replies

Uh oh!

eitsupi Oct 8, 2026 Collaborator

Uh oh!

roaldarbol Oct 9, 2026 Author

Uh oh!

eitsupi Oct 10, 2026 Collaborator

Uh oh!

roaldarbol Oct 10, 2026 Author

Uh oh!

eitsupi Oct 10, 2026 Collaborator

roaldarbol
Oct 8, 2026

Replies: 1 comment 4 replies

eitsupi
Oct 8, 2026
Collaborator

roaldarbol Oct 9, 2026
Author

eitsupi Oct 10, 2026
Collaborator

roaldarbol Oct 10, 2026
Author

eitsupi Oct 10, 2026
Collaborator