Move RetroLab to the jupyterlab organization

[jtpio]

EDIT: the project has been renamed to RetroLab.

Previously demoed at the JupyterLab developer meeting and at one of the Jupyter community calls, RetroLab is an alternative JupyterLab distribution with a retro look and feed, similar to the Classic Notebook UI.

The project is currently living in the following repository:

https://github.com/jtpio/retrolab

Even though the project hasn't officially been announced yet, it already seems to be getting some adoption and positive feedback:

• Tweet about the prototype: https://twitter.com/jtpio/status/1335941493614387205
• Tweet about the first release candidate: https://twitter.com/jtpio/status/1338534217114923008
• Being considered in a couple of repos to replace the Classic Notebook, for example:
  • Lab 3 migration nbgallery/docker-images#17
  • JupyterLab 3.0 jupyter/docker-stacks#1207
• 77 stars on GitHub as of 2021/05/19

This JupyterLab distribution is not meant to replace the Simple Interface mode of JupyterLab. It targets Jupyter users currently using the Classic Notebook as their main notebook interface.

Since there are plans for sunsetting the Classic Notebook, JupyterLab Classic positions itself as an alternative to the Classic Notebook to help users move towards JupyterLab based interfaces.

Being published to PyPI and conda-forge, retrolab can be used as is by end users. It also serves as an example of an alternative JupyterLab distribution.

Criteria for official subprojects

Have an active developer community that offers a sustainable model for future development.

As of today (2021/05/19), 3 contributors have committed to the repository. However a couple more people from the Jupyter community have also contributed to the project by opening issues, testing and giving feedback.

Have an active user community.

One target user community is the Classic Notebook users, who might not be ready to fully transition to JupyterLab. In a way, RetroLab sits between JupyterLab and the Classic Notebook and can also be seen as a "lightweight" JupyterLab.

It also targets developers who would like to build their own distribution with JupyterLab component, serving as an example implementation.

Use solid software engineering with documentation and tests hosted with appropriate technologies (Read The Docs and Travis are examples of technologies that can be used).

For now, the documentation is a list of screenshots in the main README.md file. However there is an issue to consider adding proper user documentation, for example using Jupyter Book.

CI runs on GitHub Actions to:

• build the application
• lint the code
• run unit tests using jest
• run end to end tests with playwright to test higher level functionality such as renaming a notebook or creating new notebooks in new browser tabs.

End to end tests produce artifacts (videos and screenshots) that are then uploaded to GitHub Actions.
The idea would be to migrate to using galata as the testing framework once it has been made open source.

The release process has been automated using GitHub Actions workflows and is documented in https://github.com/jtpio/retrolab/blob/main/RELEASE.md#automated-releases.

Demonstrate continued growth and development.

RetroLab quickly reached feature parity with the Classic Notebook, since it is able to reuse a lot of existing components from upstream JupyterLab.

It currently depends on the latest stable versions of JupyterLab for the @jupyterlab/ packages, and is often updated. New releases can be cut often since the process has now been automated.

Recently jupyterlab-lsp also added experimental support for RetroLab (called JupyterLab Classic at the time), to enable IDE like and code completion features to a Classic-like frontend: https://github.com/krassowski/jupyterlab-lsp/pull/465

We expect most extensions to be compatible with both JupyterLab and RetroLab, leveraging the new distribution system for prebuilt extensions added in JupyterLab 3.0.

Integrate well with other official Subprojects

RetroLab reuses many of the existing JupyterLab plugins and leverages a lot of the work put into its development.

It also includes a Jupyter Server extension, and all these different interfaces can perfectly be installed together in the same environment:

• JupyterLab
• NBClassic
• RetroLab

Be developed according to the Jupyter governance and contribution model that is documented here

The contributing guide can be extended to provide links to these resources.

Have a well-defined scope.

See https://github.com/jtpio/retrolab#relation-to-other-jupyter-frontends

Be packaged using appropriate technologies such as pip, conda, npm, bower, docker, etc.

RetroLab is packaged and published to:

• PyPI: https://pypi.org/project/retrolab/
• conda-forge: https://anaconda.org/conda-forge/retrolab
• npm (so extension authors can build extensions for RetroLab too)

It can also be used on Binder:

Next Steps

To gain visibility and momentum, the first step would be to move the repository to the jupyterlab organization.

The move should also benefit JupyterLab directly, as there might be room to make the build system and prebuilt extensions system more convenient for other third-party lab-based apps.

RetroLab could also become a reference implementation for alternative JupyterLab distributions. This could lead to templates for third-party lab-based apps, and improved workflows for distribution / extension authors.

Finally we might want to consider whether Retro should be installed by default in JupyterLab. Whether that means adding it as a dependency, or moving the code and functionalities to the jupyterlab repository, this is still an open question. And related to the parallel track of sunsetting the Classic Notebook.

-> jupyterlab/jupyterlab#9869

References

• https://discourse.jupyter.org/t/benefits-of-the-classic-ui-and-use-cases-for-classic-over-jupyterlab-was-why-is-tim-not-moving-to-lab/2419
• Notebook-only mode: provide a 1 to ~1 equivalent of notebook classic, implemented using jupyterlab api: Notebook-only mode: provide a 1 to ~1 equivalent of notebook classic, implemented using jupyterlab api jupyterlab#8450
• Fixed width notebook: Notebook maximum width.  jupyterlab#600

[choldgraf]

My 2 cents: I think this is a great idea, having jupyterlab-classic in the jupyterlab/ org would have the following benefits:

• It gives organizations building software geared towards beginners a less-complex interface than JupyterLab
• It shows off the composability of the JupyterLab interface system
• It gives people who 'just want the notebook interface' an on-ramp into the JupyterLab ecosystem
• It potentially clarifies the pathway to further-reducing development on notebook/
• A second 'first class' distribution of JupyterLab components is a good dog-fooding practice to avoid making too many assumptions about the full JupyterLab UI when developing the components

That said, I definitely think that there should be a plan around making sure that maintenance burden is shared equitably between the community.

[jtpio]

Quick update to mention that JupyterLab Classic has been renamed to RetroLab: https://github.com/jtpio/retrolab

And there is now a 0.3.0a0 prerelease using the latest JupyterLab alpha packages, with support for real time collaboration:

• Gist: https://gist.github.com/jtpio/4a6a34da66b32249e28df718ec30e4d7
• Binder: https://mybinder.org/v2/gist/jtpio/4a6a34da66b32249e28df718ec30e4d7/master?urlpath=/retro/tree
• Screencast:

[choldgraf]

2 quick thoughts:

1. I think it's super awesome

2. If you're thinking of renaming it, could I push back lightly on calling it "retrolab"? I like the name retrolab, but I worry that it will make this interface feel like a "backwards-looking" interface rather than the legimitately cool and useful interface that it is. I don't think this interface is only useful because it resembles older technology, I think it's cool as a standalone UI on its own!

   I don't think the name is problematic at all, I just wonder if there's something else that evokes a stronger positive connotation. I don't think it's a dealbreaker at all but wanted to share my thoughts in case it resonated

[afshin]

I think jupyter retro is a fun command to type and I think the concept of modern building blocks being used to evoke a UI built in the heyday of jQuery is pretty retro. I'm enthusiastically 👍 on it.

The official Jupyter web front-ends that we ship today are notebook, nbclassic, and jupyterlab. Adding another front-end composed of phonemes from those three names does strike me as problematic for end users trying to disambiguate what their choices are, which is the point of this issue Jeremy linked above: jupyterlab/jupyterlab#9869

So my two takeaways are:

1. This is awesome, Jeremy. Let's bring it into the JupyterLab org.
2. The new name is catchy, fun, and apt.

[krassowski]

I like both "JupyterLab Retro" and "jupyter retro" and I am 100% for bringing it into the JupyterLab org now (just after the rename so it's less hassle with renaming packages again).

I would suggest a different logo though; the previous classic logo was great, and maybe having retro in a similar style could work too? Also, the current logo and style of "RetroLab" is too similar to an existing product RobotLab to me - not only the name is visually similar, but Robot associated tools often use similar fonts to what is in the current logo. I just can't help but see "RobotLab" when looking at the current purple logo.

[jtpio]

the current logo and style of "RetroLab" is too similar to an existing product RobotLab to me - not only the name is visually similar, but Robot associated tools often use similar fonts to what is in the current logo. I just can't help but see "RobotLab" when looking at the current purple logo.

Right. For now this is mostly a placeholder logo to replace the previous "Jupyter Classic". It was quickly created by using a "retro" font.

But it would be great to update for sure. If anyone wants to give it a shot, that would be really appreciated. Thanks!

[jtpio]

@krassowski new proposal for the logo in https://github.com/jtpio/retrolab/pull/131 (thanks @wolfv!)

[afshin]

This is amazing 🌅

[telamonian]

@jtpio That is some strong icon work. Would look offset against the @yeebc/jupyterlab_neon_theme theme:

Speaking of that, what is the current state of theme support in retrolab?

[jtpio]

That is some strong icon work

Many thanks to Wolf for that!

Would look offset against the @yeebc/jupyterlab_neon_theme theme

Yes the PR posted above has a screenshot with the miami nights theme, which is based on the neon theme:

Speaking of that, what is the current state of theme support in retrolab?

They should work out of the box if installed as a prebuilt extension (darcula does for example): https://github.com/jtpio/retrolab#themes-

[telamonian]

They should work out of the box

sweet

[afshin]

We discussed bringing RetroLab into the github.com/jupyterlab org during today's weekly JupyterLab call and agreed to move forward with this 👍

[jtpio]

The repository has now been moved to the jupyterlab organization: https://github.com/jupyterlab/retrolab

Thanks all!

[yuvipanda]

UC Berkeley is likely going to use retrolab for the data8 class, starting with the smallish summer pilot (~100-200 students) but hopefully scaling out to the full ~1,500 students in Fall. I think it being in the JupyterLab org helped convince some people, so am glad this happened.