Add version_request/reply messaging protocol #2649
Conversation
|
Version field is already in the msg header, what utility does this serve? |
|
I don't see that in the message spec. What version is written there, the On Wed, Dec 5, 2012 at 2:41 PM, Min RK notifications@github.com wrote:
Brian E. Granger |
|
IIRC from the ruby integration I did [0,14,dev] https://github.com/Carreau/iruby/blob/master/lib/session.rb#L36 |
|
Wow, the IPython version number is transmitted in every message with that change? Doesn't that seem a bit wasteful? Maybe it could be transmitted at the start of a session or something, but since the version number probably won't change in a single session, it seems a shame to have to waste the bandwidth. |
|
And: the confusion here between IPython version number and messaging spec version number indicates that this message should probably have a more descriptive type name, maybe protocol_version or something. |
|
@minrk Sorry, I should have clarified the context. This PR is based on the discussion in the mailing list: @Carreau What does it tells to client? Something like "you need at least this version"? Probably @jasongrout is right about the protocol naming. So, should it be |
|
OK, so this is how IPython sends version of IPython itself.: import IPython
_version_info_list = list(IPython.version_info)
def msg_header(msg_id, msg_type, username, session):
date = datetime.now()
version = _version_info_list
return locals()ipython/IPython/zmq/session.py Line 189 in 6c36cd9 I agree with @jasongrout that this is a bit of waste. But probably a list in the header won't give you any significant penalty? I can't tell, as I don't do any benchmarks. More important than that, if it is in the header, client needs to send a no-op message to get that. I guess BTW I'd write it this way: def msg_header(**kwds):
kwds.update(date=datetime.now(), version=_version_info_list)
return kwds |
|
Other topic we need to discuss is weather we need the "patch version" ( Disclaimer: I've never used the semantic versioning. I just thought it fit well with protocol versioning. |
|
Okay, then if we are adding this, I would suggest a few changes:
I think using semantic versioning is fine, but may be overkill - a 'bugfix' to a protocol definition doesn't make a lot of sense to me, but people generally expect 3-part versions, so we might as well use it, even if the last field is always zero. |
|
So the message spec will be something like this? content = {
'protocol_version': [int, int], # or [int, int, int]?
'ipython_version': [int, int],
'python_version': [int, int, int],
'platform': str,
}I guess |
|
As you point out, with other kernel implementations, perhaps adding 'language' makes sense, or something more generic, such as 'kernel', which identifies the kernel implementation. Also, IPython's version is a 3-tuple, not 2 (0.13.1, etc.) - dev should give inf, so Python 3's new comparison rules don't barf. |
I guess you will have to add also 'julia_version' soon (even if it does not move fast...) I agree with min that we should make the protocol without ipython/python specificities. (Hoooo we can drag and drop images into comment field now....) |
|
OK, protocol spec version 3! content = {
'protocol_version': [int, int], # or [int, int, int]?
'ipython_version': [int, int, int], # e.g. [0, 13, 0]
'kernel_version': [int, int, int], # e.g. [2, 7, 2]
'language': str, # e.g., 'python'
'platform': str, # = sys.platform
}How about other general stuff, such as
Can't wait to see Julia kernel! |
|
I forgot |
|
Also, probably |
This is the correct relationship. It is not important to place dev versions in-between patch revisions. dev should always evaluate as 'latest', so inf is actually correct. -1 would give the wrong semantics, as comparing with 0.14.0 should give True for any 0.14dev, whereas -1 would make that not true. |
|
On Fri, Dec 7, 2012 at 12:16 PM, Takafumi Arakaki
|
|
Well, I just thought kernel_version won't mean anything as long as you don't know what implementation of language you are talking to. Also you can't stop clients to get interpreter name as they can execute any code. All the properties other than |
pypy, CPython, and IronPython all report the Python version they implement. So I would expect a pypy interpreter to identify itself as Python 2.7.1. It's fine if interpreter is a separate field, but it shouldn't be used in place of the more significant fact that it implements a particular version of Python. |
|
Right. I was wrong about replacing the language property. Close to the landing point?: content = {
'protocol_version': [int, int], # or [int, int, int]?
'ipython_version': [int, int, int], # e.g. [0, 13, 0]
'kernel_version': [int, int, int], # e.g. [2, 7, 2]
'language': str, # e.g., 'python'
'interpreter': str, # e.g., platform.python_implementation()
'platform': str, # ?
}How about
|
|
Would other languages need to conform to the python uname format? Maybe we're overreaching ourselves here, and need to just go back to protocol version and language (and possibly language version). It's easier to add to the spec than to take away from it if we decide later we made a wrong decision. |
|
I'm inclined to agree with @jasongrout - let's not try to add every potentially relevant field we can think of here. (As to the question of language version numbers: my understanding is that the Python language has a two-part version number, e.g. |
|
OK, so the remaining decision is the format of content = {
'protocol_version': [int, int], # or [int, int, int]?
'ipython_version': [int, int, int], # e.g. [0, 13, 0]
'kernel_version': [int, int, int], # e.g. [2, 7, 2]
'language': str, # e.g., 'python'
'interpreter': str, # e.g., platform.python_implementation()
} |
|
On Fri, Dec 7, 2012 at 2:20 PM, Jason Grout notifications@github.comwrote:
I think more information is better, but there should be a line between We may even be going beyond what is useful here - a significant change to Depending on how we define the message spec, we haven't made a release yet —
|
I think extra information is better be optional (can be omitted), but it
If you ignore users of master branch, yes. Also, it requires client |
|
I think this much is fairly well settled, yes? content = {
'protocol_version': [int, int, int], # or [int, int]?
'ipython_version': [int, int, int], # e.g. [0, 13, 0]
'language_version': [int, int, int], # e.g. [2, 7, 2]
'language': str, # e.g., 'python', 'ruby', or 'R'
}Here are some additional differentiators we may be interested in:
If these aren't easily settled, we can go with the 4-key version above for now, and add more as we discover a need for them. |
|
@minrk @takluyver Thanks, I fixed the failure and added the document. |
|
What version number should be used for a kernel implementation which does not support all the protocols? For example, you don't need history request protocol to support current IPython notebook so it makes sense to release a kernel without history request. One possibility is to reserve minor version 0 for such "partial implementation". Or we can later add a way to "raise" not implemented error. |
|
On Sat, Dec 15, 2012 at 12:10 PM, Takafumi Arakaki <notifications@github.com
A generic number does not make sense to express 'partial' support, where
That is, the dict with The advantage of 1. is that frontends don't need to know about which Or we can later add a way to "raise" not implemented error. There is already a single location where the kernel handles unrecognized https://github.com/ipython/ipython/blob/master/IPython/zmq/ipkernel.py#L231 |
|
If the partial implementation problem should be solved by the mechanism other than version number, I guess the discussion should go the other issue thread. Shall I open one? |
|
On Sat, Dec 15, 2012 at 1:05 PM, Takafumi Arakaki
yes, I suppose so - though I don't expect we will actually need more than
|
|
What I meant was that if we are solving the problem by playing with version number, we need to change version number in this pull request. If not, we can do it later. But probably we should do it here. As you said, if we don't want another message type, probably we should just change the message name to |
|
On Sat, Dec 15, 2012 at 3:34 PM, Takafumi Arakaki
|
|
@minrk I like kernel_info. Renamed the message. |
|
Are there anything left to do? |
|
I haven't followed the discussion too closely, but overall the code looks good. One thing that I did see is that the protocol version is buried in the session.py module. I think we should put it in a more prominent location, perhaps, in the same location where we put the rest of IPython's version information. |
|
I see @minrk recommended putting the protocol version in session.py. @minrk do you think it makes sense to put it in |
|
@ellisonbg I don't have strong feelings about it anymore - release makes some sense, but I initially picked Session as that's where the implementation lives. I could go either way. core.release has the advantage that it will always be importable for |
|
per @ellisonbg's recommendation, let's move the protocol_version to core.release, then I think this is ready to go. |
| @@ -38,6 +38,9 @@ | |||
| version = __version__ # backwards compatibility name | |||
| version_info = (_version_major, _version_minor, _version_micro, _version_extra) | |||
|
|
|||
| # Change this when incrementing the kernel protocol version | |||
| kernel_protocol_version = (4, 0) | |||
There was a problem hiding this comment.
Should we call this kernel_protocol_version_info, to be consistent with version_info?
|
@minrk Fixed. |
|
Great, I will merge. Thanks! |
Add version_request/reply to message spec and protocol_version added to core.release
Add version_request/reply to message spec and protocol_version added to core.release
Add support for `kernel_info` request for IPython kernel protocol. See: ipython/ipython#2649
Test in test_message_spec.py passes. No real world test is done yet.
Do we need user visible change (e.g.,
%kernelversionmagic)?