package management: pixi-style features / environments for optional dependencies?

[eitsupi]

I've been thinking about whether rproj.toml (or something else) should eventually support something like Pixi's features and environments.

There are already real use cases for dependencies that are needed for development/tooling, but should not necessarily be part of the main project environment.
For example, vscode-R may need packages such as languageserver, sess, and a graphics backend (httpgd, jgd).
This has already caused some friction with project package managers: see REditorSupport/vscode-R#1712 and A2-ai/rv#336.

A single dev dependency group may not be enough (related to REditorSupport/vscode-R#1728).
Different users may need different tooling (vscode, nvim, package development, documentation, etc.), and in some cases tooling dependencies should have their own dependency solution/library so that they cannot conflict with the project's dependencies.

Pixi handles this by separating reusable features from independently selectable environments.
I experimented with a similar groups + environments model in rsolve.

I noticed that rproj.toml already has optional-dependencies and include-groups, although they do not seem to have full semantics yet.
Would it make sense to define these around a more general feature/environment model before the manifest format stabilizes?

I'm not particularly attached to the syntax.
My main interest is being able to declare optional dependency sets in the manifest, compose them, and optionally resolve/install some of them into isolated libraries.

[gaborcsardi]

Related: the rproj.toml (+ R virtual envs + rproj.lock) specs are here: tidyverse/tidyups#34

[eitsupi]

Oh, I completely missed this. I had an LLM go through the proposal, and it still seems to me that borrowing more from Pixi's feature/environment model could solve several of the remaining questions quite cleanly.

In particular, dependency-groups already look like a good feature-like layer.
Perhaps the missing piece is an environment layer that can compose those groups and, when needed, resolve/install them separately from the main project environment.

[gaborcsardi]

Yes, the [environments] table seems like the main thing missing, and it does seem like a useful feature to add.

One difference for R is that when using R, you'd want to load all (some of?) these packages together. In Python you'd run a task in a certain environment, but in R it does not make sense to run 'usethis' in a different environment. At least not today. Even if we move towards running tools externally (rig run ... etc), that'll take some time, and sometimes it clearly does not work, e.g. pkgload::load_all() or the sess package for vscode-R.

FWIW, today even the installation of dependency groups does not work, so rig is catching up to the manifest spec as is.