Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #9059 > unrolled thread

How to deal with jupyter notebook extensions

Back to article view | Back to linux.debian.maint.python

Contents

  How to deal with jupyter notebook extensions Ximin Luo <infinity0@debian.org> - 2016-12-03 17:30 +0100
    Re: How to deal with jupyter notebook extensions Piotr Ożarowski <piotr@debian.org> - 2016-12-05 11:50 +0100
      Re: [Debian-science-sagemath] How to deal with jupyter notebook  extensions Ximin Luo <infinity0@debian.org> - 2016-12-05 12:30 +0100

#9059 — How to deal with jupyter notebook extensions

+debian-python@

Jupyter Notebook allows for the installation of "extensions". Users typically download an extension, then run something like this:

$ jupyter nbextension install <package>  # or python/python3 -m notebook.extension install [..]
$ jupyter nbextension enable <package>   # likewise

We're trying to figure out how to deal with this in Debian. Ideally users shouldn't need to run these steps, above.

The "install" step is basically redundant for Debian, it just involves copying files to /usr/share/jupyter/nbextension. So instead of installing the <package> files as a python module (whose sole purpose is to wrap non-python files), then calling "install" at runtime to put them into /usr/share/jupyter/nbextension, I'm installing these directly to the latter location, and omitting <package> from the filesystem.

<package> in my specific case is widgetsnbextension. It contains some metadata to describe where it should be installed to, see [1], but otherwise the "contents" is simply /usr/share/jupyter/nbextension/jupyter-js-widgets/extension.js

[1] https://anonscm.debian.org/git/python-modules/packages/ipywidgets.git/tree/widgetsnbextension/widgetsnbextension/__init__.py

So far, so good. But now I'm having trouble trying to automate away the "enable" step. What "enable" does is add an entry to /etc/jupyter/nbconfig/notebook.json. There are two ways of automating this, and I'm not sure which way is the best. They each have their downsides.

postinst hook in all notebook extension packages
================================================

One downside is that I would have to add a hard Depends: python3-notebook | python-notebook to jupyter-nbextension-jupyter-js-widgets, and then run either 

  $ python -m notebook.nbextensions enable jupyter-js-widgets/extension # or
  $ python3 -m notebook.nbextensions enable jupyter-js-widgets/extension

depending on what is available. Note that they do the same thing, i.e. edit the file mentioned above, so it doesn't matter which one is run.

Another downside is that every jupyter-notebook extension would need to have this complexity.

postinst triggers hook in python-notebook, python3-notebook
===========================================================

See https://wiki.debian.org/DpkgTriggers on what triggers are, and I'm sure you've noticed the "processing triggers" messages for man-db, etc.

The up-side of this approach is that extension packages don't need an extra Depends, and they don't need to do any extra work in their own packages.

However, it's unclear how to write the trigger. The "naive" thing is to do this:

python{,3}-notebook.postinst:
[..]
case "$1" in
    [..]
    triggered)
        cd /usr/share/jupyter/nbextensions
        find -name '*.js' -exec sh -c \
            'f="${1%.js}"; f="${f#./}"; \
             python{,3} -m notebook.nbextensions enable --sys-prefix "$f"' \
            -- '{}' \;
    ;;
    [..]
esac
[..]

However there are two down-sides to this:

1. We might pick up extraneous *.js files that extension packages might install. There's nothing to prevent this, from upstream's point of view - users need to specify a particular extension, but the installed files could contain other non-extension js files. The attempts to install these files might fail, which would obfuscate real errors.

2. There is an extra arg to the "enable" subcommand:

  --section=<Unicode> (ToggleNBExtensionApp.section)
      Default: 'notebook'
      Which config section to add the extension to, 'common' will affect all
      pages.

If this is set to a value other than "notebook", then the file being edited would be /etc/jupyter/nbconfig/${that-value}.json instead of notebook.json.

Or, if we were enabling a python module (that wraps the plain extension e.g. the <package> that we got rid of earlier), the section is automatically taken from the "section" key within that python module (e.g. see [1] above again) - instead of implicitly being "notebook".

In practise, I haven't seen anyone use anything other than the "notebook" value, and I don't know how important or common the other cases are. However, it does mean that the above "naive postinst trigger" is not technically correct, and is missing information.

So, I'm not sure of the best way to proceed here; some advice would be much appreciated.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

[toc] | [next] | [standalone]

#9063

[Ximin Luo, 2016-12-03]
> So far, so good. But now I'm having trouble trying to automate away
> the "enable" step. What "enable" does is add an entry to
> /etc/jupyter/nbconfig/notebook.json. There are two ways of automating
> this, and I'm not sure which way is the best. They each have their
> downsides.

is upstream willing to apply a patch to support
/etc/jupyter/nbconfig/notebook.d/ that would solve your problem IIUC?
-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

[toc] | [prev] | [next] | [standalone]

#9064 — Re: [Debian-science-sagemath] How to deal with jupyter notebook extensions

Piotr Ożarowski:
> [Ximin Luo, 2016-12-03]
>> So far, so good. But now I'm having trouble trying to automate away
>> the "enable" step. What "enable" does is add an entry to
>> /etc/jupyter/nbconfig/notebook.json. There are two ways of automating
>> this, and I'm not sure which way is the best. They each have their
>> downsides.
> 
> is upstream willing to apply a patch to support
> /etc/jupyter/nbconfig/notebook.d/ that would solve your problem IIUC?
> 

They would probably not want to do that, because (at least currently) the only "config option" each extension would have, is which "sections" it should be enabled in. So we'd get a mess of 1-line files in those directories.

However, I've come up with an alternative solution in the meantime, based on triggers but solving the downsides mentioned previously. Each package can install, an extra file, e.g.:

/usr/share/jupyter/nbextension/jupyter-js-widgets/extension.nbextension

whose contents would simply be "section: notebook" or even "" to imply the default value, "notebook".

Then I can write a notebook.nbextensions_scan_update module to scan for .nbextension files, and run this module in the postinst trigger. And I will ask upstream to accept this scanner module.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web