Make JupyterLab a standard package

[Samuel Lelièvre]

I opened a ticket to make JupyterLab a standard package:

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

Any opinions?

Samuel

[William Stein]

There is a murky discussion about making JupyterLab Python3-only maybe
as part of the 1.0 release, with the argument partly being as a carrot
to force people switch to python3:

https://github.com/jupyterlab/jupyterlab/issues/2096#

If we always build and always include python3 with every sage these
days, then this isn't a problem. Otherwise, it could be for a while.

-- William

>
> Samuel
>
> --
> 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 post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.



--
William (http://wstein.org)

[Dima Pasechnik]

On Monday, March 5, 2018 at 11:33:57 PM UTC, William wrote:

On Mon, Mar 5, 2018 at 3:29 PM, Samuel Lelièvre
<samuel....@gmail.com> wrote:
> I opened a ticket to make JupyterLab a standard package:
>
> https://trac.sagemath.org/ticket/24904
>
> Any opinions?

There is a murky discussion about making JupyterLab Python3-only maybe
as part of the 1.0 release, with the argument partly being as a carrot
to force people switch to python3:

https://github.com/jupyterlab/jupyterlab/issues/2096#

If we always build and always include python3 with every sage these
days, then this isn't a problem.  Otherwise, it could be for a while.

But Python3 is already a standard Sage package.

(sage-sh) $ python3

Python 3.6.1 (default, Feb 15 2018, 11:44:42) 

[GCC 7.2.0] on linux

Type "help", "copyright", "credits" or "license" for more information.

>>> 

 

[Jeroen Demeyer]

On 2018-03-06 00:29, Samuel Lelièvre wrote:
> I opened a ticket to make JupyterLab a standard package:
>
> https://trac.sagemath.org/ticket/24904
>
> Any opinions?

Shouldn't it be an optional package first?

[kcrisman]

Ordinarily, yes. 

[Samuel Lelievre]

Let me try to make the case for making JupyterLab a standard package.

(1)

According to a recent post on the Jupyter blog [0],

- JupyterLab is ready for daily use.

- JupyterLab will eventually replace the classic Jupyter Notebook.

- JupyterLab has been over three years in the making, with over 11,000 commits

  and 2,000 releases of npm and Python packages. Over 100 contributors from

  the broader community have helped build JupyterLab in addition to our core

  JupyterLab developers.

See [1] for other posts tagged "jupyterlab" on the Jupyter blog.

(2)

ThebeLab [2] is a reimplementation of Thebe as a thin layer on top of

JupyterLab (making it more sustainable), and is needed for ongoing work [3]

to restore the possibility of making the Sage documentation live, which

we had with the legacy SageNB notebook.

(3)

I want everybody to be able to try it out by typing

    sage -n jupyterlab

as was allowed by [4], without having to first run

    sage -pip install jupyterlab

(4)

To address William's question, the dependency on Python3 is not an obstacle,

since (as Dima mentioned) Python3 has been a standard package in Sage for a

while now. Actually, a sage-devel discussion started on 2017-11-29 and

reactivated on 2018-03-13 (today), reports amazing progress on making Sage

work with Python3.

(References)

[0] [2018-02-20] JupyterLab is ready for users

    https://blog.jupyter.org/jupyterlab-is-ready-for-users-5a6f039b8906

[1] posts tagged "jupyterlab" on the Jupyter blog

    https://blog.jupyter.org/tagged/jupyterlab

[2] Thebelab -- turning static HTML pages into live documents

    https://github.com/minrk/thebelab

[3] SageMath #24593: Upgrade from Thebe to ThebeLab for live documentation support

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

[4] SageMath #22215: Allow "sage -n jupyterlab"

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

[5] sage-devel discussion: A little Python 3 status update

    https://groups.google.com/d/topic/sage-devel/Ty-OQN7Avfc/discussion

Kind regards,

Samuel

[Jeroen Demeyer]

On 2018-03-13 18:33, Samuel Lelievre wrote:
> Let me try to make the case for making JupyterLab a standard package.

What is your case for *NOT* making it an optional package first?

[Samuel Lelièvre]

My view is that since it's pip-installable, it's as though it were

already an optional package.

What would it mean to make it an optional package? Maybe

I just don't understand that.

[Dima Pasechnik]

basically, make up a slot in build/pkgs/ with some mostly meta-data.

And we need a vote. Yes, I vote for make it optional, or better.

 

[John H Palmieri]

I feel like we need another class of package: "pending" (or perhaps some other name) = those which we propose to make standard soon. Most optional packages are not intended to be converted to standard, as far as I can tell, so "optional" isn't the appropriate tag in this case.

  John

[Vincent Delecroix]

I am not sure there is a need for such distinction. As a user, you
mostly don't care. As a developer, you know the "real" status.

Vincent

[Jeroen Demeyer]

On 2018-03-13 23:26, Samuel Lelièvre wrote:
> What would it mean to make it an optional package?

Exactly the same as making it a standard package, except that the type
is "optional" instead of "standard".

Once you do that, it will be trivial to make it a standard package by
just changing the type.

[Jeroen Demeyer]

On 2018-03-14 02:08, John H Palmieri wrote:
> I feel like we need another class of package: "pending" (or perhaps some
> other name) = those which we propose to make standard soon.

I agree with Vincent: the build system doesn't need to know that.

[Jeroen Demeyer]

On 2018-03-13 23:26, Samuel Lelièvre wrote:

> My view is that since it's pip-installable, it's as though it were
> already an optional package.

I have a very different view of that. "optional" implies a level of
official support in SageMath. In particular, it should actually build
and work properly on all supported systems.

[kcrisman]

On Tuesday, March 13, 2018 at 1:33:19 PM UTC-4, Samuel Lelievre wrote:

Let me try to make the case for making JupyterLab a standard package.

(1)

According to a recent post on the Jupyter blog [0],

- JupyterLab is ready for daily use.

- JupyterLab will eventually replace the classic Jupyter Notebook.

"JupyterLab 1.0 will eventually replace the classic Jupyter Notebook. Throughout this transition, the same notebook document format will be supported by both the classic Notebook and JupyterLab." 

So do we have to yet *again* reimplement notebook interactivity?  How different are they?  How does that affect people wanting to upgrade their notebooks - let alone from sagenb?  What about the CoCalc .sagews format?  And the CoCalc Jupyter notebooks?  I feel like there are some interesting unanswered questions here.

Certainly optional package is fine, though, as long as it works properly on all supported platforms.