I have been trying to set a conda environment for all users since I don’t want to use base environment.
from the admin terminal in TLJH I created a env,
conda create --name myenv
source activate myenv
The environment gets activates only in the tljh admin terminal till I am in terminal. However I want to set this env as a default env for all the users (not admins) so that when they open TLJH, they have this “myenv” as their default env for notebook, terminal and everything.
I tried export PATH=/home/jupyter-admin/.conda/envs/myenv/bin from linux terminal as well as tljh admin terminal, but as soon as I exit that, it reverts back to the default /opt/tljh/user/bin
I tried setting default environment in tljh-config file using linux terminal as well tljh terminal but didn’t work by following: tljh-config set user_environment myenv
I am new to TLJH and don’t know much about handling its configurations.
Can you clarify why you want to create an environment for all users that’s not the existing environment for all users? Note that the base ‘user’ environment is just for users, and you have control of it. It’s not used for anything else, so I’m not sure what an additional env would solve, if it’s going to be used in the same way. You can add/edit packages as you like in the user env with pip, conda, etc.
I am using TLJH for a small team (3 to 5 people), where an admin will make some scripts and share it with the users.
Admin’s side:
The scripts that will be developed by the admin, will require various functions and packages. Since the scripts might require add or edit of the packages with time depending on the development timeline, therefore there is required an environment as a backup so that if anything breaks, admin can replace the broken environment with a copy of the backup environment.
Users’ side:
The users will work on the scripts having the environment provided by the admin. However the users might bring in new things in the scripts which may require add or edit of the packages by them in their environment. If any user breaks/screws their environment, the admin should be able to replace it with a copy of the backup environment for the rescue.
Summary:
If anything breaks during script development, admin has a backup environment which admin can bring in for rescue. If anything breaks when user is working on the scripts or adding/editing packages, the admin can replace their broken environment with a copy of the backup environment that is working fine for the admin provided scripts.
Proposed solution:
Admin has the flexibility of changing the environment anytime whenever needed with a copy of the backup environment.
I know admin has control over the user’s env by adding/editing packages in user’s env but that will require more troubleshooting or analysis that which package and which version caused the breakage. Whereas, if there is a backup environment that can simply be brought in and everything is working back again.
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.