Conda-forge.github.io: Installing Jupyter Notebooks?

[jakirkham]

Where do we want to install Jupyter Notebooks? I have seen many recipes proposed where this might be an option and I would like us to think about the issues and standardize how we are going to do this. Just spit balling here, but maybe in share/notebooks or something like this. If other tools have smarts for recognize this location, it would be good to consider them in this thought process too.

cc @conda-forge/core @bollwyvl @melund @lmcinnes @jcb91

[patricksnape]

share/notebooks sounds sensible, though it would probably also be sensible for projects to place them within a folder inside share/notebooks so that it doesn't just become a dumping ground. We might also want to make sure to advise people to move notebooks out of that directory if they are going to be modified otherwise they would get overwritten by an update.

[jakirkham]

though it would probably also be sensible for projects to place them within a folder inside share/notebooks so that it doesn't just become a dumping ground

Absolutely, maybe we can have it be share/notebooks/<package name>.

[melund]

@jakirkham This was also my idea. I have updated my recipe here #1025

[lmcinnes]

That seems like the most sensible place to me, and it really is beneficial
to have notebooks as extra documentation. Thanks for suggesting such a
possibility.

On Sun, Jul 17, 2016 at 2:25 PM, Morten Enemark Lund <
[email protected]> wrote:

@jakirkham https://github.com/jakirkham This was also my idea. I have
updated my recipe here #1025

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/conda-forge/conda-forge.github.io/issues/196#issuecomment-233196117,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALaKBfRjhAC1zxaUiRy-Ta0UyTxVlEU8ks5qWnOkgaJpZM4JORjs
.

[ChrisBarker-NOAA]

Notebooks can be great documentation, but don't they belong with the other
docs? And/or with the package?

Is there a provident for conda packaging up the docs?

/CHB

Sent from my iPhone

On Jul 17, 2016, at 1:38 PM, Leland McInnes [email protected]
wrote:

That seems like the most sensible place to me, and it really is beneficial
to have notebooks as extra documentation. Thanks for suggesting such a
possibility.

On Sun, Jul 17, 2016 at 2:25 PM, Morten Enemark Lund <
[email protected]> wrote:

@jakirkham https://github.com/jakirkham This was also my idea. I have
updated my recipe here #1025

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/conda-forge/conda-forge.github.io/issues/196#issuecomment-233196117
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ALaKBfRjhAC1zxaUiRy-Ta0UyTxVlEU8ks5qWnOkgaJpZM4JORjs

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/conda-forge/conda-forge.github.io/issues/196#issuecomment-233202660,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA38YKeoSzi5NjR0TPdowYdZ79hM4i3jks5qWpLYgaJpZM4JORjs
.

[jakirkham]

There is a hard rule with docs amongst packages generally. Though they normally have a PREFIX/share/man if they have man pages. If the docs are something else, they usually live somewhere in PREFIX/share.

In any event, sometimes notebooks are docs. However, sometimes they are the user interface to the code. It is this later case that has caught my attention and prompted this discussion.

[bollwyvl]

I love the idea... but don't know how they would be surfaced in the UI... it wouldn't be out of control to say jupyter notebook --notebook-dir=${CONDA_PREFIX}/share/notebooks/this-a-here-package, but I still wouldn't want to offer that as a "first stop" for showing people how to use a package. Nicer might be to whip up a jupyter subcommand (just an entrypoint away, really) with a custom ContentsManager, like jupyter shelf or jupyter browse that could enumerate some discoverable, predictable locations, but read-only (or copy-on-write to current directory).

Here's the nickel fix:
https://gist.github.com/bollwyvl/0173efba9e5cf78c55cade93dfbbe91e

Of course, it would be packaged, and follow all the other conventions, it would then make sense to have:

• ~/.jupyter/notebooks
• $PREFIX/share/notebooks
• /opt/local/share/notebooks
• /share/notebooks
  or whatever.

This would give a nice home for efforts by some projects like bokeh that actually maintain a separate repo specifically of notebooks... but don't package them in any way, while making them more "browseable". Good enough?

I have been wondering, more generally, about something akin to dash/zeal/whatever but:

• use dedicated, versioned conda packages for distribution
  
  
  
  • always pull the right versions
  
  
• leveraging Jupyter (specifically JupyterLab) for the UI
  
  
  
  • heck, those things already look a lot like the jupyterlab demo
  
  
• maybe make use of better-than-okay search/introspection... dash's sqlite is great, but we should be able to do better.

It could be all-business conda-doc, or something more flowery, like, conda-lexandria.

There are some compelling starting points:

• https://github.com/Polyconseil/dokang
• https://github.com/staffanm/ferenda
• https://github.com/jupyter-incubator/contentmanagement

My inclination would be to reuse as much of the parser/harvest/enrich/whatever ETL chain from the above things, but probably start over with some asnyc Tornado goodness under some JupyterLab multi-tab management.

Fun stuff!

[bollwyvl]

Altair also ships notebooks, and has some custom ways to get them into the user space with the file API:

https://github.com/ellisonbg/altair/blob/master/altair/notebooks/01-Index.ipynb

[jakirkham]

Yeah, I think this ToC format has been something I have seen most often. Probably inspired or fueled by people trying to use Binder.

Though there are definitely some neat ideas mentioned above that are worthy of exploration.

Just as an example of one of the things being proposed is @melund's PR ( https://github.com/conda-forge/staged-recipes/pull/1025 ), which create an App entrypoint into the ToC notebook. This seems really nifty to me and I would love to find way for conda-forge to foster this sort of exploration.

[pelson]

Nice idea and v. interesting discussion. That said, this isn't really a conda-forge thing - it applies as a useful standard for all packaging systems (including anaconda, EPD, Debian etc.) though I certainly have no problems with conda-forge trailblazing here.

My suggestion: create a package which lives outside of conda-forge, and it can then be packaged up in short order on conda-forge.

FWIW, I completely support the <prefix>/share/notebooks/<package name> standard.

[jakirkham]

It sounds like we have a standard in place and some people are using it. That was my initial goal with this issue. So am going to close that out.

That all being said, please feel free to continue discussing other ways to improve on the notebook packages.