Conda constructor wasn't providing enough use to justify its
restrictions:
1. It doesn't work with most of conda-forge due to
https://github.com/conda/constructor/issues/86#issuecomment-330863531.
Almost all the packages we want to ship are in conda-forge.
2. There is no way to pass environment variables to the post-install
script, which makes customization super hard.
3. Can't bundle pip packages, so we need internet access to install
packages anyway. This negates the 'offline installable' aspect of
conda constructor.
4. We need an installer script that users can curl into bash regardless.
Downloading & installing miniconda straight up seems simple enough
for now, and has a reasonable upgrade pathway. I think it'll work out ok!
- Load config only once at startup.
A lot of jupyterhub config (like user lists) take effect only at
startup, so live reload is not super useful. It will make the
software more complex, so let's not do it.
- Add pyyaml as a dependency of tljh.
- Remove escapism dependency since it is not actually used
Dynamic Users are neat and probably very useful for a tmpnb
style situation. However, for regular use they have the following
problems:
1. Can't set ProtectHome=no, so you can never apt install or
similar from inside admin accounts.
2. Dynamic uid / gid makes it hard to write sudo rules. We want
admin users to have sudo.
3. Persistent uids / gids are very useful for ad-hoc ACLs between
users. gid sharing isn't the most flexible sharing mechanism,
but it is well known & quite useful.
4. /etc/skel is pretty useful!