workflow for multi-tennant systems?

[MilesMcBain]

If I understand rig correctly, it works on the premise the entire system runs on the same R version correct?

So when I change the default, that will change it for all users?

At the moment I am working with a couple with others on an on-prem server. We want to use different R versions for different projects, and while rig is handy for installing them, we found the only way to set our own R version defaults was to create our own personal symlinks to the desired version in /opt/R and add them to our PATH. Kind of what rig is meant to do anyway?

Could there a mode where rig could set the default version on a per-user basis?

[MilesMcBain]

This is probably a rare edge case, because in such systems it might not be common for users to have sudo, which is a prerequisite.

[gaborcsardi]

Yes, this is something that we want to support. There are a few reasonable choices for how this could be implemented:

1. Some subcommands get a --user and --system argument, e.g. rig default --user, etc. This is not so great for (non-admin) users, because they can only use a very restricted set of operations and rig will seem much more complex for them than it needs to be.
2. We create new subcommands for user-level operations. Some operations are already user level, e.g. rig library, so this solution does not look great.
3. Create two "modes", one for single-user systems, and one for multi-tenant ones, defaulting to single-user. Admins could configure multi-tenant mode via a config file, maybe. Maybe, in multi-tenant mode rig could show a simplified interface for non-root users. (?)
4. Have two commands instead of one. We keep rig as is, and also have a rig-user (?) command specifically for non-admin users.
5. Some combination of these. E.g. have --user options as a first step, and maybe later a rig-user command that is restricted to the user specific operations.

Right now I am leaning towards an opt-in multi-tenant mode.