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

[JEP 0028] New server extensions mechanism #33

Closed
Zsailer opened this issue Feb 28, 2019 · 1 comment
Closed

[JEP 0028] New server extensions mechanism #33

Zsailer opened this issue Feb 28, 2019 · 1 comment

Comments

@Zsailer
Copy link
Member

Zsailer commented Feb 28, 2019

From JEP 0028 (Jupyter Server):

New server extensions mechanism.

The new extension mechanism in the jupyter server will differ from notebook's server extensions.

  • The --sys-prefix installation would become the default. (Users are confused when enabling an extension requires more permissions than the installation of the package). Installation in system-wide directories would be done with the --system option.

  • Installing an extension will include the addition of a 'manifest' file into a conf.d directory (under one of the Jupyter configuration directories, user / sys-prefix / system). The placement of such an extension manifest provided by a Python package can be done with jupyter server extension install --py packagename [--user / --system / --sys-prefix]. Packages (conda or wheels) carrying server extensions could place such manifests in the sys-prefix path by default effectively installing them. Development installations would also require the call to the installation command.

  • Enabling an extension is separate from the installation. Multiple scenarios are possible:

  • enabling an extension at the same level (user / sys-prefix / system) as where it was installed, or at a higher level (user for sys-prefix and system, or sys-prefix for system).
  • forcibly disabling an extension that was enabled at a lower level of precedence.
  • forcibly enabling an extension that was disabled at a lower level of precedence.
    This would be done via two conf.d configuration directories managing a list of disabled extensions and list of enabled extensions in the form of empty files having the name of the corresponding extension. If an extension is both disabled and enabled at the same level of precedence, disabling has precedence. Packages (conda or wheels) could place such a enabler file in the sys-prefix path by default. The jupyter server extension enable command would be required for development installations.

(Possibly) when an extension is enabled at a given precedence level, it may only look for the version of the extension installed at the same or lower precedence level. For example, if an extension foobar is installed and enabled system wide, but a user installs a version with --user, this version will only be picked up if the user also enables it with --user.

Opening this issue for further discussion.

@Zsailer Zsailer changed the title [JEP 10] New server extensions mechanism [JEP 0028] New server extensions mechanism Mar 1, 2019
@Zsailer
Copy link
Member Author

Zsailer commented Oct 31, 2023

Closing, since this was added in Jupyter Server >= 1.x

@Zsailer Zsailer closed this as completed Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant