Hello community,
here is the log from the commit of package python3-jupyter_client for
openSUSE:Factory checked in at 2016-10-28 10:45:06
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/python3-jupyter_client (Old)
and /work/SRC/openSUSE:Factory/.python3-jupyter_client.new (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "python3-jupyter_client"
Changes:
--------
---
/work/SRC/openSUSE:Factory/python3-jupyter_client/python3-jupyter_client-doc.changes
2016-08-05 18:16:13.000000000 +0200
+++
/work/SRC/openSUSE:Factory/.python3-jupyter_client.new/python3-jupyter_client-doc.changes
2016-10-28 10:45:07.000000000 +0200
@@ -1,0 +2,11 @@
+Sun Oct 2 17:13:10 UTC 2016 - [email protected]
+
+- update to version 4.4.0:
+ * 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.
+
+-------------------------------------------------------------------
python3-jupyter_client.changes: same change
Old:
----
jupyter_client-4.3.0.tar.gz
New:
----
jupyter_client-4.4.0.tar.gz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ python3-jupyter_client-doc.spec ++++++
--- /var/tmp/diff_new_pack.qHsesQ/_old 2016-10-28 10:45:08.000000000 +0200
+++ /var/tmp/diff_new_pack.qHsesQ/_new 2016-10-28 10:45:08.000000000 +0200
@@ -24,7 +24,7 @@
%endif
Name: python3-jupyter_client-doc
-Version: 4.3.0
+Version: 4.4.0
Release: 0
Summary: Documentation for python3-jupyter_client
License: BSD-3-Clause
++++++ python3-jupyter_client.spec ++++++
--- /var/tmp/diff_new_pack.qHsesQ/_old 2016-10-28 10:45:08.000000000 +0200
+++ /var/tmp/diff_new_pack.qHsesQ/_new 2016-10-28 10:45:08.000000000 +0200
@@ -17,7 +17,7 @@
Name: python3-jupyter_client
-Version: 4.3.0
+Version: 4.4.0
Release: 0
Summary: Jupyter protocol implementation and client libraries
License: BSD-3-Clause
++++++ jupyter_client-4.3.0.tar.gz -> jupyter_client-4.4.0.tar.gz ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/jupyter_client-4.3.0/PKG-INFO
new/jupyter_client-4.4.0/PKG-INFO
--- old/jupyter_client-4.3.0/PKG-INFO 2016-06-07 10:30:20.000000000 +0200
+++ new/jupyter_client-4.4.0/PKG-INFO 2016-08-31 16:54:39.000000000 +0200
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: jupyter_client
-Version: 4.3.0
+Version: 4.4.0
Summary: Jupyter protocol implementation and client libraries
Home-page: http://jupyter.org
Author: Jupyter Development Team
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/jupyter_client-4.3.0/docs/api/client.rst
new/jupyter_client-4.4.0/docs/api/client.rst
--- old/jupyter_client-4.3.0/docs/api/client.rst 2015-09-03
11:35:14.000000000 +0200
+++ new/jupyter_client-4.4.0/docs/api/client.rst 2016-08-31
10:32:24.000000000 +0200
@@ -10,6 +10,12 @@
.. autoclass:: KernelClient
+ .. automethod:: load_connection_file
+
+ .. automethod:: load_connection_info
+
+ .. automethod:: start_channels
+
.. automethod:: execute
.. automethod:: complete
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/jupyter_client-4.3.0/docs/changelog.rst
new/jupyter_client-4.4.0/docs/changelog.rst
--- old/jupyter_client-4.3.0/docs/changelog.rst 2016-06-07 10:17:10.000000000
+0200
+++ new/jupyter_client-4.4.0/docs/changelog.rst 2016-08-31 10:32:24.000000000
+0200
@@ -4,6 +4,20 @@
Changes in Jupyter Client
=========================
+4.4
+===
+
+4.4.0
+-----
+
+`4.4 on GitHub <https://github.com/jupyter/jupyter_client/milestones/4.4>`__
+
+- 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
===
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/jupyter_client-4.3.0/docs/conf.py
new/jupyter_client-4.4.0/docs/conf.py
--- old/jupyter_client-4.3.0/docs/conf.py 2015-11-27 16:15:59.000000000
+0100
+++ new/jupyter_client-4.4.0/docs/conf.py 2016-08-31 10:32:24.000000000
+0200
@@ -119,7 +119,7 @@
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
-# html_theme = 'alabaster'
+html_theme = 'sphinx_rtd_theme'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
@@ -297,3 +297,13 @@
# Example configuration for intersphinx: refer to the Python standard library.
intersphinx_mapping = {'ipython': ('http://ipython.org/ipython-doc/dev/',
None)}
+
+# Read The Docs
+# on_rtd is whether we are on readthedocs.org, this line of code grabbed from
docs.readthedocs.org
+on_rtd = os.environ.get('READTHEDOCS', None) == 'True'
+
+if not on_rtd: # only import and set the theme if we're building docs locally
+ import sphinx_rtd_theme
+ html_theme = 'sphinx_rtd_theme'
+ html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
+# otherwise, readthedocs.org uses their theme by default, so no need to
specify it
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/jupyter_client-4.3.0/docs/environment.yml
new/jupyter_client-4.4.0/docs/environment.yml
--- old/jupyter_client-4.3.0/docs/environment.yml 1970-01-01
01:00:00.000000000 +0100
+++ new/jupyter_client-4.4.0/docs/environment.yml 2016-08-31
10:33:26.000000000 +0200
@@ -0,0 +1,10 @@
+name: jup_client
+channels:
+ - conda-forge
+dependencies:
+- pyzmq
+- python=3
+- traitlets>=4.1
+- jupyter_core
+- sphinx>=1.3.6
+- sphinx_rtd_theme
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/jupyter_client-4.3.0/docs/kernels.rst
new/jupyter_client-4.4.0/docs/kernels.rst
--- old/jupyter_client-4.3.0/docs/kernels.rst 2015-09-12 17:22:09.000000000
+0200
+++ new/jupyter_client-4.4.0/docs/kernels.rst 2016-07-13 05:12:42.000000000
+0200
@@ -112,6 +112,10 @@
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:
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/jupyter_client-4.3.0/docs/messaging.rst
new/jupyter_client-4.4.0/docs/messaging.rst
--- old/jupyter_client-4.3.0/docs/messaging.rst 2016-03-06 10:43:14.000000000
+0100
+++ new/jupyter_client-4.4.0/docs/messaging.rst 2016-08-31 16:52:45.000000000
+0200
@@ -141,6 +141,7 @@
so implementers are strongly encouraged to include it.
It will be mandatory in 5.1.
+
.. _wire_protocol:
The Wire Protocol
@@ -190,7 +191,7 @@
If authentication is disabled, this should be an empty string.
By default, the hashing function used for computing these signatures is sha256.
-.. _HMAC: http://en.wikipedia.org/wiki/HMAC
+.. _HMAC: https://en.wikipedia.org/wiki/HMAC
.. note::
@@ -256,8 +257,38 @@
extended structure.
-Messages on the shell ROUTER/DEALER sockets
-===========================================
+Messages on the shell (ROUTER/DEALER) channel
+=============================================
+
+.. _request_reply:
+
+Request-Reply
+-------------
+
+In general, the ROUTER/DEALER sockets follow a request-reply pattern:
+
+The client sends an ``<action>_request`` message (such as ``execute_request``)
on its shell (DEALER) socket.
+The kernel receives that request and immediately publishes a ``status: busy``
message on IOPub.
+The kernel then processes the request and sends the appropriate
``<action>_reply`` message, such as ``execute_reply``.
+After processing the request and publishing associated IOPub messages, if any,
+the kernel publishes a ``status: idle`` message.
+This idle status message indicates that IOPub messages associated with a given
request have all been received.
+
+All reply messages have a ``'status'`` field, which will have one of the
following values:
+
+- ``status='ok'``: The request was processed successfully, and the remaining
content of the reply is specified in the appropriate section below.
+- ``status='error'``: The request failed due to an error.
+ When status is 'error', the usual content of a successful reply should be
omitted,
+ instead the following fields should be present::
+
+ {
+ 'status' : 'error',
+ 'ename' : str, # Exception name, as a string
+ 'evalue' : str, # Exception value, as a string
+ 'traceback' : list(str), # traceback frames as strings
+ }
+
+- ``status='abort'``: the task has been aborted. In this case, no additional
fields should be present.
.. _execute:
@@ -294,8 +325,9 @@
'user_expressions' : dict,
# Some frontends do not support stdin requests.
- # If raw_input is called from code executed from such a frontend,
- # a StdinNotImplementedError will be raised.
+ # If this is true, code running in the kernel can prompt the user for input
+ # with an input_request message (see below). If it is false, the kernel
+ # should not send these messages.
'allow_stdin' : True,
# A boolean flag, which, if True, does not abort the execution queue, if
an exception is encountered.
@@ -390,26 +422,6 @@
``user_variables`` is removed, use user_expressions instead.
-When status is 'error', the following extra fields are present::
-
- {
- 'ename' : str, # Exception name, as a string
- 'evalue' : str, # Exception value, as a string
-
- # The traceback will contain a list of frames, represented each as a
- # string. For now we'll stick to the existing design of ultraTB, which
- # controls exception level of detail statefully. But eventually we'll
- # want to grow into a model where more information is collected and
- # packed into the traceback object, with clients deciding how little or
- # how much of it to unpack. But for now, let's start with a simple list
- # of strings, since that requires only minimal changes to ultratb as
- # written.
- 'traceback' : list,
- }
-
-
-When status is 'abort', there are for now no additional data fields. This
-happens when the kernel was interrupted by a signal.
Payloads (DEPRECATED)
~~~~~~~~~~~~~~~~~~~~~
@@ -691,18 +703,27 @@
'indent': str,
}
+
Connect
-------
+.. deprecated:: 5.1
+
+ connect_request/reply have not proved useful, and are considered
deprecated.
+ Kernels are not expected to implement handlers for this message.
+
When a client connects to the request/reply socket of the kernel, it can issue
a connect request to get basic information about the kernel, such as the ports
the other ZeroMQ sockets are listening on. This allows clients to only have
to know about a single port (the shell channel) to connect to a kernel.
+The ports for any additional channels the kernel is listening on should be
included in the reply.
+If any ports are omitted from the reply, this indicates that the channels are
not running.
Message type: ``connect_request``::
- content = {
- }
+ content = {}
+
+For example, a kernel with all channels running:
Message type: ``connect_reply``::
@@ -711,8 +732,10 @@
'iopub_port' : int, # The port the PUB socket is listening on.
'stdin_port' : int, # The port the stdin ROUTER socket is listening
on.
'hb_port' : int, # The port the heartbeat socket is listening on.
+ 'control_port' : int, # The port the control ROUTER socket is
listening on.
}
+
.. _msging_comm_info:
Comm info
@@ -888,8 +911,10 @@
process is unlikely to respond in any useful way to messages.
-Messages on the PUB/SUB socket
-==============================
+Messages on the IOPub (PUB/SUB) channel
+=======================================
+
+
Streams (stdout, stderr, etc)
------------------------------
@@ -1052,9 +1077,28 @@
execution_state : ('busy', 'idle', 'starting')
}
+When a kernel receives a request and begins processing it,
+the kernel shall immediately publish a status message with ``execution_state:
'busy'``.
+When that kernel has completed processing the request
+and has finished publishing associated IOPub messages, if any,
+it shall publish a status message with ``execution_state: 'idle'``.
+Thus, the outputs associated with a given execution shall generally arrive
+between the busy and idle status messages associated with a given request.
+
+.. note::
+
+ **A caveat for asynchronous output**
+
+ Asynchronous output (e.g. from background threads) may be produced after
the kernel
+ has sent the idle status message that signals the completion of the
request.
+ The handling of these out-of-order output messages is currently undefined
in this specification,
+ but the Jupyter Notebook continues to handle IOPub messages associated
with a given request
+ after the idle message has arrived,
+ as long as the output area corresponding to that request is still active.
+
.. versionchanged:: 5.0
- Busy and idle messages should be sent before/after handling every message,
+ Busy and idle messages should be sent before/after handling every request,
not just execution.
.. note::
@@ -1087,17 +1131,29 @@
The selective clearing keys are ignored in v4 and the default behavior
remains the same,
so v4 clear_output messages will be safely handled by a v4.1 frontend.
+.. _stdin_messages:
-Messages on the stdin ROUTER/DEALER sockets
-===========================================
+Messages on the stdin (ROUTER/DEALER) channel
+=============================================
-This is a socket where the request/reply pattern goes in the opposite
direction:
-from the kernel to a *single* frontend, and its purpose is to allow
-``raw_input`` and similar operations that read from ``sys.stdin`` on the kernel
-to be fulfilled by the client. The request should be made to the frontend that
-made the execution request that prompted ``raw_input`` to be called. For now we
-will keep these messages as simple as possible, since they only mean to convey
-the ``raw_input(prompt)`` call.
+With the stdin ROUTER/DEALER socket, the request/reply pattern goes in the
+opposite direction of most kernel communication.
+With the stdin socket, the kernel makes the request, and the single frontend
+provides the response.
+This pattern allows code to prompt the user for a line of input,
+which would normally be read from stdin in a terminal.
+
+Many programming languages provide a function which displays a prompt, blocks
+until the user presses return, and returns the text they typed before pressing
+return. In Python 3, this is the ``input()`` function; in R it is called
+``readline()``. If the :ref:`execute_request <execute>` message has
+``allow_stdin==True``, kernels may implement these functions so that they send
+an ``input_request`` message and wait for a corresponding ``input_reply``. The
+frontend is responsible for displaying the prompt and getting the user's input.
+
+If ``allow_stdin`` is False, the kernel must not send ``stdin_request``. The
+kernel may decide what to do instead, but it's most likely that calls to the
+'prompt for input' function should fail immediately in this case.
Message type: ``input_request``::
@@ -1114,7 +1170,10 @@
content = { 'value' : str }
-When ``password`` is True, the frontend should not echo the input as it is
entered.
+When ``password`` is True, the frontend should not show the input as it is
entered.
+Different frontends may obscure it in different ways; e.g. showing each
+character entered as the same neutral symbol, or not showing anything at all as
+the user types.
.. versionchanged:: 5.0
@@ -1130,14 +1189,10 @@
.. note::
- We do not explicitly try to forward the raw ``sys.stdin`` object, because in
- practice the kernel should behave like an interactive program. When a
- program is opened on the console, the keyboard effectively takes over the
- ``stdin`` file descriptor, and it can't be used for raw reading anymore.
- Since the IPython kernel effectively behaves like a console program (albeit
- one whose "keyboard" is actually living in a separate process and
- transported over the zmq connection), raw ``stdin`` isn't expected to be
- available.
+ This pattern of requesting user input is quite different from how stdin
works
+ at a lower level. The Jupyter protocol does not support everything code
+ running in a terminal can do with stdin, but we believe that this enables
the
+ most common use cases.
.. _kernel_heartbeat:
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/jupyter_client-4.3.0/docs/wrapperkernels.rst
new/jupyter_client-4.4.0/docs/wrapperkernels.rst
--- old/jupyter_client-4.3.0/docs/wrapperkernels.rst 2016-04-09
01:38:38.000000000 +0200
+++ new/jupyter_client-4.4.0/docs/wrapperkernels.rst 2016-08-31
16:52:45.000000000 +0200
@@ -4,8 +4,8 @@
You can re-use IPython's kernel machinery to easily make new kernels.
This is useful for languages that have Python bindings, such as `Octave
<http://www.gnu.org/software/octave/>`_ (via
-`Oct2Py <http://blink1073.github.io/oct2py/docs/index.html>`_), or languages
-where the REPL can be controlled in a tty using `pexpect
<http://pexpect.readthedocs.org/en/latest/>`_,
+`Oct2Py <https://blink1073.github.io/oct2py/#>`_), or languages
+where the REPL can be controlled in a tty using `pexpect
<http://pexpect.readthedocs.io/en/latest/>`_,
such as bash.
.. seealso::
@@ -67,7 +67,7 @@
from ipykernel.kernelapp import IPKernelApp
IPKernelApp.launch_instance(kernel_class=MyKernel)
-Now create a `JSON kernel spec file
<http://jupyter-client.readthedocs.org/en/latest/kernels.html#kernel-specs>`_
and install it using ``jupyter kernelspec install </path/to/kernel>``. Place
your kernel module anywhere Python can import it (try current directory for
testing). Finally, you can run your kernel using ``jupyter console --kernel
<mykernelname>``. Note that ``<mykernelname>`` in the below example is
``echo``.
+Now create a `JSON kernel spec file
<http://jupyter-client.readthedocs.io/en/latest/kernels.html#kernel-specs>`_
and install it using ``jupyter kernelspec install </path/to/kernel>``. Place
your kernel module anywhere Python can import it (try current directory for
testing). Finally, you can run your kernel using ``jupyter console --kernel
<mykernelname>``. Note that ``<mykernelname>`` in the below example is ``echo``.
Example
-------
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/jupyter_client-4.3.0/jupyter_client/_version.py
new/jupyter_client-4.4.0/jupyter_client/_version.py
--- old/jupyter_client-4.3.0/jupyter_client/_version.py 2016-06-07
10:29:02.000000000 +0200
+++ new/jupyter_client-4.4.0/jupyter_client/_version.py 2016-08-31
16:53:33.000000000 +0200
@@ -1,4 +1,4 @@
-version_info = (4, 3, 0)
+version_info = (4, 4, 0)
__version__ = '.'.join(map(str, version_info))
protocol_version_info = (5, 0)
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/jupyter_client-4.3.0/jupyter_client/adapter.py
new/jupyter_client-4.4.0/jupyter_client/adapter.py
--- old/jupyter_client-4.3.0/jupyter_client/adapter.py 2015-11-27
16:15:59.000000000 +0100
+++ new/jupyter_client-4.4.0/jupyter_client/adapter.py 2016-08-08
15:17:18.000000000 +0200
@@ -126,6 +126,7 @@
def update_header(self, msg):
msg['header'].pop('version', None)
+ msg['parent_header'].pop('version', None)
return msg
# shell channel
@@ -231,6 +232,8 @@
def update_header(self, msg):
msg['header']['version'] = self.version
+ if msg['parent_header']:
+ msg['parent_header']['version'] = self.version
return msg
# shell channel
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/jupyter_client-4.3.0/jupyter_client/connect.py
new/jupyter_client-4.4.0/jupyter_client/connect.py
--- old/jupyter_client-4.3.0/jupyter_client/connect.py 2016-03-06
10:43:14.000000000 +0100
+++ new/jupyter_client-4.4.0/jupyter_client/connect.py 2016-08-27
14:46:45.000000000 +0200
@@ -23,8 +23,9 @@
from traitlets.config import LoggingConfigurable
from .localinterfaces import localhost
from ipython_genutils.path import filefind
-from ipython_genutils.py3compat import (str_to_bytes, bytes_to_str,
cast_bytes_py2,
- string_types)
+from ipython_genutils.py3compat import (
+ bytes_to_str, cast_bytes, cast_bytes_py2, string_types,
+)
from traitlets import (
Bool, Integer, Unicode, CaselessStrEnum, Instance, Type,
)
@@ -411,23 +412,46 @@
self._connection_file_written = True
- def load_connection_file(self):
- """Load connection info from JSON dict in self.connection_file."""
- self.log.debug(u"Loading connection file %s", self.connection_file)
- with open(self.connection_file) as f:
- cfg = json.load(f)
- self.transport = cfg.get('transport', self.transport)
- self.ip = cfg.get('ip', self._ip_default())
+ def load_connection_file(self, connection_file=None):
+ """Load connection info from JSON dict in self.connection_file.
+
+ Parameters
+ ----------
+ connection_file: unicode, optional
+ Path to connection file to load.
+ If unspecified, use self.connection_file
+ """
+ if connection_file is None:
+ connection_file = self.connection_file
+ self.log.debug(u"Loading connection file %s", connection_file)
+ with open(connection_file) as f:
+ info = json.load(f)
+ self.load_connection_info(info)
+
+ def load_connection_info(self, info):
+ """Load connection info from a dict containing connection info.
+
+ Typically this data comes from a connection file
+ and is called by load_connection_file.
+
+ Parameters
+ ----------
+ info: dict
+ Dictionary containing connection_info.
+ See the connection_file spec for details.
+ """
+ self.transport = info.get('transport', self.transport)
+ self.ip = info.get('ip', self._ip_default())
for name in port_names:
- if getattr(self, name) == 0 and name in cfg:
+ if getattr(self, name) == 0 and name in info:
# not overridden by config or cl_args
- setattr(self, name, cfg[name])
+ setattr(self, name, info[name])
- if 'key' in cfg:
- self.session.key = str_to_bytes(cfg['key'])
- if 'signature_scheme' in cfg:
- self.session.signature_scheme = cfg['signature_scheme']
+ if 'key' in info:
+ self.session.key = cast_bytes(info['key'])
+ if 'signature_scheme' in info:
+ self.session.signature_scheme = info['signature_scheme']
#--------------------------------------------------------------------------
# Creating connected sockets
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/jupyter_client-4.3.0/jupyter_client/launcher.py
new/jupyter_client-4.4.0/jupyter_client/launcher.py
--- old/jupyter_client-4.3.0/jupyter_client/launcher.py 2016-03-06
10:39:27.000000000 +0100
+++ new/jupyter_client-4.4.0/jupyter_client/launcher.py 2016-08-31
16:52:45.000000000 +0200
@@ -124,9 +124,13 @@
except Exception as exc:
msg = (
"Failed to run command:\n{}\n"
- "with kwargs:\n{!r}\n"
+ " PATH={!r}\n"
+ " with kwargs:\n{!r}\n"
)
- msg = msg.format(cmd, kwargs)
+ # exclude environment variables,
+ # which may contain access tokens and the like.
+ without_env = {key:value for key, value in kwargs.items() if key !=
'env'}
+ msg = msg.format(cmd, env.get('PATH', os.defpath), without_env)
get_logger().error(msg)
raise
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/jupyter_client-4.3.0/jupyter_client/tests/signalkernel.py
new/jupyter_client-4.4.0/jupyter_client/tests/signalkernel.py
--- old/jupyter_client-4.3.0/jupyter_client/tests/signalkernel.py
2016-03-10 10:09:45.000000000 +0100
+++ new/jupyter_client-4.4.0/jupyter_client/tests/signalkernel.py
2016-08-08 13:24:58.000000000 +0200
@@ -9,6 +9,7 @@
import sys
import time
+from ipykernel.displayhook import ZMQDisplayHook
from ipykernel.kernelbase import Kernel
from ipykernel.kernelapp import IPKernelApp
@@ -61,7 +62,8 @@
class SignalTestApp(IPKernelApp):
kernel_class = SignalTestKernel
def init_io(self):
- pass # disable stdout/stderr capture
+ # Overridden to disable stdout/stderr capture
+ self.displayhook = ZMQDisplayHook(self.session, self.iopub_socket)
if __name__ == '__main__':
# make startup artificially slow,
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/jupyter_client-4.3.0/jupyter_client/tests/test_connect.py
new/jupyter_client-4.4.0/jupyter_client/tests/test_connect.py
--- old/jupyter_client-4.3.0/jupyter_client/tests/test_connect.py
2016-03-06 10:38:36.000000000 +0100
+++ new/jupyter_client-4.4.0/jupyter_client/tests/test_connect.py
2016-07-28 16:33:39.000000000 +0200
@@ -12,7 +12,7 @@
from jupyter_core.application import JupyterApp
from ipython_genutils.tempdir import TemporaryDirectory,
TemporaryWorkingDirectory
from ipython_genutils.py3compat import str_to_bytes
-from jupyter_client import connect
+from jupyter_client import connect, KernelClient
from jupyter_client.consoleapp import JupyterConsoleApp
from jupyter_client.session import Session
@@ -92,6 +92,25 @@
nt.assert_equal(value, expected, "app.%s = %s != %s" % (attr, value,
expected))
+def test_load_connection_info():
+ client = KernelClient()
+ info = {
+ 'control_port': 53702,
+ 'hb_port': 53705,
+ 'iopub_port': 53703,
+ 'ip': '0.0.0.0',
+ 'key': 'secret',
+ 'shell_port': 53700,
+ 'signature_scheme': 'hmac-sha256',
+ 'stdin_port': 53701,
+ 'transport': 'tcp',
+ }
+ client.load_connection_info(info)
+ assert client.control_port == info['control_port']
+ assert client.session.key.decode('ascii') == info['key']
+ assert client.ip == info['ip']
+
+
def test_find_connection_file():
cfg = Config()
with TemporaryDirectory() as d:
