Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a `metadata` field to kernelspecs. #274

Merged
merged 1 commit into from Jul 6, 2017

Conversation

@craigcitro
Copy link
Contributor

craigcitro commented Jul 4, 2017

Currently, the only way for a kernel to offer additional information about its
capabilities is to encode information into the kernel name or display name;
this information can be useful to clients, especially for things like
filtering a list of kernels.

This adds support for a new kernelspec dict field, metadata. This allows
kernels to add additional information, which clients can then consume as
needed.

Fixes #273. /cc @rgbkrk

Currently, the only way for a kernel to offer additional information about its
capabilities is to encode information into the kernel name or display name;
this information can be useful to clients, especially for things like
filtering a list of kernels.

This adds support for a new kernelspec dict field, `metadata`. This allows
kernels to add additional information, which clients can then consume as
needed.
@takluyver

This comment has been minimized.

Copy link
Member

takluyver commented Jul 4, 2017

👍 I think this will also be useful for the machinery I'm proposing in #261.

@craigcitro

This comment has been minimized.

Copy link
Contributor Author

craigcitro commented Jul 5, 2017

Ah, @takluyver, this does seem like it'd be exactly the information you'd want to return as kernel info in find_kernels() in that PR.

That actually brings up an interesting parallel I hadn't realized at first -- internally at Google, we don't use conda/virtualenv/etc at all, but the "different libraries" I alluded to in #273 are a really close analogue to different virtualenvs or conda environments, where each has a fixed set of libraries installed (possibly with particular build configurations for C++ libraries, that sort of thing). So I suspect we're actually solving roughly the same problem -- meaning I can hopefully bootstrap off some of what you're doing in #261. 😉

@rgbkrk

This comment has been minimized.

Copy link
Member

rgbkrk commented Jul 6, 2017

Since so far there is agreement on this one, its been open a few days, and this fits in with the way we do metadata elsewhere, I'm going to merge this with the acknowledgement that metadata is going to be the wild west just like in the notebook format.

@rgbkrk

This comment has been minimized.

Copy link
Member

rgbkrk commented Jul 6, 2017

Like we've done in the notebook format (especially per cell metadata) we've explicitly stated that usage of metadata should be namespaced. That could be worth adding on here too.

@rgbkrk rgbkrk merged commit 5a8d7f8 into jupyter:master Jul 6, 2017
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
craigcitro added a commit to craigcitro/jupyter_client that referenced this pull request Aug 2, 2017
(This is a followup to jupyter#274.)
craigcitro added a commit to craigcitro/jupyter_client that referenced this pull request Aug 22, 2017
(This is a followup to jupyter#274.)
@minrk minrk added this to the 5.2 milestone Mar 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.