diff --git a/.gitignore b/.gitignore index bc4d808..f063392 100644 --- a/.gitignore +++ b/.gitignore @@ -17,3 +17,4 @@ __pycache__ .cache .pytest_cache absolute.json +.idea diff --git a/docs/Makefile b/docs/Makefile index 1117413..1e36a74 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -87,9 +87,9 @@ qthelp: @echo @echo "Build finished; now you can run "qcollectiongenerator" with the" \ ".qhcp project file in $(BUILDDIR)/qthelp, like this:" - @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/jupyter_client.qhcp" + @echo "# qcollectiongenerator $(BUILDDIR)/qthelp/jupyter_protocol.qhcp" @echo "To view the help file:" - @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/jupyter_client.qhc" + @echo "# assistant -collectionFile $(BUILDDIR)/qthelp/jupyter_protocol.qhc" applehelp: $(SPHINXBUILD) -b applehelp $(ALLSPHINXOPTS) $(BUILDDIR)/applehelp @@ -104,8 +104,8 @@ devhelp: @echo @echo "Build finished." @echo "To view the help file:" - @echo "# mkdir -p $$HOME/.local/share/devhelp/jupyter_client" - @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/jupyter_client" + @echo "# mkdir -p $$HOME/.local/share/devhelp/jupyter_protocol" + @echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/jupyter_protocol" @echo "# devhelp" epub: diff --git a/docs/api/client.rst b/docs/api/client.rst deleted file mode 100644 index e7e5478..0000000 --- a/docs/api/client.rst +++ /dev/null @@ -1,43 +0,0 @@ -client - communicating with kernels -=================================== - -.. currentmodule:: jupyter_client - -.. seealso:: - - :doc:`/messaging` - The Jupyter messaging specification - -.. autoclass:: KernelClient - - .. automethod:: load_connection_file - - .. automethod:: load_connection_info - - .. automethod:: start_channels - - .. automethod:: execute - - .. automethod:: complete - - .. automethod:: inspect - - .. automethod:: history - - .. automethod:: comm_info - - .. automethod:: is_complete - - .. automethod:: input - - .. automethod:: shutdown - - .. automethod:: get_shell_msg - - .. automethod:: get_iopub_msg - - .. automethod:: get_stdin_msg - -.. autoclass:: BlockingKernelClient - - .. automethod:: execute_interactive diff --git a/docs/api/index.rst b/docs/api/index.rst deleted file mode 100644 index 125646f..0000000 --- a/docs/api/index.rst +++ /dev/null @@ -1,12 +0,0 @@ -jupyter_client API -================== - -.. module:: jupyter_client - -.. toctree:: - :maxdepth: 2 - :caption: Jupyter API - - kernelspec - manager - client diff --git a/docs/api/kernelspec.rst b/docs/api/kernelspec.rst deleted file mode 100644 index 6bccc08..0000000 --- a/docs/api/kernelspec.rst +++ /dev/null @@ -1,66 +0,0 @@ -kernelspec - discovering kernels -================================ - -.. seealso:: :ref:`kernelspecs` - -.. module:: jupyter_client.kernelspec - -.. class:: KernelSpec - - .. attribute:: argv - - The list of arguments to start this kernel. - - .. attribute:: env - - A dictionary of extra environment variables to declare, in addition to - the current environment variables, when launching this kernel. - - .. attribute:: display_name - - The name to display for this kernel in UI. - - .. attribute:: language - - The name of the language the kernel implements, to help with picking - appropriate kernels when loading notebooks. - - .. attribute:: metadata - - Additional kernel-specific metadata; clients can use this as needed, - for instance to aid in kernel selection and filtering. - - Metadata added here should be namespaced for the tool reading and - writing that metadata. Concretely, if you're adding a new field called - :code:`supported_versions` which your tool recognizes, then you should - add it as :code:`"mytool": {"supported_versions": [1, 2]}`, **not** as a - top-level field called :code:`supported_versions`. - - .. attribute:: resource_dir - - The path to the directory with this kernel's resources, such as icons. - - .. automethod:: to_json - -.. class:: KernelSpecManager - - .. automethod:: find_kernel_specs - - .. automethod:: get_all_specs - - .. automethod:: get_kernel_spec - - .. automethod:: install_kernel_spec - -.. exception:: NoSuchKernel - - .. attribute:: name - - The name of the kernel which was requested. - -.. function:: find_kernel_specs - get_kernel_spec(kernel_name) - install_kernel_spec(source_dir, kernel_name=None, user=False, replace=False) - - These methods from :class:`KernelSpecManager` are exposed as functions on the - module as well; they will use all the default settings. diff --git a/docs/api/manager.rst b/docs/api/manager.rst deleted file mode 100644 index f1d9913..0000000 --- a/docs/api/manager.rst +++ /dev/null @@ -1,58 +0,0 @@ -manager - starting, stopping, signalling -======================================== - -.. currentmodule:: jupyter_client - -.. autoclass:: KernelManager - - .. attribute:: kernel_name - - The name of the kernel to launch (see :ref:`kernelspecs`). - - .. automethod:: start_kernel - - .. attribute:: kernel - - Once the kernel has been started, this is the :class:`subprocess.Popen` - class for the kernel process. - - .. automethod:: is_alive - - .. automethod:: interrupt_kernel - - .. automethod:: signal_kernel - - .. automethod:: client - - For the client API, see :mod:`jupyter_client.client`. - - .. automethod:: blocking_client - - .. automethod:: shutdown_kernel - - .. automethod:: restart_kernel - -multikernelmanager - controlling multiple kernels -------------------------------------------------- - -.. autoclass:: MultiKernelManager - - This exposes the same methods as :class:`~jupyter_client.manager.KernelManager`, - but their first parameter is a kernel ID, a string identifying the kernel - instance. Typically these are UUIDs picked by :meth:`start_kernel` - - .. automethod:: start_kernel - - .. automethod:: list_kernel_ids - - .. automethod:: get_kernel - - .. automethod:: remove_kernel - - .. automethod:: shutdown_all - -Utility functions ------------------ - -.. autofunction:: run_kernel - diff --git a/docs/changelog.rst b/docs/changelog.rst index 35e21b5..a932ea6 100644 --- a/docs/changelog.rst +++ b/docs/changelog.rst @@ -1,155 +1,14 @@ .. _changelog: -========================= -Changes in Jupyter Client -========================= +=========================== +Changes in Jupyter Protocol +=========================== -5.1 -=== - -`5.1 on GitHub `__ - -- Define Jupyter protocol version 5.2, - resolving ambiguity of ``cursor_pos`` field in the presence - of unicode surrogate pairs. - - .. seealso:: - - :ref:`cursor_pos_unicode_note` - -- Add :meth:`Session.clone` for making a copy of a Session object - without sharing the digest history. - Reusing a single Session object to connect multiple sockets - to the same IOPub peer can cause digest collisions. -- Avoid global references preventing garbage collection of background threads. - - -5.0 -=== - -5.0.1 ------ - -`5.0.1 on GitHub `__ - -- Update internal protocol version number to 5.1, - which should have been done in 5.0.0. - -5.0.0 ------ - -`5.0.0 on GitHub `__ - -New features: - -- Implement Jupyter protocol version 5.1. -- Introduce :command:`jupyter run` command for running scripts with a kernel, for instance:: - - jupyter run --kernel python3 myscript.py - -- New method :meth:`.BlockingKernelClient.execute_interactive` - for running code and capturing or redisplaying its output. -- New ``KernelManager.shutdown_wait_time`` configurable for adjusting the time - for a kernel manager to wait after politely requesting shutdown - before it resorts to forceful termination. - -Fixes: - -- Set sticky bit on connection-file directory to avoid getting cleaned up. -- :func:`jupyter_client.launcher.launch_kernel` passes through additional options to the underlying Popen, - matching :meth:`KernelManager.start_kernel`. -- Check types of ``buffers`` argument in :meth:`.Session.send`, - so that TypeErrors are raised immediately, - rather than in the eventloop. - -Changes: - -- In kernelspecs, if the executable is the string ``python`` (as opposed to an absolute path), - ``sys.executable`` will be used rather than resolving ``python`` on PATH. - This should enable Python-based kernels to install kernelspecs as part of wheels. -- kernelspec names are now validated. - They should only include ascii letters and numbers, plus period, hyphen, and underscore. - -Backward-incompatible changes: - -- :py:class:`.datetime` objects returned in parsed messages are now always timezone-aware. - Timestamps in messages without timezone info are interpreted as the local timezone, - as this was the behavior in earlier versions. - - -4.4 -=== - -4.4.0 ------ - -`4.4 on GitHub `__ - -- Add :meth:`.KernelClient.load_connection_info` on KernelClient, etc. for loading connection info - directly from a dict, not just from files. -- Include parent headers when adapting messages from older protocol implementations - (treats parent headers the same as headers). -- Compatibility fixes in tests for recent changes in ipykernel. - -4.3 -=== - -4.3.0 ------ - -`4.3 on GitHub `__ - -- Adds ``--sys-prefix`` argument to :command:`jupyter kernelspec install`, - for better symmetry with :command:`jupyter nbextension install`, etc. - -4.2 -=== - -4.2.2 ------ - -`4.2.2 on GitHub `__ - -- Another fix for the :func:`start_new_kernel` issue in 4.2.1 affecting slow-starting kernels. - - -4.2.1 +0.1.0 ----- -`4.2.1 on GitHub `__ - -- Fix regression in 4.2 causing :func:`start_new_kernel` - to fail while waiting for kernels to become available. - - -4.2.0 ------ - -`4.2.0 on GitHub `__ - -- added :command:`jupyter kernelspec remove` for removing kernelspecs -- allow specifying the environment for kernel processes via the ``env`` argument -- added ``name`` field to connection files identifying the kernelspec name, - so that consumers of connection files (alternate frontends) can identify the kernelspec in use -- added :meth:`KernelSpecManager.get_all_specs` for getting all kernelspecs more efficiently -- various improvements to error messages and documentation - -4.1 -=== - -4.1.0 ------ - -`4.1.0 on GitHub `__ - -Highlights: - -- Setuptools fixes for ``jupyter kernelspec`` -- ``jupyter kernelspec list`` includes paths -- add :meth:`KernelManager.blocking_client` -- provisional implementation of ``comm_info`` requests from upcoming 5.1 release of the protocol +- Initial experimental implementation. -4.0 -=== -The first release of Jupyter Client as its own package. +Note: Because the code in this repository originated from jupyter_client you may +also want to look at its `changelog history `_. diff --git a/docs/conf.py b/docs/conf.py index 849d7a5..168292d 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -1,8 +1,6 @@ #!/usr/bin/env python3 # -*- coding: utf-8 -*- # -# jupyter_client documentation build configuration file, created by -# sphinx-quickstart on Tue May 26 15:41:51 2015. # # This file is execfile()d with the current directory set to its # containing dir. @@ -51,7 +49,7 @@ master_doc = 'index' # General information about the project. -project = 'jupyter_client' +project = 'jupyter_protocol' copyright = '2015, Jupyter Development Team' author = 'Jupyter Development Team' @@ -61,7 +59,7 @@ # version_ns = {} here = os.path.dirname(__file__) -version_py = os.path.join(here, os.pardir, 'jupyter_client', '_version.py') +version_py = os.path.join(here, os.pardir, 'jupyter_protocol', '_version.py') with open(version_py) as f: exec(compile(f.read(), version_py, 'exec'), version_ns) @@ -211,7 +209,7 @@ #html_search_scorer = 'scorer.js' # Output file base name for HTML help builder. -htmlhelp_basename = 'jupyter_clientdoc' +htmlhelp_basename = 'jupyter_protocoldoc' # -- Options for LaTeX output --------------------------------------------- @@ -233,7 +231,7 @@ # (source start file, target name, title, # author, documentclass [howto, manual, or own class]). latex_documents = [ - (master_doc, 'jupyter_client.tex', 'jupyter\\_client Documentation', + (master_doc, 'jupyter_protocol.tex', 'jupyter\\_protocol Documentation', 'Jupyter Development Team', 'manual'), ] @@ -263,7 +261,7 @@ # One entry per manual page. List of tuples # (source start file, name, description, authors, manual section). man_pages = [ - (master_doc, 'jupyter_client', 'jupyter_client Documentation', + (master_doc, 'jupyter_protocol', 'jupyter_protocol Documentation', [author], 1) ] @@ -277,8 +275,8 @@ # (source start file, target name, title, author, # dir menu entry, description, category) texinfo_documents = [ - (master_doc, 'jupyter_client', 'jupyter_client Documentation', - author, 'jupyter_client', 'One line description of project.', + (master_doc, 'jupyter_protocol', 'jupyter_protocol Documentation', + author, 'jupyter_protocol', 'One line description of project.', 'Miscellaneous'), ] @@ -296,7 +294,8 @@ # Example configuration for intersphinx: refer to the Python standard library. -intersphinx_mapping = {'ipython': ('http://ipython.readthedocs.io/en/stable/', None)} +intersphinx_mapping = {'ipython': ('http://ipython.readthedocs.io/en/stable/', None), + 'jupyter_kernel_mgmt': ('http://jupyter-kernel-mgmt.readthedocs.io/en/latest/', None)} # Read The Docs # on_rtd is whether we are on readthedocs.org, this line of code grabbed from docs.readthedocs.org diff --git a/docs/environment.yml b/docs/environment.yml index 3690c73..9cc7cde 100644 --- a/docs/environment.yml +++ b/docs/environment.yml @@ -1,4 +1,4 @@ -name: jup_client +name: jup_protocol channels: - conda-forge dependencies: diff --git a/docs/index.rst b/docs/index.rst index 41e218c..7285e7f 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -1,15 +1,23 @@ -Jupyter Client |version| -======================== +Jupyter Protocol |version| +========================== -This package provides the Python API for starting, managing and communicating -with Jupyter kernels. +This package provides the Python API for message composition relevant to Jupyter +kernels. For information related to the launch, communication and lifecycle +management of Jupyter kernels, please refer to the `Jupyter Kernel Management +documentation `_. -.. important:: +.. .. important:: This document contains the authoritative description of the Jupyter messaging protocol. All developers are strongly encouraged to keep it updated as the implementation evolves, so that we have a single common reference for all protocol details. +.. note:: + The information contained in this documentation also resides in the + `Jupyter Client documentation `_. + The documentation will be consolidated at a future date. Please consider + the Jupyter Client documentation as the authoritative description relative + to the messaging protocol until further notice. .. toctree:: :maxdepth: 2 @@ -23,13 +31,6 @@ with Jupyter kernels. kernels wrapperkernels - kernel_providers - -.. toctree:: - :maxdepth: 2 - :caption: API - - api/index .. toctree:: :maxdepth: 2 diff --git a/docs/kernel_providers.rst b/docs/kernel_providers.rst deleted file mode 100644 index 2e1b7e2..0000000 --- a/docs/kernel_providers.rst +++ /dev/null @@ -1,156 +0,0 @@ -================ -Kernel providers -================ - -.. note:: - This is a new interface under development, and may still change. - Not all Jupyter applications use this yet. - See :ref:`kernelspecs` for the established way of discovering kernel types. - -Creating a kernel provider -========================== - -By writing a kernel provider, you can extend how Jupyter applications discover -and start kernels. For example, you could find kernels in an environment system -like conda, or kernels on remote systems which you can access. - -To write a kernel provider, subclass -:class:`jupyter_client.discovery.KernelProviderBase`, giving your provider an ID -and overriding two methods. - -.. class:: MyKernelProvider - - .. attribute:: id - - A short string identifying this provider. Cannot contain forward slash - (``/``). - - .. method:: find_kernels() - - Get the available kernel types this provider knows about. - Return an iterable of 2-tuples: (name, attributes). - *name* is a short string identifying the kernel type. - *attributes* is a dictionary with information to allow selecting a kernel. - - .. method:: make_manager(name) - - Prepare and return a :class:`~jupyter_client.KernelManager` instance - ready to start a new kernel instance of the type identified by *name*. - The input will be one of the names given by :meth:`find_kernels`. - -For example, imagine we want to tell Jupyter about kernels for a new language -called *oblong*:: - - # oblong_provider.py - from jupyter_client.discovery import KernelProviderBase - from jupyter_client import KernelManager - from shutil import which - - class OblongKernelProvider(KernelProviderBase): - id = 'oblong' - - def find_kernels(self): - if not which('oblong-kernel'): - return # Check it's available - - # Two variants - for a real kernel, these could be something like - # different conda environments. - yield 'standard', { - 'display_name': 'Oblong (standard)', - 'language': {'name': 'oblong'}, - 'argv': ['oblong-kernel'], - } - yield 'rounded', { - 'display_name': 'Oblong (rounded)', - 'language': {'name': 'oblong'}, - 'argv': ['oblong-kernel'], - } - - def make_manager(self, name): - if name == 'standard': - return KernelManager(kernel_cmd=['oblong-kernel'], - extra_env={'ROUNDED': '0'}) - elif name == 'rounded': - return KernelManager(kernel_cmd=['oblong-kernel'], - extra_env={'ROUNDED': '1'}) - else: - raise ValueError("Unknown kernel %s" % name) - -You would then register this with an *entry point*. In your ``setup.py``, put -something like this:: - - setup(... - entry_points = { - 'jupyter_client.kernel_providers' : [ - # The name before the '=' should match the id attribute - 'oblong = oblong_provider:OblongKernelProvider', - ] - }) - -Finding kernel types -==================== - -To find and start kernels in client code, use -:class:`jupyter_client.discovery.KernelFinder`. This uses multiple kernel -providers to find available kernels. Like a kernel provider, it has methods -``find_kernels`` and ``make_manager``. The kernel names it works -with have the provider ID as a prefix, e.g. ``oblong/rounded`` (from the example -above). - -:: - - from jupyter_client.discovery import KernelFinder - kf = KernelFinder.from_entrypoints() - - ## Find available kernel types - for name, attributes in kf.find_kernels(): - print(name, ':', attributes['display_name']) - # oblong/standard : Oblong (standard) - # oblong/rounded : Oblong(rounded) - # ... - - ## Start a kernel by name - manager = kf.make_manager('oblong/standard') - manager.start_kernel() - -.. module:: jupyter_client.discovery - -.. autoclass:: KernelFinder - - .. automethod:: from_entrypoints - - .. automethod:: find_kernels - - .. automethod:: make_manager - -Kernel providers included in ``jupyter_client`` -=============================================== - -``jupyter_client`` includes two kernel providers: - -.. autoclass:: KernelSpecProvider - - .. seealso:: :ref:`kernelspecs` - -.. autoclass:: IPykernelProvider - -Glossary -======== - -Kernel instance - A running kernel, a process which can accept ZMQ connections from frontends. - Its state includes a namespace and an execution counter. - -Kernel type - The software to run a kernel instance, along with the context in which a - kernel starts. One kernel type allows starting multiple, initially similar - kernel instances. For instance, one kernel type may be associated with one - conda environment containing ``ipykernel``. The same kernel software in - another environment would be a different kernel type. Another software package - for a kernel, such as ``IRkernel``, would also be a different kernel type. - -Kernel provider - A Python class to discover kernel types and allow a client to start instances - of those kernel types. For instance, one kernel provider might find conda - environments containing ``ipykernel`` and allow starting kernel instances in - these environments. diff --git a/docs/kernels.rst b/docs/kernels.rst index 5308c60..6e59f3e 100644 --- a/docs/kernels.rst +++ b/docs/kernels.rst @@ -20,6 +20,8 @@ There are two options for writing a kernel: work initially, but the people using your kernel might be more likely to contribute to it if it's in the language they know. +.. _connection_files: + Connection files ================ @@ -81,88 +83,13 @@ stdin socket to prompt the user for textual input. `simple_kernel `_ A simple example implementation of the kernel machinery in Python - .. _kernelspecs: Kernel specs ============ -A kernel identifies itself to IPython by creating a directory, the name of which -is used as an identifier for the kernel. These may be created in a number of -locations: - -+--------+--------------------------------------------+-----------------------------------+ -| | Unix | Windows | -+========+============================================+===================================+ -| System | ``/usr/share/jupyter/kernels`` | ``%PROGRAMDATA%\jupyter\kernels`` | -| | | | -| | ``/usr/local/share/jupyter/kernels`` | | -+--------+--------------------------------------------+-----------------------------------+ -| Env | ``{sys.prefix}/share/jupyter/kernels`` | -+--------+--------------------------------------------+-----------------------------------+ -| User | ``~/.local/share/jupyter/kernels`` (Linux) | ``%APPDATA%\jupyter\kernels`` | -| | | | -| | ``~/Library/Jupyter/kernels`` (Mac) | | -+--------+--------------------------------------------+-----------------------------------+ - -The user location takes priority over the system locations, and the case of the -names is ignored, so selecting kernels works the same way whether or not the -filesystem is case sensitive. -Since kernelspecs show up in URLs and other places, -a kernelspec is required to have a simple name, only containing ASCII letters, ASCII numbers, and the simple separators: ``-`` hyphen, ``.`` period, ``_`` underscore. - -Other locations may also be searched if the :envvar:`JUPYTER_PATH` environment -variable is set. - -Inside the kernel directory, three types of files are presently used: -``kernel.json``, ``kernel.js``, and logo image files. Currently, no other -files are used, but this may change in the future. - -Inside the directory, the most important file is *kernel.json*. This should be a -JSON serialised dictionary containing the following keys and values: - -- **argv**: A list of command line arguments used to start the kernel. The text - ``{connection_file}`` in any argument will be replaced with the path to the - connection file. -- **display_name**: The kernel's name as it should be displayed in the UI. - Unlike the kernel name used in the API, this can contain arbitrary unicode - characters. -- **language**: The name of the language of the kernel. - When loading notebooks, if no matching kernelspec key (may differ across machines) - is found, a kernel with a matching `language` will be used. - This allows a notebook written on any Python or Julia kernel to be properly associated - with the user's Python or Julia kernel, even if they aren't listed under the same name as the author's. -- **interrupt_mode** (optional): May be either ``signal`` or ``message`` and - specifies how a client is supposed to interrupt cell execution on this kernel, - either by sending an interrupt ``signal`` via the operating system's - signalling facilities (e.g. `SIGINT` on POSIX systems), or by sending an - ``interrupt_request`` message on the control channel (see - :ref:`msging_interrupt`). If this is not specified - the client will default to ``signal`` mode. -- **env** (optional): A dictionary of environment variables to set for the kernel. - These will be added to the current environment variables before the kernel is - started. -- **metadata** (optional): A dictionary of additional attributes about this - kernel; used by clients to aid clients in kernel selection. Metadata added - here should be namespaced for the tool reading and writing that metadata. - -For example, the kernel.json file for IPython looks like this:: - - { - "argv": ["python3", "-m", "IPython.kernel", - "-f", "{connection_file}"], - "display_name": "Python 3", - "language": "python" - } - -To see the available kernel specs, run:: - - jupyter kernelspec list - -To start the terminal console or the Qt console with a specific kernel:: - - jupyter console --kernel bash - jupyter qtconsole --kernel bash - -The notebook offers you the available kernels in a dropdown menu from the 'New' -button. +A kernel typically identifies itself to an IPython-compatible application by creating a directory, +the name of which is used as an identifier for the kernel. The contents of this directory +is what is referred to as the *kernel specfication*. For more information on kernel specs +and other ways kernels are identified, please refer to the `Jupyter Kernel Management documentation +`_. diff --git a/docs/make.bat b/docs/make.bat index 3cdae74..fad6c44 100644 --- a/docs/make.bat +++ b/docs/make.bat @@ -127,9 +127,9 @@ if "%1" == "qthelp" ( echo. echo.Build finished; now you can run "qcollectiongenerator" with the ^ .qhcp project file in %BUILDDIR%/qthelp, like this: - echo.^> qcollectiongenerator %BUILDDIR%\qthelp\jupyter_client.qhcp + echo.^> qcollectiongenerator %BUILDDIR%\qthelp\jupyter_protocol.qhcp echo.To view the help file: - echo.^> assistant -collectionFile %BUILDDIR%\qthelp\jupyter_client.ghc + echo.^> assistant -collectionFile %BUILDDIR%\qthelp\jupyter_protocol.ghc goto end ) diff --git a/docs/messaging.rst b/docs/messaging.rst index 7c533a7..7caff7b 100644 --- a/docs/messaging.rst +++ b/docs/messaging.rst @@ -25,7 +25,7 @@ The current version of the specification is 5.3. .. note:: *New in* and *Changed in* messages in this document refer to versions of the - **Jupyter message specification**, not versions of :mod:`jupyter_client`. + **Jupyter message specification**, not versions of :mod:`jupyter_protocol`. Introduction ============ @@ -163,13 +163,13 @@ The Wire Protocol This message format exists at a high level, but does not describe the actual *implementation* at the wire level in zeromq. -The canonical implementation of the message spec is our :class:`~jupyter_client.session.Session` class. +The canonical implementation of the message spec is our :class:`~jupyter_protocol.session.Session` class. .. note:: This section should only be relevant to non-Python consumers of the protocol. Python consumers should simply import and the use implementation of the wire - protocol in :class:`jupyter_client.session.Session`. + protocol in :class:`jupyter_protocol.session.Session`. Every message is serialized to a sequence of at least six blobs of bytes: diff --git a/docs/wrapperkernels.rst b/docs/wrapperkernels.rst index bc9a8a5..94c76c5 100644 --- a/docs/wrapperkernels.rst +++ b/docs/wrapperkernels.rst @@ -69,7 +69,7 @@ To launch your kernel, add this at the end of your module:: from ipykernel.kernelapp import IPKernelApp IPKernelApp.launch_instance(kernel_class=MyKernel) -Now create a `JSON kernel spec file `_ and install it using ``jupyter kernelspec install ``. Place your kernel module anywhere Python can import it (try current directory for testing). Finally, you can run your kernel using ``jupyter console --kernel ``. Note that ```` in the below example is ``echo``. +Now create a `JSON kernel spec file `_ and install it using ``jupyter kernelspec install ``. Place your kernel module anywhere Python can import it (try current directory for testing). Finally, you can run your kernel using ``jupyter console --kernel ``. Note that ```` in the below example is ``echo``. Example -------