[WIP] Add --no-user-env flag to the installer

[jtpio]

Fixes #524.

This change adds a --no-user-env flag to the installer, to be able to skip the creation of the user environment.

As mentioned in #524, this can be quite useful to shave off a lot of time in deployments where the default user environment is not needed (using DockerSpawner).

• Add / update documentation
• Add tests

[jtpio]

Opening the PR early to know what other folks think.

Being explicit with --no-user-env instead of --hub-only probably makes more sense. We might also want to consider printing a message when both --no-user-env and --user-requirements-txt-url are specified.

--skip-user-env could also be an alternative to --no-user-env.

[betatim]

The code looks sensible to me.

I think the biggest question here is: where are we on the road to feature creep/scope expansion? TLJH targets a very specific niche (low tech skilled admins, low requirements in terms of scalability, small number of users). The resulting simplicity is attractive to everyone but we then invariably need new features/more configuration which makes things more complex for the original audience.

I don't know where we this feature would fall (I'd use it but I am probably also not the target audience ...). An alternative could be to use the plugin/extension mechanism of TLJH to allow people to do things like this. Ideas and thoughts welcome.

[jtpio]

Plugins could be a great way to "hide" that, and all potential complexity. But at the moment they run at the very end of the install process. So that should be doable, but also raises the question of whether this should be exposed as a hook or something else.

At the same time, it looks like TLJH could be slightly extended to handle use cases between TLJH and Z2JH, still targeting the same requirements (simplicity, good defaults, single machine, low number of users).

[yuvipanda]

Thank you for working on this, @jtpio.

I want to balance the possibilities offered by TLJH vs the maintenance cost of complexity. We have a well tested set of hub infrastructure here - Proxy setup, TLS, supervision, etc. This is extremely useful in a number of cases, where we ignore the env created for the user. The installer does a lot of unnecessary work, which is very annoying.

The options here are a specific flag like what this PR does, or moving the entire user env creation step to a plug-in, which can then be replaced. This would require adding newer hooks, maybe even a LoggingConfigurable. This would help us define a nice interface for what a user env provider should do, make it easier to add things like docker based installs. Just skipping env creation makes this a free-for-all, which isn't nice. It will also break TLJH upgrades, since we can't assume anything is idempotent.

So I'd suggest we:

1. Move the current conda based env creation to a plug-in, adding hooks as necessary.
2. Make the current plugin the default, installed via its own package.
3. Write at least one other env creation plugin (docker?) to make sure our interface is general enough
4. Document all this.

What do you think? I can help with code review and discussions, but don't have time to actually write code...

[jtpio]

Thanks @yuvipanda and @betatim for the input!

@yuvipanda really nice write-up 👍 I'll open a new issue since it's a bit more general that what this PR does, and also to make it more visible to other folks.

[consideRatio]

Thank you @jtpio for very clearly communicated issues/PRs! ❤️ 🎉

---

I'm currently thinking we should hold off doing this by adding a flag, and do it after modularizing it so it just becomes a plugin that can be disabled.

@jtpio can I close this PR and reference #534 as the action point going onwards, where this PR work is also referenced so it isn't lost?

[jtpio]

Thanks @consideRatio for the triage effort!

No problem for closing this PR.

The main issue was related to the install time and there is already a good mitigation with the update to JupyterLab 3 and mamba.

[consideRatio]

Thanks @jtpio for such a considerate response, and thanks @manics for #697!