Unclear how to obtain jupyter_client version number

[lumberbot-app]

This arose in jupyter/nbconvert#328

I eventually noticed that jupyter-client manages jupyter kernelspec so I thought jupyter kernelspec --version might work, and it returned the value I expected so I think that is one way to do it…is that right?

but we might want to put in some kind of a command for either dumping a lot of the relevant jupyter version numbers all at once (for debugging and error locating purposes), or include a jupyter client --version even if all it exists to do is to provide the version number in a more straightforward fashion.

---

Originally opened as jupyter/jupyter_client#178 by @mpacer, migration requested by @Carreau

[lumberbot-app]

@minrk commented: In general, the way to find a Python package version is via pip list or conda list. To find the same information from Python, you would import the package and use package.__version__. jupyter_client and all Jupyter packages follow these standards.

Each Jupyter entrypoint does expose the version of the package providing it, but I don't think we should add new entrypoints whose sole purpose is to report version numbers. The package managers already provide the entrypoint for this.

[lumberbot-app]

@takluyver commented: I'd also rather not add subcommands like jupyter client just to have version numbers, but I could maybe be persuaded of something like jupyter --versions to print version numbers of a list of core Jupyter packages. I'm not sure what the advantage over pip/conda list would be, though.

[lumberbot-app]

@Carreau commented: I think the pip/conda approach is complex as pip can shadow conda and it's anyway confusing for users to know in which environment they are.

I see a few approaches:

Have something in the Jupyter metapackage that list versions. And assume that people that do not install this meta-package know what they are doing.

Have a thing that list version in jupyter_core.

[lumberbot-app]

@takluyver commented: We do have the jupyter troubleshoot command that captures the output of both pip list and conda list.

[lumberbot-app]

@Carreau commented: > We do have the jupyter troubleshoot command that captures the output of both pip list and conda list.

Well... I did not remember merging it, but indeed we do.. we need to document it more.

[lumberbot-app]

@mpacer commented: Should it be documented in each of the jupyter projects since it could be
helpful in any of those cases?

On Fri, Jul 29, 2016 at 11:51 AM, Matthias Bussonnier <
[email protected]> wrote:

We do have the jupyter troubleshoot command that captures the output of
both pip list and conda list.

Well... I did not remember merging it, but indeed we do
https://github.com/jupyter/jupyter_core.. we need to document it more.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
jupyter/jupyter_client#178 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACXg6AIzAnHkcYMKjE9jbFOSgv2TOsaeks5qakuXgaJpZM4JXhRA
.

[lumberbot-app]

@takluyver commented: Probably not in detail, because duplicating docs is a great way to make outdated docs in the future ;-). We could crosslink it, but it's not obvious to me where people will land when they have problems. The main reason for jupyter troubleshoot is so that we can ask people to run it when they're reporting a problem, to get a snapshot of what's going on. We've just tended to ask for specific bits of information instead.

[lumberbot-app]

@mpacer commented: This came up again in a discussion with @jhamrick about people leaving useful info in the context of issues and bug reports.

I think that having a global jupyter --versions in the metapackage would be a great way to approach that. I may take a look at that…

@Carreau is meseeksbot able to transfer issues between repos in different orgs? Because this would seem to be most appropriate for jupyter/jupyter_core now that this is the agreed upon solution.

[lumberbot-app]

@takluyver commented: From a user perspective I like the idea of doing jupyter --versions to see all the versions. From an organisational perspective, it's a bit ugly that it would need a) a package that knows the names of all the other Jupyter packages, b) updates to that package to add to the list, and c) a decision as to what packages belong in the list.

[lumberbot-app]

@Carreau commented: > @Carreau is meseeksbot able to transfer issues between repos in different orgs? Because this would seem to be most appropriate for jupyter/jupyter_core now that this is the agreed upon solution.

Yes that's one of the feature. If it's enabled on 2 repositories, and you have admin permission on both you should be able to ask him to migrate.

I agree (in principle) with @takluyver, in this case I think that practicality beats purity.

We can also add a This list might not show the versions of all the Jupyter related packages you have installed. And once your new Entrypoint-pep is installed we can make use of that right ?

[lumberbot-app]

@takluyver commented: We could, but then it requires a change and new release of all Jupyter packages before it's usable. And by the time extension authors are using it as well... I feel like we may as well just ask people to run jupyter troubleshoot and get the versions of all packages.

Maybe we could add a feature so you could do jupyter troubleshoot --gist and it would publish to a gist and give you a link back.

[lumberbot-app]

@mpacer commented: @MeseeksDev migrate to jupyter/jupyter_core

@Carreau I think MeseeksDev is not enabled on jupyter_client

[lumberbot-app]

@mpacer commented: While I understand the principle you're talking about @takluyver, but I actually think a list of all the jupyter maintained python packages) is probably something worth doing independently.

That will require solving a), b) and c), but I think that's reasonable. Can you give an example of edge cases that you think are going to be difficult to establish? At least at first, I was thinking that it would be good to have hard boundaries like "is it a package hosted on any of our official orgs?". So for example I'd think that'd be a subset of the packages living in the following orgs:

• jupyter
• ipython
• jupyterhub
• jupyterlab

That subset need not be (but probably should be) a proper subset of the packages on those repos. But if we make an assumption that we should include more rather than fewer things, just including everything from those orgs wouldn't be the worst first pass (& it would be greatly improved from a dump of everything from pip/conda).

Also, it's worth noting that we kind of do this in an indirect way in the jupyter/help org: https://github.com/jupyter/help#reporting-a-bug-in-a-jupyter-project

@takluyver What's the entrypoint pep? I'm intrigued!

[lumberbot-app]

@mpacer commented: I think that @Carreau's warning message would also be a good touch, though with an additional pointer to say "If you see that a package is missing please let us know at https://github.com/jupyter/jupyter_core/issues "

[lumberbot-app]

@Carreau commented: > @Carreau I think MeseeksDev is not enabled on jupyter_client

weird. Let me check, there is no error or refusal in the logs.

[lumberbot-app]

I was not able to apply the following label(s): documentation

[takluyver]

Addressed by #136.