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.

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.

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.

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

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.

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
#178 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACXg6AIzAnHkcYMKjE9jbFOSgv2TOsaeks5qakuXgaJpZM4JXhRA
.

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.

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.

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.

@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 ?

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.

@MeseeksDev migrate to jupyter/jupyter_core

@Carreau I think MeseeksDev is not enabled on jupyter_client

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!

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 "

@Carreau I think MeseeksDev is not enabled on jupyter_client

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

I think you typoed.

@meeseeksdev migrate to jupyter/jupyter_core

Done as jupyter/jupyter_core#117.

Yep you typoed.

Oweee you missed an EEEE