Repository navigation
sess should be a pure R package #1829
Description
Activity
@eitsupi Thanks for bringing up this issue. I agree that the extension should not require a compiler on installation. In fact, a commit attempted to partially tackle this issue by using the pre-built binary from https://reditorsupport.r-universe.dev/sess.
For simplicity, I think it makes good sense to let Interactive be initially limited to arf and remove the C code from sess. I'll take a closer look at this very soon.
After looking more closely at the implementation and arf's IPC, our preferred direction is approach 2: remove the C bridge, make the bundled sess a pure R package, and initially limit R Interactive to managed, headless arf sessions. Since Interactive is experimental, accepting a clearly documented reduction in capabilities seems preferable to adding a compiler requirement to ordinary vscode-R setup.
The three approaches have different tradeoffs:
Approach Maintainability Robustness User experience Separate native bridge package Preserves the existing implementation, but adds another package, compatibility boundary, and native build/release matrix. Isolates ordinary sess from native installation failures and can preserve today's Interactive functionality. Ordinary setup becomes compiler-free, while full Interactive still needs a compatible binary or build tools. Remove the bridge and use arf initially Removes custom console callbacks and delegates frontend behavior to arf. Its experimental IPC needs version checks and integration tests. Keeps ordinary integration independent of Interactive prerequisites; supported Interactive capabilities must be explicit. Predictable sess installation, with arf required only for Interactive and some features initially unavailable. Bundled source → R-universe binary → basic sess fallback Maintains several installation paths and native/basic capability variants. Depends on repository availability and platform/R-version coverage, with more compatibility and recovery cases. Convenient when successful, but potentially slow and confusing when installation falls back to a different feature set. Splitting the native bridge is a reasonable alternative if preserving all current Interactive behavior is a release requirement. The native package would need to be genuinely optional, so ordinary sess could load and operate without it. However, this commits us to maintaining native integration indefinitely. The current native console bridge is Unix-only, so requiring Windows users to build it for ordinary session integration is especially undesirable.
R-universe now publishes sess builds containing the Interactive bridge, making the binary fallback more useful than the older PR description suggests. It still cannot guarantee coverage for every platform, architecture, R version, or offline environment. Maintaining native and stripped packages under the same sess name also complicates compatibility checks. I would retain binary repositories as an installation convenience rather than make this fallback hierarchy the permanent design.
There is an important qualification for approach 2: the existing arf adapter also uses sess's C bridge, so removing
interactive.calone would break it. The backend boundary introduced in #1805 gives us a suitable place to change that integration while retaining the agent's session persistence, execution queues, ownership, reconnection, history, and exports. Pure R inspection, table/HTML output, and plot helpers can continue using sess's R-level IPC.I checked the arf 0.5.3 IPC implementation and ran a local smoke test without loading sess. Visible evaluation can stream output through a managed arf process's stdout/stderr and return captured output/results through IPC. However:
- Current arf IPC has no output subscription, so adopted sessions cannot provide equivalent live streaming or reliably capture arbitrary terminal-origin output.
user_inputsubmits code; it is not a reply channel for nestedreadline()orbrowser()prompts. In the headless test,readline()returned an empty string despiteinteractive()being true. Notebook input/debugger support therefore needs additional arf support.- Output ordering needs care when console and rich events use separate transports. Arf also buffers captured output even when streaming it, so large-output handling needs validation.
The intended direction is therefore to make bundled sess unconditionally pure R, adapt arf behind
SessionBackend, and initially support managed arf sessions with input/debugger capabilities disabled. Adopted-session support can be deferred or explicitly reduced. Ordinary R terminals should remain fully available, and JGD and richer graphics should remain optional.Finally, pure R sess does not make every dependency pure R: processx, later, and jsonlite contain native code. The goal here is to remove the additional mandatory source-compilation step introduced by sess itself, while using installed dependencies or compatible binaries where available.
I think this should block 3.1.0.
sess now contains native C code for the experimental Interactive runtime (#1805).
As a result, installing the bundled package from source requires a compiler.
This is particularly problematic on Windows, where users may need to install the very large Rtools toolchain just to use ordinary vscode-R session integration, even though the native Interactive console bridge is not supported on Windows.
I see two possible directions:
@renkun-ken Since R Interactive is still experimental, would you be open to prioritizing compiler-free installation and simplicity for 3.1.0, even if that means some Interactive features are initially available only with arf?
I don't think requiring Rtools as part of the normal vscode-R setup is acceptable.