When removing the classic notebook frontend from jupyter_server, we have kept the nbconvert handlers.

Should these be removed and made a separate server extension?

cc @mpacer

Currently, if you start jupyter server it always starts a browser process. Should support --no-browser that makes this not happen.

Given e.g. the case of Voilà, you want the server to not add some of the default handlers (while you want some of them). This should ideally be overridable by a subclass of ServerApp (but probably not user configurable?).

Taking the Voilà example again, you probably want to:

• Keep the configurable login/logout handlers.
• Keep the kernel/kernelspecs/security handlers.
• Not keep the contents/file/view/edit/nbconvert handlers.
• Modify/customize/restrict the shutdown/sessions/config handlers (?).

These are all currently hard-coded in the web-app. I'm not sure what the best way to configure these would be, but the pattern from extra_services seems like a good one (maybe default_services?).

see jupyter/notebook#4613

maybe Jupyter-Server could be a place to experiment solutions for cheap ?

Opening this issue to track the porting of relevant Notebook PRs to Jupyter Server.

List to Port:

• jupyter/notebook#3664
• jupyter/notebook#3759
• jupyter/notebook#3778
• jupyter/notebook#3789
• jupyter/notebook#3799
• jupyter/notebook#3806
• jupyter/notebook#3809
• jupyter/notebook#3829
• jupyter/notebook#3879
• jupyter/notebook#3883
• jupyter/notebook#3886
• jupyter/notebook#3907
• jupyter/notebook#4034
• jupyter/notebook#4036
• jupyter/notebook#4063
• jupyter/notebook#4099
• jupyter/notebook#4103
• jupyter/notebook#4112
• jupyter/notebook#4139
• jupyter/notebook#4161 (via #92)
• jupyter/notebook#4210
• jupyter/notebook#4219
• jupyter/notebook#4235
• jupyter/notebook#4260
• jupyter/notebook#4284
• jupyter/notebook#4328
• jupyter/notebook#4355
• jupyter/notebook#4376
• jupyter/notebook#4392
• jupyter/notebook#4412
• jupyter/notebook#4426
• jupyter/notebook#4431 (via #92)
• jupyter/notebook#4449
• jupyter/notebook#4453
• jupyter/notebook#4468
• jupyter/notebook#4519
• jupyter/notebook#4528
• jupyter/notebook#4531
• jupyter/notebook#4576 (via #92)
• jupyter/notebook#4618
• jupyter/notebook#4672
• jupyter/notebook#4674
• jupyter/notebook#4701 (via #92)
• jupyter/notebook#4724 (via #92)
• jupyter/notebook#4725 (via #92)
• jupyter/notebook#4756
• jupyter/notebook#4777 (via #92)
• jupyter/notebook#4891

My strategy is to just manually move PRs that affect files in the Server. Is that the best strategy here? @SylvainCorlay @blink1073

When running behind a load balancer/proxy, I get this error:
Blocking Cross Origin WebSocket Attempt
because the Host header doesn't match the Origin header (from here). However, this is supposed to be the case, as the "real" host will be in Forwarded or X-Forwarded-Host.

Would it make sense to check if these are set, and if so, to prefer them to the Host header when comparing to Origin?

I saw that https://github.com/jupyter/jupyter_server/blob/master/jupyter_server/services/contents/handlers.py#L319

it handle ambiguous path when I create directory named "checkpoints" or "trust" , since the "checkpoints" directory is familiar name in Tenrsorflow.

Have some plan to separate them ?

I'm not 100% sure if I post on the right repo.

I have a ipynb file calling Julia 1.0.x code. I wanted to use my unregistered package so downloading from my GitHub repo with the following code (I'm a newbie with Julia, so yet not sure of the correct code):

using Pkg; Pkg.add(PackageSpec(url="https://github.com/xxx/yyy.jl"));

On my GitHub page, on https://nbviewer.jupyter.org and on my own jupyter-lab I have the same error (while working perfectly on my Julia 1.0.x):

error compiling #add_or_develop#13: error compiling shred!: error compiling #26: error compiling with: error compiling #27: could not load library "libgit2"
/usr/lib/x86_64-linux-gnu/libmbedx509.so.0: undefined symbol: mbedtls_mutex_unlock

Stacktrace:
 [1] #add_or_develop at ./none:0 [inlined]
 [2] #add_or_develop#12 at /build/julia-wJr69F/julia-1.0.3+dfsg/usr/share/julia/stdlib/v1.0/Pkg/src/API.jl:29 [inlined]
 [3] #add_or_develop at ./none:0 [inlined]
 [4] #add_or_develop#10 at /build/julia-wJr69F/julia-1.0.3+dfsg/usr/share/julia/stdlib/v1.0/Pkg/src/API.jl:27 [inlined]
 [5] #add_or_develop at ./none:0 [inlined]
 [6] #add#18 at /build/julia-wJr69F/julia-1.0.3+dfsg/usr/share/julia/stdlib/v1.0/Pkg/src/API.jl:69 [inlined]
 [7] add(::Pkg.Types.PackageSpec) at /build/julia-wJr69F/julia-1.0.3+dfsg/usr/share/julia/stdlib/v1.0/Pkg/src/API.jl:69
 [8] top-level scope at In[1]:1

It looks like you should include a Julia compiled against the static lib libgit2 but against a shared lib

Has any docs to know how to use the server? README's link was broken.

license in copying.md should be updated and renamed

See PR #5051 in the JupyterLab repo.

Files can be opened on Windows using absolute paths. This shouldn't be allowed. (It doesn't work on linux).

We should check that the jupyter server (and the classic notebook server) is not allowing absolute paths on Windows.

Steps to reproduce:

1. Put a mp4 file, like file.mp4, on notebook folder
2. Run jupyter
3. Open your file.mp4 on /files/file.mp4.

Expected:
You should be able to easily move current playing position to some other place.

Actual:
You can't move current playing position.

This feature is already can be provided by using this part of StaticFileHandler but since FilesHandler of Jupyter Server is using some custom logic, HTTP 206 serving is not working and partial downloading is not possible.

The fix may consists some inheriting just like what AuthenticatedFileHandler do, as return web.StaticFileHandler.get(self, path) can delegate the work to Tornado's StaticFileHandler, or copying that part of implementation to this project.

I wish you could replace FilesHandler with AuthenticatedFileHandler but I guess that wouldn't be possible due to content_managers?

The user token generation/validation is done in various methods of https://github.com/jupyter/jupyter_server/blob/master/jupyter_server/auth/login.py

There is no way for an jupyter admin to change that and use for example an external token provider such as e.g. an OpenID Connect provider.

Is there an interest for such usecase, and how could this be implemented in a pluggable way?

We need to backpart https://github.com/jupyter/notebook/pull/4449/files

Jupyter notebook and jupyter_server both provide a jupyter-bundlerextension executable. This creates a conflict between the two packages.

This repo needs documentation for what it does and how to use it. Right now, it's not clear what starting jupyter-server gets you, or how to write an extension (e.g. turn the notebook package into an extension of this repo)

Hello everyone. Do you guys see any blocker for a 0.0.6 release of jupyter_server?

That would allow us to move forward with

• ExtensionApps
• The ongoing debugger work
• Some other small fixes that were introduced since 0.0.5

cc @vidartf @Zsailer @epifanio @rolweber

When used on the top of the classic notebook server, the JupyterLab LabApp inherits from NotebookApp and therefore inherits all of the configuration traits of the classic notbeook, even those that may not be relevant to JupyterLab.

When using jupyter_server, both NotebookApp and LabApp inherit from a common ServerApp. Launching jupyter lab creates a lab app, and the classic notebook extensions does not see its configuration initialized.

How can we disentangle the server extensions and set options for all of then?

cc @minrk @jasongrout

I wrote my own function for calculating mean squared error between values of two arrays and it returned wrong values for one particular input (see code below) only . I also tried the same input with built-in MSE function from sklearn.metrics module and the output was the same. It only returns wrong values in Jupyter and works fine in other shells.

Here's the python code and the value 2.99 in the third print line is the one causing the problem:

import numpy as np
from sklearn.metrics import mean_squared_error

print(mean_squared_error(np.array([1, 2, 3]), np.array([0.9, 1.9, 2.9])))
print(mean_squared_error(np.array([1, 2, 3]), np.array([0.98, 1.98, 2.8])))
print(mean_squared_error(np.array([1, 2, 3]), np.array([0.99, 1.99, 2.99])))

I've been coming across various places where jupyter_server diverges from notebook. I'm using this issue to track these differences. This will be turned into documentation in the future to help users migrate in places where we cannot add shims.

• ConfigManager changed its config path from "nbconfig" to "serverconfig". (code)
  • Follow up question: should this be hardcoded into the config manager?

We should release a new version that includes the security fix from PRs #77 and #88.

After a conversation with @blink1073 this morning,

I looked at traits in NotebookApp that other extensions might depend on. If we turn the NotebookApp into server extension, such traits/configurations won't be seen by other server extensions. This would break those extensions.

Here is the full list:

extra_nbextensions_path
enable_mathjax
max_body_size
max_buffer_size
webapp_settings
server_extensions
nbserver_extensions
notebook_dir
mathjax_url
get_secure_cookie_kwargs
base_project_url
mathjax_config
ignore_minified_js

The only trait that causes trouble in JupyterLab is notebook_dir. Jupyter server renames this trait to root_dir.

We may want to add notebook_dir to jupyter_server with a deprecation warning.

I'm trying to build a custom server app by inheriting from ServerApp. This custom app will include some other JupyterApps as subcommands. So far so good. Now, I want to add a subcommand imported from another project (JupyterLab). Here, things break during import, since jupyterlab imports jupyterlab_server which import notebook. This causes a conflict in the metrics:

Traceback (most recent call last):
[...]
  File "[...]\app.py", line 6, in <module>
    from jupyterlab import labapp
  File "[...]\jupyterlab\labapp.py", line 14, in <module>
    from jupyterlab_server import slugify, WORKSPACE_EXTENSION
  File "[...]\jupyterlab_server\__init__.py", line 4, in <module>
    from .app import LabServerApp
  File "[...]\jupyterlab_server\app.py", line 9, in <module>
    from .server import ServerApp
  File "[...]\jupyterlab_server\server.py", line 20, in <module>
    from notebook.notebookapp import aliases, flags, NotebookApp as ServerApp
  File "[...]\notebook\notebookapp.py", line 80, in <module>
    from .log import log_request
  File "[...]\notebook\log.py", line 10, in <module>
    from .metrics import prometheus_log_method
  File "[...]\notebook\metrics.py", line 14, in <module>
    ['method', 'handler', 'status_code'],
  File "[...]\prometheus_client\metrics.py", line 494, in __init__
    labelvalues=labelvalues,
  File "[...]\prometheus_client\metrics.py", line 103, in __init__
    registry.register(self)
  File "[...]\prometheus_client\registry.py", line 29, in register
    duplicates))
ValueError: Duplicated timeseries in CollectorRegistry: {'http_request_duration_seconds_sum', 'http_request_duration_seconds_created', 'http_request_duration_seconds_bucket', 'http_request_duration_seconds_count'}

If you ever end up with a URL that hits the trailing slash rule, and you have query arguments, you end up in a redirect loop.

The current path rule (path rules are applied to the path, i.e. without query args):

https://github.com/jupyter/jupyter_server/blob/9f3b26d153ac0582df0f6422abd33346d418effe/jupyter_server/base/handlers.py#L871

The current redirect logic (request.uri includes query args at the end):

https://github.com/jupyter/jupyter_server/blob/9f3b26d153ac0582df0f6422abd33346d418effe/jupyter_server/base/handlers.py#L786

Proposed resolution: When redirecting, ensure that the rstrip is ran on the path portion, before reconstructing the full URI.

This idea was raised in jupyterlab/jupyterlab#6451.

Problem: the classic notebook can configure both the server and the frontend from the CLI. This is helpful for scenarios where you are deploying jupyter servers from scripts. JupyterHub, for example, launches single-user server using the CLI entry points. Those running notebook or lab as server extensions cannot configure those frontends from the jupyter server CLI.

Soluton: I propose we add functionality to Jupyter Server that enables the jupyter server CLI to configure extensions (assuming they are configurable objects). This would require ServerApp to look for enabled, configurable extensions and dynamically add those classes to the ServerApp's classes trait.

We need this feature first before implementing it in JLab/Notebook. See jupyter/notebook#4781 for context.

Some of our services are split into two directories; one that includes JupyterHandlers and another (that lives under services submodule) that includes APIHandlers + managers.

I think it would make the most sense to collapse these services into single directories with handlers.py, api_handlers.py, and manager.py submodules. This would make it easier to implement #31, where every service follows a standard structure and can be easily loaded through a services trait.

There are various handlers that server basic templates (i.e. login/logout handlers). While Jupyter server doesn't seek to provide a frontend, hitting these handlers results in 500 errors.

I think we should port basic jinja templates for these handlers that can be overridden or inherited by extensions/subclasses.

Right now, services and their corresponding managers are hardcoded as traits to the ServerApp. And the handlers are hardcoded into the web app.

I think we should make which services are loaded/registered a configurable option.

This would allow other applications to subclass the ServerApp and customize the services it uses. I mentioned this briefly in issue #29.

1. Install jupyter_server
2. Run jupyter server
3. It opens a URL that's /?token=XXX in browser
4. This URL infinitely redirects to itself, never shows anything

If you manually have it open something like /voila?token=XXX it works fine. Default behavior should be better.

A new draft of the Jupyter Server enhancement proposal was posted here.

Anyone who is interested, check it out. Feedback welcome!

Hey guys, I am experiencing very weird issue with jupyter, that I guess is a regression, here is its steps to reproduce:

Create a notebook, put this code on first cell to create test images:

from PIL import Image
from PIL import ImageDraw

for i in range(1, 6):
    img = Image.new('RGBA', (10, 10), 255)
    draw = ImageDraw.Draw(img)
    draw.text((0, 0), str(i), fill="black")
    img.save(str(i) + '.png')

Put this on the next cell as markdown:

<img src="1.png" width="30">
<img src="2.png" width="30">
<img src="3.png" width="30">
<img src="4.png" width="30">
<img src="5.png" width="30">
<img src="6.png" width="30">

Actual:
I see such result this, differently every time:

Expected:
To images loaded correctly.

My system:
jupyter --version: 4.3.0
macOS High Sierra

I can reproduce this very consistently on my setup, Is jupyter server somehow fails on serving concurrent requests or something else is wrong?

I've configured a public server as specified in https://jupyter-notebook.readthedocs.io/en/stable/public_server.html, and I use letsencrypt to generate a key. However, when running the server, it prompts that the private key is not found (understandable, since it requires sudo access). Running jupyter with sudo seems to be discouraged.

If I grant access to my private key to my user, jupyter runs fine, but I can easily view my private key through the command prompt. I understand this is only intended to one user, but having the private key with only the protection of jupyter authentication seems too high a risk. I'm not sure if I'm missing something... Any help would be appreciated.

This could be in a classic_notebook repository on the jupyter organization, or as a PR on the actual classic notebook (with a greater risk of not being merged).

The classic_notebook extension could be a way to enable the classic notebook button with JupyterLab when it is installed on the top of the jupyter_server.

Python 2.7 reaches its end of life at new year's eve.
Should we still bother with it in jupyter_server until then?

I'm in favor of dropping it rather sooner than later. Should be just some metadata and CI configuration that needs to be updated.

Hi,

Got myself to try some ML lessons (http://course.fast.ai/index.html) and I thought it would be handy to do the setup (http://course.fast.ai/lessons/aws.html) of jupyter not on aws but on my windows10 linux subsystem as part of anaconda2 distribution.

After I've opened a new python [conda root] notebook, kernel dies. See the attached screenshot.

Using Anaconda2-4.2.0-Linux-x86_64.sh

Hello @SylvainCorlay and @blink1073!

I talked with @ellisonbg this morning about the jupyter_server project. I'm planning to devote full-time sprinting on this project over the next few weeks. Is there a time you both would be available to video chat and discuss the project? Also, is there a different medium to discuss the project (gitter, slack, etc?)

Hi,

We are running the Jupyter server, had a reboot and the service is no longer running.

Getting the following error:

[I 2018-08-10 11:31:11.380 JupyterHub app:622] Loading cookie_secret from /jupyterhub_cookie_secret
[D 2018-08-10 11:31:11.380 JupyterHub app:694] Connecting to db: sqlite:///jupyterhub.sqlite
[E 2018-08-10 11:31:11.389 JupyterHub app:1296]
    Traceback (most recent call last):
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/jupyterhub/app.py", line 1293, in launch_instance_async
        yield self.initialize(argv)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/jupyterhub/app.py", line 1099, in initialize
        self.init_db()
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/jupyterhub/app.py", line 700, in init_db
        **self.db_kwargs
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/jupyterhub/orm.py", line 402, in new_session_factory
        Base.metadata.create_all(engine)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/sql/schema.py", line 3748, in create_all
        tables=tables)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/engine/base.py", line 1856, in _run_visitor
        conn._run_visitor(visitorcallable, element, **kwargs)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/engine/base.py", line 1481, in _run_visitor
        **kwargs).traverse_single(element)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/sql/visitors.py", line 121, in traverse_single
        return meth(obj, **kw)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/sql/ddl.py", line 709, in visit_metadata
        [t for t in tables if self._can_create_table(t)])
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/sql/ddl.py", line 709, in <listcomp>
        [t for t in tables if self._can_create_table(t)])
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/sql/ddl.py", line 686, in _can_create_table
        table.name, schema=table.schema)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/dialects/sqlite/base.py", line 1139, in has_table
        connection, "table_info", table_name, schema=schema)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/dialects/sqlite/base.py", line 1480, in _get_table_pragma
        cursor = connection.execute(statement)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/engine/base.py", line 906, in execute
        return self._execute_text(object, multiparams, params)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/engine/base.py", line 1054, in _execute_text
        statement, parameters
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/engine/base.py", line 1146, in _execute_context
        context)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/engine/base.py", line 1341, in _handle_dbapi_exception
        exc_info
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/util/compat.py", line 202, in raise_from_cause
        reraise(type(exception), exception, tb=exc_tb, cause=cause)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/util/compat.py", line 185, in reraise
        raise value.with_traceback(tb)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/engine/base.py", line 1139, in _execute_context
        context)
      File "/opt/.virtualenvs/jupyter/lib/python3.4/site-packages/sqlalchemy/engine/default.py", line 450, in do_execute
        cursor.execute(statement, parameters)
    sqlalchemy.exc.DatabaseError: (sqlite3.DatabaseError) database disk image is malformed [SQL: 'PRAGMA table_info("hubs")']
    
[D 2018-08-10 11:31:11.392 JupyterHub application:642] Exiting application: jupyterhub

Can you please assist us with this?

Best Regards
Eddy

I was looking at the extension app mechanism, and I have some thoughts for the voila use case.

• Ideally, I would like to have the voila command line to become an alias on jupyter voila. A byproduct will be that we should be able to drop the VoilaConfiguration mixin used by both the tornado application and the server extension...

• Now, one thing about the voila command line that we would lose, is the guarantee that other server extensions are not enabled. The reason is that we generally want voila to be used to produce standalone web app that don't allow arbitrary code execution. Enabling the lab server extension defeats the purpose, because it would provide a means to access and execute code...

• So an idea would be to have a --standalone option that only enables the selected server extension and not the other ones. Then voila would make use of jupyter voila --standalone...

cc @rolweber @Zsailer @epifanio

I want to connect remote jupyter_server by python codes rather than in a Browser
but i don't know which lib shall I use
I have checked the jupyter_client lib,but it seems that lib is not what I am looking for,maybe i didn't understand that lib well : )
Is there a python lib that I can use to connect the remote jupyter_server?
I find when it is in a Browser ,Kernel.js do the connect and communicate work
So I wonder is there a python lib can do the same work
Do I have to write a python lib to use websocket to do the same thing as the Kernel.js do or there is already one?
Thanks for your reading!!
I am waiting for answers!!!
: )

One of the goals of the standalone jupyters_server is to enable use cases where certain messages are not allowed such as execute_requests.

The main usecase is for widgets-based applications, that should not allow arbitrary code execution.

Should there be an option for disabling execute_request globally (at least as a first iteration), or have a more complex security scenario where this would depend on who is connected.

cc @jasongrout @rgbkrk

If giving the server launch command a file path, it will try to open the browser at /notebooks/<file path>:

https://github.com/jupyter/jupyter_server/blob/4b8c9eebfcae24f4a09fcb796fbcfb1fa27a2950/jupyter_server/serverapp.py#L1580

The /notebooks part should probably be configurable (for user and/or extension apps).

If that is agreed, then comes the bike shed that is what to call the trait. A first suggestion could be file_to_run_url, but I'm happy for better suggestions.

Some time ago, @takluyver introduced a proposal for a new mechanism of kernel management. This framework essentially supplants jupyter_client, splitting it into juptyer_kernel_mgmt and jupyter_protocol leading to a better separation of functionality. I have spent some time over the past several weeks working on juptyer_kernel_mgmt and migrating Enterprise Gateway's remote kernel support into this framework as a proof of concept.

jupyter_kernel_mgmt, among other things, introduces the notion of a Kernel Provider. Kernel Providers essentially take on the responsibility of discovery, launch and lifecycle management of a kernel. With this approach, multiple third-party application Kernel Providers can co-exist within the same server. This was not possible before since there could only be one override of KernelSpecManager (for discovery) and KernelManager (for launch and lifecycle management). This is a huge win relative to jupyter-server and allowing third-party innovations!

The base implementation provides two kernel providers out of the box - the KernelSpecProvider (for kernelspec-based kernels) and the IPykernelProvider for kernels running in the typical python/conda-installed kernels.

@takluyver has also provided examples of an ssh-based and docker-based providers, while I have migrated EG's kubernetes, yarn, and docker implementations as proof of concepts.

We would likely ONLY support async kernels (work in progress) and enable the ability to use parameterized kernels (work in progress), among other things.

I would like to move forward with incorporating these changes - similar to what has been proposed in Notebook (although the plan would be that this framework only get used in jupyter_server) - but wanted to run this past the project first.

We have kept the HTML templates from the classic notebook server.

I guess that 404.html and error.html and their bases belong to the server. What about the other ones?

The terminal application in the classic notebook is a good example of a jupyter server extension.

I think we should break this logic out into a extensions submodule inside this package, add a load_jupyter_server_extension function to register the extension, and add the terminal app to the jpserver_extension list trait.

We'll need to write an application to migrate the notebook config to server config.

Users call:

$ jupyter server migrate

much like we did for the IPython/Jupyter split (jupyter migrate).

This is a bit tricky because some traits need to stay in the notebook config, while others move to the server config.

Pinging @SylvainCorlay, @blink1073 and @jasongrout.

I'm hoping this discussion will bring me up to speed on everyone's thoughts/plans, so I apologize for anything that I say that's naive 😆

Essentially, I'm asking how should applications like the class Notebook, jupyterlab, etc. interface with the server? (I realize there's a big discussion that needs to happen about how we handle configuration, especially in a backward-compatible way. For now, I'm ignoring that question and just asking what is the end goal for jupyter_server).

1. Everything is a server extension

One approach is that each application is loaded through the server extension logic.

def load_jupyter_server_extension(server_app): 
    # 1. Pass application settings to Jupyter WebApp (this requires new logic)
    # 2. Add handlers to Jupyter WebApp

Each extension is added to the server extension list in the server config. The server has one entry point jupyter server (though we'd need to add shims for backward compatibility). The server+webapp launch and load the server extensions (i.e. the classic notebook, lab, etc.). Each extension loads it's specific configuration and these additional settings are added after the server and webapp are created. I'm not sure how we'd handle extension configurations from the CLI (will likely new traitlets logic...).

In this scenario, the jupyter ServerApp and WebApp are a general applications that expose API's to the backend jupyter services. Jupyter lab and the notebook are (first class) external applications that interface with server. As an example, here is a branch of the classic notebook that uses the current server extension logic to load the notebook.

2. External apps subclass the server+webapp

Every external application subclass the jupyter ServerApp and WebApp and add/update application specific configurations to these classes (I think this is what jupyterlab_server does?).

In this case, each application comes with their own server, webapp, configuration template, and entry-point.

Is there a way to import notebook server into another module and start programmatically (as opposed to calling jupyter notebook with subprocess or something)?

I probably overlooked something, but I didn't see notebook exported in __init__.py, or any other avenue.

Thanks.

If a kernel handler gets a msg that is not allowed (for instance voila gets an execute_request) there is no reply. For testing or UI it makes sense to get a reply.

Is there an example that I could use on how such a reply should look like? I guess this also means the protocol description should be updated?

Moved over from jupyterlab/jupyterlab#4777

TL;DR: Currently the only indication you get that something is wrong is repeated messages Adapting to protocol v5.1 for kernel in the logs. At a minimum it would be good to log a warning that the websocket was disconnected and if at all possible to log any other relevant debug information to help track down the issue when it occurs.