Skip to content

Commit 203eb25

Browse files
committed
minimal changes for jupyter book website
1 parent 0739b61 commit 203eb25

File tree

14 files changed

+131
-81
lines changed

14 files changed

+131
-81
lines changed

.gitignore

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -25,3 +25,6 @@ build/Release
2525
# Dependency directory
2626
# https://www.npmjs.org/doc/misc/npm-faq.html#should-i-check-my-node_modules-folder-into-git
2727
node_modules
28+
29+
# Jupyter Book
30+
_build

jupyter-server/jupyter-server.md renamed to 28-jupyter-server/jupyter-server.md

Lines changed: 42 additions & 42 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,13 @@
1-
# Standalone Jupyter server enhancement proposal [active]
2-
3-
| Item | Value |
4-
|------------|------------------------------------------------------------------------------------------------------------------------------|
5-
| JEP Number | 10 |
6-
| Title | Standalone Jupyter Server |
7-
| Authors | Zach Sailer ([@Zsailer](https://github.com/Zsailer)) and Sylvain Corlay ([@SylvainCorlay](https://github.com/sylvaincorlay)) |
8-
| Status | Draft |
9-
| Type | S - [Standards Track](https://www.python.org/dev/peps/#pep-types-key) JEP |
10-
| Created | 20 September 2016 |
11-
| History | 20 September 2016, 12 February 2019 |
1+
---
2+
title: Standalone Jupyter server
3+
authors: Zach Sailer ([@Zsailer](https://github.com/Zsailer)) and Sylvain Corlay ([@SylvainCorlay](https://github.com/sylvaincorlay))
4+
issue-number: 31
5+
pr-number: 28
6+
date-started: "2016-09-20"
7+
type: S - [Standards Track](https://www.python.org/dev/peps/#pep-types-key)
8+
---
9+
10+
# Standalone Jupyter server enhancement
1211

1312
## Problem
1413

@@ -19,7 +18,7 @@ There are now multiple frontends that talk to the backend services provided by t
1918
Decouple the backend server (and its configuration) from the classic notebook frontend. This will require the following steps:
2019

2120
1. [Separate `jupyter_server` repository](#separate-jupyter_server-repository)
22-
- A fork of the `notebook` repository.
21+
- A fork of the `notebook` repository.
2322
- Pure Python package with notebook backend services.
2423
- `notebook` tornado handlers and frontend logic stay in `notebook` repo.
2524
- Deprecated notebook server APIs do not move to `jupyter_server`.
@@ -29,12 +28,12 @@ Decouple the backend server (and its configuration) from the classic notebook fr
2928
1. [Extensions as Applications](#extensions-as-applications)
3029
- server extensions move to `jupyter_server`.
3130
- New `ExtensionApp` class
32-
- Notebook, jupyterlab, etc. become ExtensionApps.
31+
- Notebook, jupyterlab, etc. become ExtensionApps.
3332
1. [New server extensions mechanism.](#new-server-extensions-mechanism)
34-
- new base classes to create applications from server extensions.
35-
- nbextensions stay in `notebook`.
33+
- new base classes to create applications from server extensions.
34+
- nbextensions stay in `notebook`.
3635
- `jupyter_notebook_config.d` folder becomes `jupyter_server_config.d`
37-
1. [Namespacing static files and REST API urls.](#add-namespacing-to-static-endpoints-and-rest-api-urls)
36+
1. [Namespacing static files and REST API urls.](#add-namespacing-to-static-endpoints-and-rest-api-urls)
3837
- Each extension serves static files at the `/static/<extension>` url.
3938
- New `ExtensionHandlerApp` class
4039
1. [Configuration System](#configuration-system)
@@ -45,7 +44,7 @@ Decouple the backend server (and its configuration) from the classic notebook fr
4544
### Separate `jupyter_server` repository
4645

4746
The first thing to do is fork `notebook`. A new `jupyter_server` repo will keep the server specific logic and remove:
48-
1. the notebook frontend code,
47+
1. the notebook frontend code,
4948
2. deprecated notebook server APIs, and
5049
3. tornado handlers to the classic notebook interface. These pieces will stay in the `notebook` repository.
5150

@@ -74,11 +73,11 @@ Preliminary work resides in [jupyter_server](https://github.com/jupyter/jupyter_
7473

7574
The server-notebook split is an opportunity to clearly define Jupyter's core services. The old notebook server was comprised of many services, and it could be extended by separate "server extensions". However, it isn't clear what should be a core service versus a server extension. Some extensions were "grand-fathered" in as core services to make the notebook application more full-featured (e.g. nbconvert, terminals, contents, ...). Now that we are separating the server from the classic notebook, we need to reevaluate what services are core to the Jupyter Server.
7675

77-
Jupyter server aims to be a core building block for other applications (like nteract, lab, dashboards, standalone widgets, etc.). To achieve this, we need to define the simplest "unit" that defines a Jupyter Server: `kernels`, `kernelspec`, and `sessions`. Other services become extensions to the core server (using the `load_jupyter_server_extension` mechanism defined below).
76+
Jupyter server aims to be a core building block for other applications (like nteract, lab, dashboards, standalone widgets, etc.). To achieve this, we need to define the simplest "unit" that defines a Jupyter Server: `kernels`, `kernelspec`, and `sessions`. Other services become extensions to the core server (using the `load_jupyter_server_extension` mechanism defined below).
7877

7978
### Extensions as Applications
8079

81-
A new `ExtensionApp` class will be available in `jupyter_server.extensions.extensionapp`. It enables developers to make server extensions behave like standalone Jupyter applications. Jupyterlab is an example of this kind of server extension. It can be configured, initialized, and launched from the command line. When Lab is launched, it first initializes and configures a jupyter (notebook) server, then loads the configured jupyterlab extension and redirects the use to the Lab landing page.
80+
A new `ExtensionApp` class will be available in `jupyter_server.extensions.extensionapp`. It enables developers to make server extensions behave like standalone Jupyter applications. Jupyterlab is an example of this kind of server extension. It can be configured, initialized, and launched from the command line. When Lab is launched, it first initializes and configures a jupyter (notebook) server, then loads the configured jupyterlab extension and redirects the use to the Lab landing page.
8281

8382
`ExtensionApp` handles the boilerplate code to make Jupyter applications that configure and launch server extensions directly. It inherits `jupyter_core.JupyterApp` and exposes a command line entry point: `jupyter <extension-name>`. When an extension is launched, it first configures and starts a jupyter_server (`ServerApp`); then, it loads the configured extension and redirects users to the extension's landing page. Extension developers simply inherit the `ExtensionApp` and add the extension's `load_jupyter_server_extension` as a `staticmethod`.
8483

@@ -93,7 +92,7 @@ class MyExtension(ExtensionApp):
9392
load_jupyter_server_extension = staticmethod(load_jupyter_server_extension)
9493
```
9594

96-
`ExtensionApp`s can be configured by `jupyter_<extension-name>_config.py|json` as well. When the server extension is loaded by a server or launched from the command line, it searches the list of `jupyter --paths` for configured traits in these files.
95+
`ExtensionApp`s can be configured by `jupyter_<extension-name>_config.py|json` as well. When the server extension is loaded by a server or launched from the command line, it searches the list of `jupyter --paths` for configured traits in these files.
9796

9897
Initial experimental work resides in [`jupyter_server_extension`](https://github.com/Zsailer/jupyter_server_extension).
9998

@@ -105,21 +104,21 @@ c.ServerApp.jpserver_extensions = {
105104
'notebook': True
106105
}
107106
```
108-
Users can also launch the notebook application using the (usual)`jupyter notebook` command line interface.
107+
Users can also launch the notebook application using the (usual)`jupyter notebook` command line interface.
109108

110109
### New server extensions mechanism.
111110

112111
The new extension mechanism in the *jupyter server* will differ from notebook's server extensions.
113112

114-
* 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.
113+
* 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.
115114
* 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.
116115

117116
* Enabling an extension is separate from the installation. Multiple scenarios are possible:
118117
- 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).
119118
- forcibly disabling an extension that was enabled at a lower level of precedence.
120119
- forcibly enabling an extension that was disabled at a lower level of precedence.
121120
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.
122-
121+
123122
(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`.
124123

125124
### Add namespacing to `static` endpoints and REST API urls.
@@ -136,32 +135,32 @@ Preliminary experimental work resides in the [`jupyter_server_extension`](https:
136135

137136
Splitting the server-specific pieces from the classic notebook affects Jupyter's configuration system. This is a non-trivial problem. Changing Jupyter's configuration system affects everyone. We need to consider how to make this transition as painless as possible. At the end of this section, we list some steps that make reduce the friction.
138137

139-
Here is a list of things the changes on the configuration system:
138+
Here is a list of things the changes on the configuration system:
140139
* Move server-specific configuration from `jupyter_notebook_config.py|json` into `jupyter_server_config.py|json`.
141140
* Notebook configuration will stay in `jupyter_notebook_config.py|json`.
142141
* Server extensions configurations move from `jupyter_notebok_config.d` to `jupyter_server_config.d`.
143142
* The tornado server and webapp configurable applications move to `jupyter_server`. They become `ServerApplication` and `ServerWebApp`
144143
* The `NotebookApp` becomes a server extension. It would only load notebook specific configuration/traitlets, from `jupyter_notebook_config.py|json`.
145-
* Server extensions are found using the `jpserver_extensions` trait instead of the `nbserver_extensions` trait in the `ServerApp`.
144+
* Server extensions are found using the `jpserver_extensions` trait instead of the `nbserver_extensions` trait in the `ServerApp`.
146145
* Extension configuration files in `jupyter_server_config.d` must be enabled using the `jpserver_extensions` trait. They are enabled by JSON config files in `jupyter_server_config.d`.
147146
* Extensions can create their own configuration files in `{sys-prefix}/etc/jupyter/` or `~/.jupyter`, i.e. `jupyter_<my-extension>_config.py|json`.
148147
* General `jupyter_config.py|json` files must update to set server-specific configuration using the `ServerApp` and notebook specific configuration using `NotebookApp`.
149148

150149
Some traits will stay in `jupyter_notebook_config.py|json`. Here is a list of those traits (everything else moves to server config files):
151-
* extra_nbextensions_path
152-
* enable_mathjax
153-
* max_body_size
154-
* max_buffer_size
155-
* notebook_dir
156-
* mathjax_url
157-
* get_secure_cookie_kwargs
158-
* mathjax_config
150+
* extra_nbextensions_path
151+
* enable_mathjax
152+
* max_body_size
153+
* max_buffer_size
154+
* notebook_dir
155+
* mathjax_url
156+
* get_secure_cookie_kwargs
157+
* mathjax_config
159158
* ignore_minified_js
160159

161160
Here are some steps we can take to reduce the friction for transitioning:
162161
* **Copy (not move)** `jupyter_notebook_config.py|json` to `jupyter_server_config.py|json`
163162
* **Copy (not move)** `jupyter_notebook_config.d/` to `jupyter_server_config.d`.
164-
* `NotebookApp` becomes `ServerApp` in all copied files.
163+
* `NotebookApp` becomes `ServerApp` in all copied files.
165164
* Leftover server traits in `jupyter_notebook_config.py|json` get ignored when the notebook extension is initialized. Server traits are only read from `jupyter_server_config.py|json`.
166165
* Document like crazy!
167166

@@ -173,17 +172,18 @@ To make migration easier on users, a `migrate` application will be available to
173172

174173
### How this effects other projects
175174

176-
[**Classic notebook**]()
175+
**Classic notebook**
177176
In short, the classic notebook will become a server extension application. The rest of this proposal describes the details behind what will change in the notebook repo.
178-
[`JupyterServerExtensionApp`]().
179177

180-
[**Jupyter Lab**]()
178+
`JupyterServerExtensionApp`
179+
180+
**Jupyter Lab**
181181
Jupyter lab will also become a server extension application. The new classes described above should simplify the way JupyterLab interfaces with the server.
182182

183-
[**Kernel Gateway**]()
184-
Kernel Gateway can use the new Jupyter Server to server kernels as a service. The new Jupyter server will remove the unwanted services that Kernel Gateway currently removes by using a custom server application. KG will also be able to swap out the kernels and kernelspec manager in the Jupyter Server with its custom classes.
183+
**Kernel Gateway**
184+
Kernel Gateway can use the new Jupyter Server to server kernels as a service. The new Jupyter server will remove the unwanted services that Kernel Gateway currently removes by using a custom server application. KG will also be able to swap out the kernels and kernelspec manager in the Jupyter Server with its custom classes.
185185

186-
[**Kernel Nanny**]()
186+
**Kernel Nanny**
187187

188188
## Pros and Cons
189189

@@ -198,7 +198,7 @@ Kernel Gateway can use the new Jupyter Server to server kernels as a service. Th
198198

199199
* Break the classic notebook in a backwards incompatible way.
200200
* Affects many projects. The transition may be painful?
201-
* Adding a dependency injection system adds new complexity.
201+
* Adding a dependency injection system adds new complexity.
202202

203203
## Relevent Issues, PRs, and discussion
204204

@@ -217,4 +217,4 @@ Static Namespace:
217217

218218
## Interested
219219

220-
@Zsailer, @SylvainCorlay, @ellisonbg, @blink1073, @kevin-bates
220+
@Zsailer, @SylvainCorlay, @ellisonbg, @blink1073, @kevin-bates

29-jep-process/README.md renamed to 29-jep-process/jep-process.md

Lines changed: 13 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,16 @@
1-
| Item | Value |
2-
| ---------- | ------------------------------------------------------------ |
3-
| JEP number | 29 |
4-
| Title | Jupyter Enhancement Proposal |
5-
| Authors | Jason Grout ([[email protected]](mailto:[email protected])), Safia Abdalla ([[email protected]](mailto:[email protected])), John Lam ([[email protected]](mailto:[email protected])), Kevin M. McCormick ([[email protected]](mailto:[email protected])), Pierre Brunelle ([[email protected]](mailto:[email protected])), Paul Ivanov ([[email protected]](mailto:[email protected])) |
6-
| Status | Draft |
7-
| Type | P - Process |
8-
| Created | 23-Feb-2019 |
9-
| History | 04-Mar-2019, 07-Mar-2019 |
10-
11-
### Background
1+
---
2+
title: Jupyter Enhancement Proposal
3+
authors: |
4+
Jason Grout ([[email protected]](mailto:[email protected])), Safia Abdalla ([[email protected]](mailto:[email protected])), John Lam ([[email protected]](mailto:[email protected])), Kevin M. McCormick ([[email protected]](mailto:[email protected])), Pierre Brunelle ([[email protected]](mailto:[email protected])), Paul Ivanov ([[email protected]](mailto:[email protected]))
5+
issue-number: 27
6+
pr-number: 29
7+
date-started: "2019-02-23"
8+
type: P - Process
9+
---
10+
11+
# Jupyter Enhancement Proposal
12+
13+
## Background
1214

1315
Project Jupyter has an existing repository and process for “Jupyter Enhancement Proposals” or JEP for short. The repository is here:
1416

voila-incorporation/voila-incorporation.md renamed to 42-voila-incorporation/voila-incorporation.md

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,13 @@
1-
# Voilà Incorporation Proposal
1+
---
2+
title: Voilà Incorporation
3+
authors: SylvainCorlay
4+
issue-number: XX
5+
pr-number: 42
6+
date-started: "2019-10-14"
7+
type: S - [Standards Track](https://www.python.org/dev/peps/#pep-types-key)
8+
---
9+
10+
# Voilà Incorporation
211

312
## Problem
413

xeus-incorporation/xeus-incorporation.md renamed to 44-xeus-incorporation/xeus-incorporation.md

Lines changed: 10 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,18 @@
1-
# Xeus Incorporation Proposal
1+
---
2+
title: Xeus Incorporation
3+
authors: SylvainCorlay
4+
issue-number: XX
5+
pr-number: 44
6+
date-started: "2019-11-30"
7+
---
8+
9+
# Xeus Incorporation
210

311
## Problem
412

513
The [Xeus](https://github.com/QuantStack/xeus/) project is a C++ implementation of the [Jupyter kernel protocol](https://jupyter-client.readthedocs.io/en/stable/messaging.html). Xeus is not a kernel, but a library meant to facilitate the authoring of kernels.
614

7-
Several Jupyter kernels have been created with Xeus:
15+
Several Jupyter kernels have been created with Xeus:
816

917
- [xeus-cling](https://github.com/QuantStack/xeus-cling), a kernel for the C++ programming language, based on the Cling C++ interpreter. The [cling](https://github.com/root-project/cling) project comes from CERN and is at the foundation of the [ROOT](https://github.com/root-project/root.git) project.
1018
- [xeus-python](https://github.com/QuantStack/xeus-python), a kernel for the Python programming language, embedding the Python interpreter.

0 commit comments

Comments
 (0)