Proposal: make Jupyterlab a standard package

[Eric Gourgoulhon]

Hi,

The optional package Jupyterlab has been upgraded to version 3.3.1 in

https://trac.sagemath.org/ticket/32069

(merged in Sage 9.6.beta5)

Jupyterlab offers more functionalities than the classic Jupyter Notebook and is aimed to replace it, see e.g.

https://jupyterlab.readthedocs.io/en/stable/getting_started/overview.html

Maybe it is time to make it a standard package in Sage.

To be clear, this is not to switch (yet) the default notebook interface from the  classic Jupyter Notebook to Jupyterlab, but simply to make the following commands work out of the box:

(1) sage -n   

(2) sage -n jupyterlab

with (1) launching the classic Jupyter Notebook (current behavior).

At the moment, (2) fails by complaining that Jupyterlab is not installed.

In a second stage, we could get rid of the Jupyter Notebook as a standard package, but still keeping the same user interface as (1) and (2)  thanks to the extension nbclassic of Jupyterlab. This extension has been added to #32069. Then (1) will run Jupyterlab with the nbclassic interface, which is identical to the classic Jupyter Notebook one.

In a third stage, we could make Jupyterlab the default by having (1) running it and having the old interface still accessible via

(3) sage -n nbclassic

Please vote.

Eric.

[Michael Orlitzky]

On Tue, 2022-03-22 at 03:44 -0700, Eric Gourgoulhon wrote:
>
> Maybe it is time to make it a standard package in Sage.
>

If so, please make it optional via a --disable-jupyterlab flag. (We
already have one for the standard notebook, --disable-notebook.)

Hijack, sorry: with these flags starting to accumulate, now would be a
good time to go back and make sense of our standard vs optional
designation. In most packages, anything that has a --disable flag is
de-facto optional, but the default (enabled or disabled) can be set
per-package. In sage, we use "optional" to mean "optional and disabled
by default." Historically "standard" has meant "not optional and
therefore always enabled," but more and more these days it means
"optional but enabled by default."

I think anything that can be disabled (such as jupyterlab) should be
"optional," but that we should be able to mark optional packages as
enabled by default. So the "optional" distinction would just mean "give
it a ./configure flag." This would avoid the semantic confusion of
"standard" packages that can be disabled via hand-written --disable
flags.

[Thierry]

Hi,

On Tue, Mar 22, 2022 at 07:58:07AM -0400, Michael Orlitzky wrote:
> On Tue, 2022-03-22 at 03:44 -0700, Eric Gourgoulhon wrote:
> >
> > Maybe it is time to make it a standard package in Sage.
> >
>
> If so, please make it optional via a --disable-jupyterlab flag. (We
> already have one for the standard notebook, --disable-notebook.)
>
> Hijack, sorry: with these flags starting to accumulate, now would be a
> good time to go back and make sense of our standard vs optional
> designation. In most packages, anything that has a --disable flag is
> de-facto optional, but the default (enabled or disabled) can be set
> per-package. In sage, we use "optional" to mean "optional and disabled
> by default." Historically "standard" has meant "not optional and
> therefore always enabled," but more and more these days it means
> "optional but enabled by default."

"Standard" also means "be shipped within the source tarball" that is
self-contained and does not require network connexion to be installed.

Ciao,
Thierry

> I think anything that can be disabled (such as jupyterlab) should be
> "optional," but that we should be able to mark optional packages as
> enabled by default. So the "optional" distinction would just mean "give
> it a ./configure flag." This would avoid the semantic confusion of
> "standard" packages that can be disabled via hand-written --disable
> flags.
>
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/1f0514f25545ddd9bdd1d875746ebf7bbdb2af07.camel%40orlitzky.com.

[Michael Orlitzky]

On Tue, 2022-03-22 at 13:47 +0000, Thierry wrote:
>
> "Standard" also means "be shipped within the source tarball" that is
> self-contained and does not require network connexion to be installed.
>

True, but it would be just as easy to ship the tarballs for packages
that are optional and enabled by default as it is to ship them for
packages that are standard.

[Samuel Lelievre]

+1 for enabling JuptyerLab by default.

There is already a ticket to make it a standard spkg:

https://trac.sagemath.org/ticket/24904

[Thierry]

Hi,

I just wanted to point that we still need a "standard vs optional"
distinction for this purpose.

Regarding make options, maybe it could be nice to ship all possible make
options (--enable-*, --disable-*) for every package, so that we can
override defaults easily ?

Ciao,
Thierry

>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/2a6bcb9cceae2a8bbc0724dfdab903e49213bada.camel%40orlitzky.com.

[Matthias Koeppe]

On Tuesday, March 22, 2022 at 3:44:37 AM UTC-7 Eric Gourgoulhon wrote:

Maybe it is time to make it a standard package in Sage.

+1, but not in Sage 9.6, which I'm hoping we can release ASAP

[kcrisman]

Sorry for a tangential question - the overview page seems to imply that *everything* from a (current) Jupyter notebook will work in a Jupyterlab instance (and, by extension, presumably can easily be imported).  Would that include the widgets we use for @interact?

(Tail wagging the dog here is that upgrading sagenb -> jupyter was already nontrivial for many "customers", though thanks to a huge amount of work by people-not-me a good export solution was found.)

PS: Would I be right in saying Jupyterlab is RStudio for Jupyter?

[Eric Gourgoulhon]

Le mercredi 23 mars 2022 à 12:01:15 UTC+1, kcrisman a écrit :

Sorry for a tangential question - the overview page seems to imply that *everything* from a (current) Jupyter notebook will work in a Jupyterlab instance (and, by extension, presumably can easily be imported).  Would that include the widgets we use for @interact?

As far as I can tell, all widgets work in Jupyterlab with Sage 9.6.beta5. In particular @interact works well. The widgets have been tested via this notebook:

https://nbviewer.org/github/egourgoulhon/SageMathTest/blob/master/Notebooks/test_display.ipynb

Eric.