instead of the monkeypatch we did to keep the backport patch small
requiring tornado 5 simplifies things a ton because tornado.concurrent.Future is asyncio.Future
tornado gen.maybe_future is deprecated in >= 5.0 and doesn't accept asyncio coroutine objects or awaitables in general
causing failures with tornado 6 on asyncio
monkeypatch gen.maybe_future for easier backport to 5.x
later, we can update to use our maybe_future throughout
it doesn’t matter if the close was clean or not,
we should still handle the close event.
we set a different onclose handler prior to the client requesting close,
which is likely what the old wasClean checks were for
Converted `MappingKernelManager.restart_kernel` to a coroutine so that
projects that take advantage of async kernel startup can also realize
appropriate behavior relative to restarts.
Eliminated the Kernel and Kernelspec handlers. The Websocket (ZMQ)
channels handler still remains. This required turning a few methods
into coroutines in the Notebook server.
Renamed the Gateway config object to GatewayClient in case we want
to extend NB server (probably jupyter_server at that point) with
Gateway server functionality - so an NB server could be a Gateway
client or a server depending on launch settings.
Add code to _replace_ the channels handler rather than rely on position
within the handlers lists.
Updated mock-gateway to return the appropriate form of results.
Updated the session manager tests to use a sync ioloop to call the
now async manager methods.
Created a singleton class `Gateway` to store all configuration options
for a Gateway. This class also holds some help methods to make it easier
to use the options and determine if the gateway option is enabled.
Updated the NotebookTestBase class to allow for subclasses to infuence
the patched environment as well as command line options via argv.
Added a test to ensure various gateway configuration items can be
set via the environment or command-line.
This change alleviates a significant pain-point for consumers of Jupyter
Kernel and Enterprise Gateway projects by embedding the few classes defined
in the NB2KG server extension directly into the Notebook server. All code
resides in a separate gateway directory and the 'extension' is enabled
via a new configuration option `--gateway-url`.
Renamed classes from those used in standard NB2KG code so that Notebook
servers using the existing NB2KG extension will still work.
Added test_gateway.py to exercise overridden methods. It does this by
mocking the call that issues requests to the gateway server.
Updated the _Running a notebook server_ topic to include a description
of this feature.
- separates nbserver_extension config loading into new
init_server_extension_config method
- adds init_server_extension_config to the initialize funciton before
the init_webapp call
- adds nbserver_extension configuration found in config.d files (by the
BaseJSONConfigLoader) to both the underlying NotebookApp config object
and the self.nbserver_extensions value
- makes self.nbserver_extensions the canonical location for identifying
all nbserver_extensions rather than temporary extensions variable
Min RK
Carol Willing
Kevin Bates
Frédéric Chapoton
Thomas Kluyver
Thomas Kluyver
M Pacer
Roman Kornev
Gestalt LUR
edubov
Maxime Mouchet
__kai__
Stephen Ward