Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Notebook doesn't contain IPython version info #3025

Closed
techtonik opened this Issue · 25 comments

9 participants

@techtonik

I can say which version of IPython my notebook is running. I propose to add it to html head as a meta tag.

@ivanov
Owner

Hi there,

To find out which version of IPython you are running, just run this code:

import IPython
IPython.__version__

Note, though, that we do store the notebook fileformat version in the .ipynb notebook file currently, but if/when that format changes, we will be able to read the older formats and upgrade them.

@techtonik

I see. But the reason is to expose this to the interface. I want to know the server and client versions as well. It should be easy to add this to , isn't it?

@techtonik techtonik referenced this issue from a commit in techtonik/ipython
@techtonik techtonik notebook: show IPython version on start up
this fixes issue #3025
aff23ec
@ivanov
Owner

It is indeed easy to do this, just a question of is it necessary to do this?

@tkf

I think it would be much better if it is provided as JSON because it is easy to parse for client programs.

@ivanov
Owner

@techtonik - welcome to IPython, we're really glad to have you participating, so I hope you don't discouraged by this bit of pushback on a feature. Part of the reason I'm questioning the need for this comes from what @ellisonbg wrote in hist posts about feature creep.

If printing __version__ is enough for you, this is something you can bake into your startup directory. Run this code to figure out how to get started:

In [2]: import os                                                                                                   |

In [3]: readme = os.path.join(get_ipython().profile_dir.location, 'startup', 'README')                              |

In [4]: !cat $readme                                                                                                |
This is the IPython startup directory

.py and .ipy files in this directory will be run *prior* to any code or files specified
via the exec_lines or exec_files configurables whenever you load this profile.

Files will be run in lexicographical order, so you can control the execution order of files
with a prefix, e.g.::

    00-first.py
    50-middle.py
    99-last.ipy

In [5]: readme
@takluyver
Owner
@minrk
Owner

There are two things here:

  1. the notebook server's version (used by clients to determine the URL API, etc.)
  2. the Kernel(s) that the notebook server can start. This would be something like a dict mapping short names to something like the content of the kernel's version_reply message.
@techtonik

I want to make sure that my notebook software is running the latest and greatest version. I am not sure that import IPython inside working frontend conjures the same version of Python that used to start it.

@takluyver
Owner
@techtonik

So, basically I need to know two versions to ensure that I am using the latest and greatest (and tag bugs accordingly).

@takluyver
Owner
@tkf

Many softwares have "About" page which shows version numbers etc. I think it is not bad to have this page in notebook. Also, if you print out versions of all relevant components and modules (e.g., tornado) you can simply ask user to copy & paste that page when you got a bug report or question. Probably it would be better than asking user to execute a command line program if you consider situation where someone other than actual user setups and hosts notebook server.

@techtonik

In very critical cases this information can be used to analyze exceptions, but for that it needs to be available from somewhere. In-process dictionary and out-of-process JSON message sound like a good idea to me, because these are reusable data formats. User level page representation on About page can be different, of course.

@ivanov
Owner
@ellisonbg
Owner

PR #3037 had one implementation of a solution, but it has been closed until we figure out where exactly we want to go with this one.

@ellisonbg
Owner

It would be very difficult to run the notebook server and kernel with different versions of ipython. You would basically have to write custom kernel manager code - you would be forking ipython. So I am not worried about that issue.

The main question is whether or not we need something more sophisticated than !ipython --version. I probably agree with @ivanov that it is not worth the added complexity to do something else. It is always important to ask "can we get 80% of the feature with 20% of the complexity and code?". I think the answer is yes.

@techtonik

If simple version string addition appears to be complicated, then reducing the code complexity is also an option.

@jason-s

The main question is whether or not we need something more sophisticated than !ipython --version. I probably agree with @ivanov that it is not worth the added complexity to do something else. It is always important to ask "can we get 80% of the feature with 20% of the complexity and code?". I think the answer is yes.

I think you need to re-examine your audience. A bunch of us are experienced Python users, and we know how to get the version of IPython through the shell or via the techniques mentioned here.

But some of the IPython users are not. I am working with a number of coworkers who are smart engineers but have very little Python experience. I give them a copy of my IPython notebooks to run, and they can do this, but they are not confident at all in making changes or running things that to them seem very sophisticated but to us seem very simple.

Yes, I can tell them to do this:

import IPython
IPython.__version__

But then I have to remember where to find it, and then I have to tell my colleagues to run that and send me the result, and I have to emphasize that they need to type in two underscores and not one. It's not a huge amount of time, but the time we have to do things is precious and it would be a lot easier if I could just tell them during a phone call to look at the IPython notebook page and tell me the version number shown at the top of the screen, so I can see if they are using the correct version. So many other programs have the version number displayed as a matter of good practice. Just a quick survey of programs with HTML browser interfaces: JIRA has it. CouchDB has it.

Please add it to the HTML header; it's a really little thing but it can make a big difference in quickly and reliably troubleshooting IPython setups among users who are beginners.


edit: more succinctly said by tkf:

Many softwares have "About" page which shows version numbers etc. I think it is not bad to have this page in notebook. Also, if you print out versions of all relevant components and modules (e.g., tornado) you can simply ask user to copy & paste that page when you got a bug report or question. Probably it would be better than asking user to execute a command line program if you consider situation where someone other than actual user setups and hosts notebook server.

@Carreau
Owner

import IPython
IPython.version

print(IPython.sys_info()) or IPython.version_info might be less scary.

look at the IPython notebook page and tell me the version number shown at the top of the screen

If you are following IPython, then you know that IPython is present in several component, printing at top of the screen will not be of much help as kernel could be a different version than frontend. I don't see many reason why you should manually check the version of IPython to run code, but lets assume we have one.

Do you intend the kernel version or the frontend version ? Showing kernel info would be doable
as in master you have the kernel indicator:

capture d ecran 2014-09-26 a 13 17 38

But this is different from embeding the kernel exact version info in notebook, and have it checked.

For the frontend info I suppose this can be doable but might not represent what you actually want.

@Carreau
Owner

Here is a proposition :
Add a long_desc to kernelspec that can hold whatever string the kernel want, and is purely for information: like 3.4.1 (default, May 19 2014, 13:09:54) \n[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] and completely optional.

A way to show it in our UI: a (i) button near kernel ?
It might not actually reflect the current kernel though, as this is set at kernel spec install time.
An about dialog page in the notebook. That give IPython Server version (not Kernel).
Maybe a small '(powererd by) IPython notebook vX.Y.Z' at end of page.

But hat won't give you any hard requirement on the notebook having to be runned by such a kernel and would be purely informative without being certain.

@damianavila

To add into the discussion... I have a setup where this could be interesting to have and I think other could encounter that situation... it is probably not a normal workflow, just throwing here to show there could be some use cases...

OK, in my case, I work in Bokeh and IPython for my daily job and I need to provide feedback for stable versions and also test development versions. So I have made kernels pointing to conda environments where the stable kernel have IPython 2.2.0 and Bokeh 0.6.1 and another env py34devel where I have IPython master and Bokeh master (and others envs too, but let get the description short)... so, I can easily test stable and devel situations just switching the kernel. So, something like having the notebook server version and the kernel version, would be very useful, because in the middle of so many envs, you can quickly lost idea about your current server version and kernel version...
In such case and in others situation where I point to specific "hacks" over the notebook, it would be useful to have some indication about the server/kernel versions I am running...

@Carreau
Owner

From #3037 should we reconsider also printing the IPython version in the console that started the notebook ?

@Carreau Carreau modified the milestone: 3.0, no action
@damianavila

Probably...

@techtonik

I also miss info on IP and port from the console.

@minrk
Owner

closed by #6554

@minrk minrk closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.