-
Notifications
You must be signed in to change notification settings - Fork 5k
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
Using python entrypoints for notebook server extensions? #2894
Comments
I was thinking about this.. maybe a few hours ago :) |
I think for server extensions it makes sense to use entry points. It's less clear for nbextensions: they are usually installed and served through Python machinery, but in principle there's nothing Python specific about them, and we may one day regret tying them to Python mechanisms. On the other hand, if server extensions are loaded by entry points, it would be a nice symmetry for nbextensions to use the same, and it would mean that extensions could be cleanly uninstalled with the same tools used to install them. This also ties into our discussion on #2824 about moving to a model where installed extensions are automatically loaded unless they have been disabled, rather than requiring an enable step as we currently do. See also my entrypoints module, which we're already using in nbconvert. |
I'm leaning towards using entry points for both server extensions and nbextensions:
|
👍 For server extensions using entry points. This would also allow installation while the notebook server is running. For extensions themselves that sounds good, too. Definitely worth considering IMO. |
I like that it is tied to the Python environment, it will no leak out of the Python environment like it currently does (if you don't include --sys-prefix, at least for nbextensions) |
Hm, but that may the thing that breaks the use case for notebook extensions ? Now when I use a different Python environment as my kernel, how do I get nbconvert support or additional templates tied to the Python package ? |
+1, big fan of Presumably, we'd just duplicate part of the traitlets config namespaces: setup(
# ...
entry_points={
'notebook.NotebookApp.nbserver_extensions: 'my-serverextension = my_serverextension'
}
) Where, because Anyhoo, thinking about that, though: some of the more powerful/evil "extensions" out there aren't serverextensions (or aren't just server extensions), and need to touch other parts of (multiple) Having a "one entry point to rule them all" for config would be pretty concise: setup(
# ...
entry_points={
'jupyter_notebook_config': 'my-contents-kernel-auth-manager-serverextension = mckam:my_custom_jupyter_config'
}
)
# ...
def my_custom_jupyter_config(c):
c.NotebookApp.contents_manager_class = Foo
c.NotebookApp.nbserverextensions["foo"] = Bar
... Presumably this would take effect right before the on-disk As an extension developer, you're still writing a function, but it's not a magic-named function, and the magic name appears in the least-worst place ( |
w00t, this is all awesome :) Looks like there's enough other people more experienced & invested in this than me to make this happen, so I'm unlicking this cookie :D I'm happy with anything y'all come up with as long as I can just do 'pip install' and it just works :) <3 |
For reference, Donald Stufft mentioned some problems with entry points in a thread on distutils-sig. I don't think it should necessarily stop us using them (especially because I'm not sure there's any alternative without similar issues), but it's worth being aware of the drawbacks:
I have some plans to do caching to mitigate the slowness issue (that's partly what the distutils-sig thread is about) - but that's inevitably going to lead to a new kind of problem, with caches getting out of date. We'll have to wait for the implementation to know how big a problem that will be in practice. |
FWIW, I'm trying to use entry points as well, and I am not sure how good support is on conda. The meta.yaml has an build:
preserve_egg_dir: True @takluyver could you explain what entrypoints does? I am not sure why it is needed next to setuptools/pkg_resources? |
I think it should work through conda so long as you use pip to build the package. We don't appear to need any other options when doing that - I've just checked the IPython package from conda-forge, and it has the expected entry points in the right place (both
|
The jupyterlab recipe also includes entry points but without using |
@takluyver thanks, i'll take that up with the conda-forge people to see what their preference is for non-console-entry points. Could you maybe explain the entrypoints goals on the documentation page, because I think it is useful to know, and a useful package :). @blink1073 I was referring to non-console entry points, or did I miss your point? |
Ah, I haven't used those before in conda, but I suspect they should work the same with that invocation. |
Yeah it looks like you don't have to specify the non-console entry points in In [2]: import pkg_resources
In [3]: for entry_point in pkg_resources.iter_entry_points('nbconvert.exporters'
...: ):
...: print(entry_point)
...:
rst = nbconvert.exporters:RSTExporter
custom = nbconvert.exporters:TemplateExporter
html = nbconvert.exporters:HTMLExporter
... |
I think this can be closed due to #3116 right? |
I am personally a fan of entry_points, but yes, I would say #3116 has
pretty much solved the issue.
At this point, add this and we're getting even further from "preferably
one" way to do the thing... we'd also have to resolve yet another "who
wins" race vs the current ($>) x ((., ~, $prefix, /) x (py, json)) matrix.
…On Fri, Jan 5, 2018, 13:46 Maarten Breddels ***@***.***> wrote:
I think this can be closed due to #3116
<#3116> right?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2894 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AACxRHgRXzi4FiZYoz12nzWG2fh5_O3Oks5tHm3sgaJpZM4Prd1X>
.
|
Also, entry_points imply that you must have a Python package, while data_files can be populated by anything (e.g a non-Python conda package). |
But I suppose with server extensions you are already a Python package... |
Yes... But some server extensions also need to monkey about with other
configurables (e.g. ContentsManager, KernelManager... which never even had
a cli for changing!). Problem is, those aren't generally composable, so an
entry_pointy thing would still need to accompanied by a config file and win
the config race...
…On Fri, Jan 5, 2018, 17:36 Steven Silvester ***@***.***> wrote:
But I suppose with server extensions you are already a Python package...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2894 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AACxRDY5oxDJQsGrrou4t7rl6nrQ55vsks5tHqPsgaJpZM4Prd1X>
.
|
Closing as fixed then. If folks would like to continue the discussion then the Jupyter Server repo would be a good place for this: https://github.com/jupyter-server/jupyter_server Thanks all! |
Heya!
Notebook server extensions now need an extra step after being pip installed to be enabled. However, since they're purely python, we could just discover them via a well known Python Entry Point - and then just pip install would work.
I tried looking for discussion about this in this repo, and couldn't find any. #116 was the closest I could find, but that seems a much bigger discussion than just serverextensions. Server Extensions are always Python, they can be notebook specific, etc - so all those would be side stepped.
I found http://amir.rachum.com/blog/2017/07/28/python-entry-points/ to be a very good description of entrypoints in python, and I really like how pytest uses them.
If this seems like a good idea, I might take a shot at writing up a patch. If there was discussion about this elsewhere, telling me where to search would also be highly appreciated!
The text was updated successfully, but these errors were encountered: