This is a bit outside tljh’s target use, since it expects a single admin-controlled environment for all users, and if you want user-controlled packages, that usually means separate environments for each user. Is that what you have in mind? Managing environments for each user that is:
- persistent
- upgradeable by the user
- manageable by the admin (e.g. system upgrades)
is quite a challenge.
The most common solution to this is something like containers (DockerSpawner), where the admin controls the initial environment (the image), but users may install additional packages (permissions within the image). This satisfies 2-3 above, but user package installations are not persisted across sessions. This adds tedium for users (reinstall packages on server start) in exchange for a much more manageable situation for the admin (knows state of all packages at each server start time, and users can’t have a long history of modifications to keep track of for debugging).
If you’re talking about ‘rescue’ of the shared /opt/tljh/user environment, having a ‘spec’ rather than an environment might be the easiest solution. Then you can discard and recreate the user environment with conda env create.
If you do choose to have an additional ‘live’ env so you don’t have to change much, then what I’d do is environment activation in a startup script, as described here. Then you can create as many envs as you want, and activate the right one during startup.