Drop extension_name for name in ExtensionApp

[Zsailer]

This issue is to track the change from ExtensionApp.extension_name to ExtensionApp.name

Prior discussion from #222.

Why the change from name -> extension_name for the config file path? Was this to avoid the legacy path resolution?

honestly, I don't have a good answer for that 😆. It was a change I made early on in the development of ExtensionApp's to avoid legacy path resolution, but (I think) I've since patched the places where that would be an issue.

It probably makes sense to switch back...

[blink1073]

For more context, we brought up some issues with the path resolution in a JEP Issue.

In JupyterLab, we have some robust logic for detecting whether user or sys-prefix should take precedence. If using a different name allows us to use better semantics then I am all for it 😄

[blink1073]

Another data point is that the PyPA recommends only shipping data files within the package itself: https://setuptools.readthedocs.io/en/latest/setuptools.html#non-package-data-files. Also, data_files do not get moved into the appropriate place during an editable install, and that is a won't fix.

The pattern I would like to see is:

• Entry points used for discovery of extensions instead of having them insert themselves into a config.d directory.
• Incorporation of the hierarchy detection logic for root/sys-prefix/user

[blink1073]

cc @SylvainCorlay

[blink1073]

Adopting entry_points would also mean that we can avoid using magic-named functions like _jupyter_server_extension_paths.

[Zsailer]

The pattern I would like to see is:

• Entry points used for discovery of extensions instead of having them insert themselves into a config.d directory.

How do you handle enabling/disabling when using the entry point mechanism? Can you store dynamic values (i.e. enabled = True/False) in an entry point plugin?

[Zsailer]

Adopting entry_points would also mean that we can avoid using magic-named functions like _jupyter_server_extension_paths.

This would be awesome. I need to do better familiarize myself with the entry point framework.

[blink1073]

How do you handle enabling/disabling when using the entry point mechanism? Can you store dynamic values (i.e. enabled = True/False) in an entry point plugin?

The entry point would serve as a "soft" enable, that could be overridden by config.

[blink1073]

cf https://packaging.python.org/guides/creating-and-discovering-plugins/

[Zsailer]

Thanks, @blink1073. This is great!

We discussed this in the Jupyter Server meeting this morning. I'm going to draft a PR using the entry points.

[blink1073]

Yeah I saw the meeting notes. 😉

[SylvainCorlay]

Thanks for the ping @blink1073,

Entry points are interesting, although why are configuration directories to be avoided? Also, configuration directories are the default in most of Jupyter, and are language agnostic (which matters for other cases than server extensions such as kernels), so I am generally in favor of placing configuration and data files respectively in etc and share, the Unix way...

Regarding the change of APIs with respect to server extension, another change in jupyter_server is the renaming from load_jupyter_server_extension to load_jupyter_server_extension...

[Zsailer]

Regarding the change of APIs with respect to server extension, another change in jupyter_server is the renaming from load_jupyter_server_extension to _load_jupyter_server_extension...

Right, but jupyter server currently handles both. See this chunk:

https://github.com/jupyter/jupyter_server/blob/8dde7a63c0e99525431df99f7b5d5efaa081eb16/jupyter_server/extension/serverextension.py#L144-L154

[blink1073]

@SylvainCorlay, I explained why not to prefer data_files in #224 (comment). My suggestion is to offer both conf.d and entry points, but not use data_files.

[vidartf]

@blink1073 I don't think I understand the proposal fully: If we support conf.d, won't extensions be free to use data_files to configure their extension if they want to? If so, is the suggestion to only stop using data_files in official jupyter extensions? Or am I misunderstanding something further up the chain?

Similarly to @SylvainCorlay: Is your concern that your extensions will lose the ability to use data_files to configure your stuff, or is your concern the inability to gather and resolve the full configuration from both conf.d + data_files from a non-python system?