Fix missing JEPs, move kernel-subshells to follow convention

.github/workflows/docs.yml

@@ -21,10 +21,10 @@ jobs:
     - uses: actions/checkout@v2
 
     # Install dependencies
-    - name: Set up Python 3.7
+    - name: Set up Python 3.9
       uses: actions/setup-python@v1
       with:
-        python-version: 3.7
+        python-version: 3.9
 
     - name: Build the docs
       run: |

.readthedocs.yaml

@@ -0,0 +1,13 @@
+version: 2
+
+build:
+  os: ubuntu-22.04
+  tools:
+    python: "3.9"
+
+sphinx:
+  configuration: conf.py
+
+python:
+  install:
+    - requirements: requirements.txt

jep-process-v2/jep-process-v2.md → 104-jep-process-v2/jep-process-v2.md

@@ -3,7 +3,7 @@ title: Jupyter Enhancement Proposal
 authors: |
   Jason Grout ([jason@jasongrout.org](mailto:jason@jasongrout.org)), Safia Abdalla ([safia@safia.rocks](mailto:safia@safia.rocks)), John Lam ([jflam@microsoft.com](mailto:jflam@microsoft.com)), Kevin M. McCormick ([mckev@amazon.com](mailto:mckev@amazon.com)), Pierre Brunelle ([brunep@amazon.com](mailto:brunep@amazon.com)), Paul Ivanov ([pi@berkeley.edu](mailto:pi@berkeley.edu))
 issue-number: 27
-pr-number: 29
+pr-number: 29, 104
 date-started: "2019-02-23"
 last-update: "2023-10-10"
 type: P - Process

kernelspec-spec/kernelspec-spec.md → 105-kernelspec-spec/kernelspec-spec.md

@@ -2,7 +2,7 @@
 title: kernelspec specification
 authors: Johan Mabille
 issue-number: XX
-pr-number: [#105](https://github.com/jupyter/enhancement-proposals/pull/105)
+pr-number: 105
 date-started: "2023-04-19"
 ---
 

connectionfile-spec/connectionfile-spec.md → 106-connectionfile-spec/connectionfile-spec.md

@@ -2,7 +2,7 @@
 title: connection file specification
 authors: Johan Mabille
 issue-number: XX
-pr-number: XX
+pr-number: 106
 date-started: "2023-04-19"
 ---
 

118-restart-clarification/restart-clarification.md

@@ -6,7 +6,9 @@ pr-number: [#118](https://github.com/jupyter/enhancement-proposals/pull/118)
 date-started: 2023-08-23
 ---
 
-# Summary
+# Restart Clarification
+
+## Summary
 
 The jupyter client protocol around what "restart" means is ambiguous. Per Jupyter Client's [kernel shutdown documention](https://jupyter-client.readthedocs.io/en/latest/messaging.html#kernel-shutdown), the only guidance is:
 >  'restart' : bool # False if final shutdown, or True if shutdown precedes a restart
@@ -16,13 +18,13 @@ This has led to a situation where certain jupyter subprojects (e.g. enterprise g
 We propose to clarify this to always mean "restart-in-place", that is only restart the kernel itself. For
 most usage of Jupyter, this change is a no-op as subprocess kernels already act like this.
 
-# Motivation
+## Motivation
 
 This greatly improves the usability of remote kernels whose startup includes scheduling. By making this change,
 restarts for remote kernels will be nearly as fast as those of local kernels. It also matches what we
 believe to be the mental model of users when they click "restart".
 
-# Guide-level explanation
+## Guide-level explanation
 
 The [protocol](https://jupyter-client.readthedocs.io/en/latest/messaging.html#kernel-shutdown) would describe
 restart as optimally preserving as many resources outside the kernel as possible (e.g. restarting only the kernel process and its subprocess *not* any parent process).
@@ -32,12 +34,12 @@ When the kernel is a toplevel process (e.g. local kernels), there is no change.
 When the kernel is not a toplevel process (e.g. when used in Enterprise Gateway), restart often means only the kernel restarts. To restart the whole progress group, the stop and start messages could be used. It's up to UIs
 for how to display this difference (if any).
 
-# Reference-level explanation
+## Reference-level explanation
 
 The `jupyter-client` messaging page would be updated to indicate this nuance. Any implementations that
 treat restart differently would be updated to match this clarification.
 
-# Rationale and alternatives
+## Rationale and alternatives
 
 A new message could be added, as proposed in the pre-JEP. In the [Jupyter Server meeting](https://github.com/jupyter-server/team-compass/issues/45#issuecomment-1682582186),
 we concluded that is is likely most users want restart to only restart the kernel and not potentially reschedule resources. Therefore, a new message was not the best option.
@@ -46,15 +48,15 @@ is the same as a hard restart since it is the toplevel kernel process.
 
 For users that want a hard restart, a stop followed by a start continues to be available. While this may be less convenient, a UI can trivially hide this two call process from the user.
 
-# Prior art
+## Prior art
 
 N/A
 
-# Unresolved questions
+## Unresolved questions
 
 Only the exact wording changes as proposed in [jupyter_client](https://github.com/jupyter/jupyter_client/pull/966).
 
-# Future possibilities
+## Future possibilities
 
 We would make a service that implements a "hard restart" as discussed in the jupyter-server meeting.
 No one on the meeting had an immediate use case for it.

80-kernel-info/kernel-info.md

@@ -1,4 +1,4 @@
-# Support kernel\_info request on the control channel
+# Support `kernel_info` request on the control channel
 
 ## Problem
 
@@ -14,9 +14,9 @@ We propose to state in the Jupyter Messaging Protocol that the `kernel_info` req
 
 ### Impact on existing implementations
 
-This JEP impacts kernels since it requires them to support receiving 'kernel\_info\_request' on the control channel in addition to receiving them on the shell channel.
+This JEP impacts kernels since it requires them to support receiving `kernel_info_request` on the control channel in addition to receiving them on the shell channel.
 
-It also has an impact on the Jupyter Server. For example, the reference implementation of Jupyter Server will attempt to send a a `kernel_info` request on both channels and listen for a response from _either_ channel. Any response informs the UI that the kernel is connected. 
+It also has an impact on the Jupyter Server. For example, the reference implementation of Jupyter Server will attempt to send a a `kernel_info` request on both channels and listen for a response from _either_ channel. Any response informs the UI that the kernel is connected.
 
 ## Relevant Resources (GitHub repositories, Issues, PRs)
 

kernel-subshells/kernel-subshells.md → 91-kernel-subshells/kernel-subshells.md

@@ -6,11 +6,13 @@ pr-number: 91
 date-started: 2022-12-15
 ---
 
-# Summary
+# Jupyter kernel subshells
+
+## Summary
 
 This JEP introduces kernel subshells to allow for concurrent shell requests.
 
-# Motivation
+## Motivation
 
 Users have been asking for ways to interact with a kernel while it is busy executing CPU-bound code,
 for the following reasons:
@@ -31,7 +33,7 @@ purposes, and the processing of those messages should be almost immediate.
 
 The goal of this JEP is to offer a way to process shell requests concurrently.
 
-# Proposed enhancement: kernel subshells
+## Proposed enhancement: kernel subshells
 
 The proposal is to support extra threads within a kernel as a JEP 92
 [optional feature](https://github.com/jupyter/enhancement-proposals/blob/master/92-jupyter-optional-features/jupyter-optional-features.md) so that whilst the main thread is performing a long blocking task it
@@ -62,9 +64,9 @@ request and receive stdin independently of other subshells.
 
 Each subshell will store its own execution count and history.
 
-## Modifications to existing messages
+### Modifications to existing messages
 
-### Identify optional feature
+#### Identify optional feature
 
 Clients identify if a kernel supports subshells via the
 [optional feature API](https://github.com/jupyter/enhancement-proposals/blob/master/92-jupyter-optional-features/jupyter-optional-features.md):
@@ -85,9 +87,9 @@ The full API for optional features is still to be determined, so the details her
 In particular, there is probably the need for a version specifier here to allow future changes to
 the kernel subshells specification.
 
-## New control channel messages
+### New control channel messages
 
-### Create subshell
+#### Create subshell
 
 Message type: `create_subshell_request`: no content.
 
@@ -103,7 +105,7 @@ content = {
 }
 ```
 
-### Delete subshell
+#### Delete subshell
 
 Message type: `delete_subshell_request`:
 
@@ -123,7 +125,7 @@ content = {
 }
 ```
 
-### List subshells
+#### List subshells
 
 Message type: `list_subshell_request`: no content.
 
@@ -138,9 +140,9 @@ content = {
 
 Note that the parent subshell (`subshell_id = None`) is not included in the returned list.
 
-## New fields on existing messages
+### New fields on existing messages
 
-### Shell and stdin requests
+#### Shell and stdin requests
 
 All shell and stdin messages will allow the optional `subshell_id` field in the request to identify
 which subshell should process that message:
@@ -154,14 +156,14 @@ content = {
 
 This field is not in the corresponding reply message as it will be in the parent header.
 
-### IOPub messages
+#### IOPub messages
 
 IOPub messages do not need an extra optional `subshell_id` field as this information is available
 in the parent header.
 
-## Behavior
+### Behavior
 
-### Kernels supporting subshells
+#### Kernels supporting subshells
 
 A subshell request may be processed concurrently with other subshells. Within a an individual
 subshell, requests are processed sequentially.
@@ -172,15 +174,15 @@ messages are handled at the kernel (process) rather than subshell (thread) level
 include a `subshell_id` field. A child subshell can be individually shut down using a
 `delete_subshell_request` message.
 
-### Kernels not supporting subshells
+#### Kernels not supporting subshells
 
 These will not claim support for kernel subshells via the optional features API. Unrecognised shell
 request messages, such as the subshell request messages listed above, will be ignored as normal.
 Any use of a `subshell_id` field in a message will be ignored. Hence existing kernels that do not
 support kernel subshells will continue to work as they currently do and will not require any
 changes.
 
-## Implications for other projects
+### Implications for other projects
 
 Kernel writers who wish to support subshells will need to write extra threading and socket
 management code. `ipykernel` will contain a reference implementation.

92-jupyter-optional-features/jupyter-optional-features.md

@@ -6,13 +6,15 @@ pr-number: 92
 date-started: 2023-01-16
 ---
 
-# Summary
+# Jupyter Optional Features
+
+## Summary
 
 This JEP introduces Jupyter optional features, which ease the way
 a kernel advertises which features it supports, without coupling it
 to the version of the protocol that it implements.
 
-# Motivation
+## Motivation
 
 Some of the features that were added (the debugger) or proposed (the subshells)
 may require a lot of work from kernel authors to implement. Besides, the
@@ -27,7 +29,7 @@ and to have an explicit list of such features. This way, we do not prevent kerne
 authors from upgrading to a more recent version of the protocol when we introduce
 a new feature that may be complicated to implement and not mandatory for them.
 
-# Proposed Enhancement
+## Proposed Enhancement
 
 We propose to add a new `supported_features` field to the `kernel_info_reply` message.
 This field is a list of optional features that the kernel supports. The boolean field

debugger-info-copy-to-globals/debugger-info-copy-to-globals.md → 93-debugger-info-copy-to-globals/debugger-info-copy-to-globals.md

@@ -1,30 +1,32 @@
 ---
-title: Debugger support to copyToGlobals
+title: Debugger support to `copyToGlobals`
 authors: Nicolas Brichet (@brichet)
 issue-number: xxx
-pr-number: xxx
+pr-number: 93
 date-started: 2023-02-20
 ---
 
-# Summary
+# Debugger support to `copyToGlobals`
+
+## Summary
 
 This JEP introduces a new field to the kernel debugger_info response. This new
 field will inform the UI that the debugger supports the `copyToGlobals` request.
 
-# Motivation
+## Motivation
 
 The `copyToGlobals` request has been introduced in
 [ipykernel](https://github.com/ipython/ipykernel/pull/1055) and in
 [xeus-python](https://github.com/jupyter-xeus/xeus-python/pull/562) to copy a local
 variable to the global scope during a breakpoint. It would be useful to inform the
 UI if this is supported by the kernel before displaying the corresponding menu entry.
 
-# Proposed Enhancement
+## Proposed Enhancement
 
 We propose to add a new `copyToGlobals` boolean field to the `debugger_info`
 response which will inform the UI that this request is supported.
 
-## Reference-level explanation
+### Reference-level explanation
 
 This boolean flag should be included in the `debugger_info` response from the kernel
 which supports the feature. It is optional, assuming that its absence is understood

97-add-schema/add-schema-to-notebook-format.md

@@ -6,15 +6,17 @@ pr-number: 97
 date-started: 2023-03-01
 ---
 
-# Summary
-
+# Add `$schema` to notebook format
+
+## Summary
+
 We propose to add a new top-level required property, `$schema` to the notebook JSON, as such updating the notebook JSON schema. This new property deprecates `nbformat` and `nbformat_minor`.
 
-# Motivation
+## Motivation
 
 Today, `nbformat` and `nbformat_minor` specify the JSON schema a notebook should adhere to (for example [4.5](https://github.com/jupyter/nbformat/blob/main/nbformat/v4/nbformat.v4.5.schema.json)). Since this approach was adopted in the Jupyter ecosystem, the JSON schema standard has evolved and Jupyter's approach is no longer in line with it. Other than following standards being the right thing to do, bringing the notebook format back in line with the current JSON Schema spec opens it up to the rich tooling that exists around JSON schema validation today.
 
-# Guide-level explanation
+## Guide-level explanation
 
 The new required `$schema` top-level property refers to a JSON Schema that validates the current notebook. During a deprecation period, `$schema` takes precedence over the existing `"nbformat"` and `"nbformat_minor"` properties that specify the notebook format. There will be a one-to-one mapping between `$schema` and the `(nbformat, nbformat_minor)` pair, which should follow a URI template, e.g.:
 ```json
@@ -30,7 +32,7 @@ After the deprecation period expires, a future JEP will remove these `nbformat`
 The addition of the `$schema` property removes a level of indirection between the notebook and the schema against which it is invalidated. It also guarantees that the schema against which it is validated is invariant with respect to time; the schema URI should refer to an immutable document.
 
 
-# Reference-level explanation
+## Reference-level explanation
 
 The following changes are made to the existing v4.5 schema:
 ```diff
@@ -580,20 +582,20 @@ Invalid `$schema` URI:
 The schema identified by `$schema` MUST require that the `nbformat` and `nbformat_minor` properties are `const`. This ensures that there is a one-to-one mapping between schemas and nbformat versions published up-to the final nbformat version of the deprecation period.
 
 
-# Rationale and alternatives
+## Rationale and alternatives
 
 Not doing this will leave the Jupyter notebook format in a non-standard state.
 
-# Prior art
+## Prior art
 
 [JSON Schema](https://json-schema.org/) is a widely adopted declarative language that annotates and validates documents, so it's the obvious candidate to adhere to.
 
-# Unresolved questions
+## Unresolved questions
 
 - Code to upgrade from and downgrade to 4.5 still needs to be written.
 Some exploration has been done by Nick Bollweg in [this gist](https://gist.github.com/bollwyvl/a6e1ae13125f01ff04edf121e30a462a).
 - We want to deprecate `nbformat` and `nbformat_minor` in favor of `$schema` but we also need to ensure old clients can still work with notebooks in this new schema, so `nbformat` and `nbformat_minor` are still required. What's the path here? Major version update?
 
-# Future possibilities
+## Future possibilities
 
 This work paves the way for [``Add `extraSchemas` to notebook format`` JEP](https://hackmd.io/9QZ8YibfQHm9l1B6JPSQsg?both), which will be submitted as a separate JEP soon.

README.md

@@ -38,10 +38,19 @@ encouraged to commence on the topic.
 | 0047 | Implemented | [Jupyter Debugger Protocol](47-jupyter-debugger-protocol/jupyter-debugger-protocol.md) | [#47](https://github.com/jupyter/enhancement-proposals/pull/47) |
 | 0062 | Implemented | [Cell ID Addition to Notebook Format](62-cell-id/cell-id.md) | [#62](https://github.com/jupyter/enhancement-proposals/pull/62) |
 | 0065 | **Accepted** | [Replace PUB socket with XPUB socket](65-jupyter-xpub/jupyter-xpub.md) | [#65](https://github.com/jupyter/enhancement-proposals/pull/65) |
-| 0066 | **Accepted** | Kernel Handshaking pattern[](66-jupyter-handshaking/jupyter-handshaking.md) | [#66](https://github.com/jupyter/enhancement-proposals/pull/66) |
+| 0066 | **Accepted** | [Kernel Handshaking pattern](66-jupyter-handshaking/jupyter-handshaking.md) | [#66](https://github.com/jupyter/enhancement-proposals/pull/66) |
 | 0072 | **Accepted** | [Language server protocol (LSP)](72-language-server-protocol/language-server-protocol.md) | [#72](https://github.com/jupyter/enhancement-proposals/pull/72) |
 | 0079 | Implemented | [Build Jupyter Notebook v7 off of JupyterLab components](79-notebook-v7/notebook-v7.md) | [#79](https://github.com/jupyter/enhancement-proposals/pull/79) |
+| 0080 | **Accepted** | [Support `kernel_info` request on the control channel](80-kernel-info/kernel-info.md) | [#80](https://github.com/jupyter/enhancement-proposals/pull/80) |
+| 0091 | **Accepted** | [Jupyter kernel subshells](91-kernel-subshells/kernel-subshells.md) | [#91](https://github.com/jupyter/enhancement-proposals/pull/91) |
+| 0092 | **Accepted** | [Jupyter Optional Features](92-jupyter-optional-features/jupyter-optional-features.md) | [#92](https://github.com/jupyter/enhancement-proposals/pull/92) |
+| 0093 | **Accepted** | [Debugger support to `copyToGlobals`](93-debugger-info-copy-to-globals/debugger-info-copy-to-globals.md) | [#93](https://github.com/jupyter/enhancement-proposals/pull/93) |
+| 0097 | **Accepted** | [Add `$schema` to notebook format](97-add-schema/add-schema-to-notebook-format.md) | [#97](https://github.com/jupyter/enhancement-proposals/pull/97) |
+| 0104 | **Accepted** | [Jupyter Enhancement Proposal v2](104-jep-process-v2/jep-process-v2.md) | [#104](https://github.com/jupyter/enhancement-proposals/pull/104) |
+| 0105 | **Accepted** | [kernelspec specification](105-kernelspec-spec/kernelspec-spec.md) | [#105](https://github.com/jupyter/enhancement-proposals/pull/105) |
+| 0106 | **Accepted** | [Connection file specification](106-connectionfile-spec/connectionfile-spec.md) | [#106](https://github.com/jupyter/enhancement-proposals/pull/106) |
 | 0108 | **Accepted** | [Subdomain and repository for publishing schemas under jupyter.org](108-jupyter-subdomain-for-schemas/jupyter-subdomain-for-schemas.md) | [#108](https://github.com/jupyter/enhancement-proposals/pull/108) |
+| 0118 | **Accepted** | [Restart Clarification](118-restart-clarification/restart-clarification.md) | [#118](https://github.com/jupyter/enhancement-proposals/pull/118) |
 | 0122 | **Accepted** | [Incorporate Jupyter Book as a subproject](./122-jupyter-book-incorporation/jupyter-book-incorporation.md) | [#123](https://github.com/jupyter/enhancement-proposals/pull/123) |
 
 ## How do I submit a JEP?