Remove jupyterhub-configurator in 1.0.0?

[consideRatio]

I'd like to propose we remove the opt-in setup of jupyterhub-configurator.

Overview

According to the docs, the configurator is disabled by default but is documented as something that can be experimetnally enabled.

If it is enabled, the Spawner get's an imported ConfiguratorSpawnerMixin that checks the relevant configuration just in time.

https://github.com/jupyterhub/the-littlest-jupyterhub/blob/c6c3c96f9aa21a8dcfee594db0c0f9f180193f40/tljh/user_creating_spawner.py#L41-L50

What can be configured by the jupyterhub configurator is hardcoded in a tljh package bundled config file.

https://github.com/jupyterhub/the-littlest-jupyterhub/blob/c6c3c96f9aa21a8dcfee594db0c0f9f180193f40/tljh/configurer.py#L278-L304

That declares that the default url can be configured:

https://github.com/jupyterhub/the-littlest-jupyterhub/blob/c6c3c96f9aa21a8dcfee594db0c0f9f180193f40/tljh/jupyterhub_configurator_config.py#L1

Proposal motivations

• We are heading for a 1.0.0 release and can do breaking changes as part of it
• Enabling jh-configurator via tljh is hardcoded to only allow config of the default interface (default_url ?)
• As a tljh jupyterhub admin one can use either the configurator to set default_url specifically, or use tljh-config or plain jupyterhub config .py files to do ~anything without the configurator. Should we really teach jh admins another way of doing things just to configure default-url in a simpler way?
• jupyterhub-configurator is not versioned, so we reference fixed git hashes currently
• tljh-config is already a shortcut to configure things by adding another configuration layer, adding another with the configurator can make it harder to understand how things work overall

[consideRatio]

I think I've come to see providing the jupyterhub-configurator in TLJH to configure default url specifically, as done now, seems like commiting to constructing and maintaing a car, teaching users how to drive it, and then suggesting they can use it to drive a few meters they could have walked with ease.

With that analogy in mind, I suggest we don't try to help users drive it further and to a few new destinations, but instead help users be even more confident walkers able to get everywhere.

@yuvipanda @GeorgianaElena @manics what do you think about this? Okay to remove the configurator?

[manics]

I've never used the configurator so I can't speak as to how useful it is.

Since the docs say

Because the configurator is under continue development and it might change over time, it is disabled by default in TLJH.

Removing it is fine if you think that's best.

[yuvipanda]

I would also like it to be removed, but for a different reason - I think my initial approach is a technological dead end. Architectural poor choices were made that came to light as we used it in production. See https://github.com/2i2c-org/features/issues/26 for more details.

I know that @GeorgianaElena spent a bunch of time integrating it into TLJH though, so would want to hear what she thinks too.