Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Jupyter Server #21

Closed
wants to merge 1 commit into from
Closed

Jupyter Server #21

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions ipyserver/ipyserver.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
# Standalone Jupyter Server

## Problems

- There are now multiple frontends that can talk to the backend services provided by the notebook server: the legacy Notebook, the dashboards, JupyterLab, standalone widgets and more.
- The configuration of the server and the legacy notebook are currently tightly coupled in a single NotebookApp configurable.
- The migration towards a `conf.d` approach, which is required for enabling a better mechanism for distributing extensions, is unlikely to be accomplished in a backward compatible fashion.

## Proposed Enhancement

1. The Big Split

The last remaining step of the big split of the notebook repository is simply a clean separation of the server and the pure front-end code.

- Create a new `jupyter server` repository that would essentially be a fork of the current `notebook` repository.
- This notebook should be a pure Python package (`server`?) that only provides the backend services.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

server as a package name seems a very fuzzy and general name (just a Continuum's packager perspective :-)

I'd suggest notebook-server instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it seems that people like jupyter_server which I preempted on pypi. I am 👎 on notebook server because one the points is that it is not merely about the notebook. It is a server for kernels and content. It should work with widgets etc...

- The specific tornado handlers added to support the legacy notebook frontend would not be provided.
- Deprecated APIs of the notebook server would not be carried over to the new server.
- The `jupyter server` repository has only *one* extension point: server extensions. The command name for enabling or installing server extensions will have to be different from the current server extension to avoid conflict. (e.g. `jupyter server extension install`).

2. The Extension Mechanism

The extension mechanism for the *jupyter server* will be the main area where `server` extensions differ from notebook's server extensions.

- The `--sys-prefix` installation would become the default. (Users are confused when enabling an extension requires more permissions than the installation of the package). Installation in system-wide directories would be done with the `--system` option.
- Installing an extension will include the addition of a 'manifest' file into a conf.d directory (under one of the Jupyter configuration directories, `user / sys-prefix / system`). The placement of such an extension manifest provided by a Python package can be done with `jupyter server extension install --py packagename [--user / --system / --sys-prefix]`. Packages (conda or wheels) carrying server extensions could place such manifests in the sys-prefix path by default effectively installing them. Development installations would also require the call to the installation command.
- Enabling an extension is separate from the installation. Multiple scenarios are possible:

- enabling an extension at the same level (user / sys-prefix / system) as where it was installed, or at a higher level (user for sys-prefix and system, or sys-prefix for system).
- forcibly disabling an extension that was enabled at a lower level of precedence.
- forcibly enabling an extension that was disabled at a lower level of precedence.

This would be done via two `conf.d` configuration directories managing a list of disabled extensions and list of enabled extensions in the form of empty files having the name of the corresponding extension. If an extension is both disabled and enabled at the same level of precedence, disabling has precedence. Packages (conda or wheels) could place such a enabler file in the sys-prefix path by default. The `jupyter server extension enable` command would be required for development installations.

- (Possibly) when an extension is enabled at a given precedence level, it may only look for the version of the extension installed at the same or lower precedence level. For example, if an extension `foobar` is installed and enabled system wide, but a user installs a version with `--user`, this version will only be picked up if the user also enables it with `--user`.


3. The Notebook Extension

The legacy Notebook should become an server extension, just like JupyterLab is a server extension.

Eventually *some* front-end content could be provided by server such as a simple app listing installed and enabled extensions...