--collaborative flag is not correctly interpreted when jupyter-collaboration package is installed

[echarles]

The --collaborative flag aims to indicate if JupyterLab should run or not with RTC.

When you use use flag without jupyter-collaboration package, the server stops with "To enable real-time collaboration, you must install the extension jupyter_collaboration You can install it using pip for example: python -m pip install jupyter_collaboration" which is the expected behavior.

When jupyter-collaboration is installed, the RTC mode is enabled even if you start without the --collaborative flag. RTC should be enabled only if you give --collaborative (see also #14715 (comment))

[minrk]

One way to address this would be for Jupyter-collaboration to remove its "enable-by-default" config from the installation process. That seems like the correct behavior if collab is meant to be opt-in at runtime rather than install time.

[hbcarlos]

Hi, @echarles.

Removing the collaborative flag was intentional, and the current behavior is correct. We keep the flag in JupyterLab to point users to the new extension.

[echarles]

Removing the collaborative flag was intentional, and the current behavior is correct. We keep the flag in JupyterLab to point users to the new extension.

True, I remember this has been discussed but not sure where, but it sounds like it is already bringing questions from 3 Jupyter user/developers (@fperez, @minrk and myself). I can imagine others have also questions on that. Is there a room to revisit that point?

[minrk]

Removing the collaborative flag was intentional, and the current behavior is correct

I think it's reasonable to follow the standard practice of extensions being on by default. But the --collaborative flag has not been removed, and still claims to be the way to enable collaboration in 4.0.2, implying that if it's not specified collaboration will be disabled:

# jupyter lab --help
--collaborative
    Whether to enable collaborative mode.
    Equivalent to: [--LabApp.collaborative=True]

The help string should probably mention more clearly that setting this flag is equivalent to enabling the jupyter-collaboration extension.

If you still want it to be easy to run in both ways without modifying packages (this makes sense to me in my use), it may be worth adding an opt-out --no-collaboration, since the default will be on from now own. Alternately, rely on the labextension disable for the opt-out to not treat it specially. But going that way suggests the --collaborative flag should show a deprecation message pointing to the standard extension mechanisms, rather than being a silent no-op.

[hbcarlos]

If you still want it to be easy to run in both ways without modifying packages (this makes sense to me in my use), it may be worth adding an opt-out --no-collaboration, since the default will be on from now own. Alternately, rely on the labextension disable for the opt-out to not treat it specially

I prefer to use the labextension disable, but I'm fine adding the --no-collaboration flag to jupyter-collaboration.

But going that way suggests the --collaborative flag should show a deprecation message pointing to the standard extension mechanisms, rather than being a silent no-op.

We should deprecate it, we forgot to do it when we moved RTC to the jupyter-collaboration extension. In addition, we should change the help message to the same message we currently use when the flag is enabled.

jupyterlab/jupyterlab/labapp.py

Line 859 in e04293e

To enable real-time collaboration, you must install the extension `jupyter_collaboration`.

[minrk]

Makes sense for it to behave like a standard extension.

FWIW, relying on filesystem state will make this harder for JupyterHub users, where deployments that have asked for RTC have generally only wanted it sometimes, so folks want the ability to have a single image that can be launched with and without RTC for different containers, which usually means differing only in CLI args or environment variables. opt-in --collaborative or opt-out --no-collaborative make that easy. I'm not sure how easy it is to specify extension disable/enable overrides for a single launch via CLI and/or env.

Additional configuration directories to add to JUPYTER_CONFIG_PATH or something may work, but will be a lot harder to document/communicate/implement.

[hbcarlos]

Disabling and enabling an extension is a bit more complicated, so I added a new flag in jupyter-collaboration to turn off real-time collaboration on documents.

It is implemented here:
jupyterlab/jupyter-collaboration#177

Once released, it will be possible to disable RTC with --YDocExtension.disable_rtc=True while keeping every other collaborative feature (list of collaborators, chat, etc.)

[minrk]

@hbcarlos that sounds great!

[echarles]

@hbcarlos I have just tried the --YDocExtension.disable_rtc=True and it does not work for me on my local dev env. Can you double confirm it is working for you?

[hbcarlos]

Hi @echarles,

I just tried with a dev env from the main branch and the latest release, jupyter-collaboration v1.1.0, and it seems to work fine.