Notebook user can include local files in deployed dashboard about dashboards HOT 10 CLOSED

-1 on option 1. Magics are kernel specific.

Gino B.

On Sep 28, 2015, at 10:31 PM, Peter Parente [email protected] wrote:

The notebook author may want to include external files (e.g. HTML & CSS) without having to write the entire contents in a notebook cell. This works locally, but when the notebook is converted (and deployed) any links to local files will not work. There should be some way of "marking" files for inclusion during conversion.

Example cell linking files:

%%html
<link rel="stylesheet" type="text/css" href="main.css">
<link rel="import" href="elements.html">

Some ideas:

Cell magics for including files

%%converter include "elements.html", "main.css"
or -
%%linkcss "main.css"
%%linkhtml "elements.html"
The %%link* magics automatically insert the correct html tag, as well as being used to notify the converter.

UI component for manually selecting files to include

—
Reply to this email directly or view it on GitHub.

from dashboards.

I'll take this one.

from dashboards.

When you have a plan of attack, put some thoughts here so others can comment. I think this is related to the ever-present discussion topic of how to track all notebook dependencies (e.g., libraries, etc.) Maybe doing something for widgets will pave a bit of a path for the broader problem.

from dashboards.

Current idea is to let the user declare files as associated with the notebook using comments in one or more markdown cells, and have those files automatically included whenever deploying and also offered with a new "Download as" option, "IPython Notebook with associated files (.zip)" (a working terminology for now, I'm open to something better). The list itself would be patterns as described in https://git-scm.com/docs/gitignore as they're easy to grasp for the simplest cases, can cover complex cases, and how a tool should behave for a list of them, including negation, is well documented.

from dashboards.

The plan sounds fine to start. We'll invite community feedback on it in the PR when there's a visible code fencing option for the associate list too.

I think the true test of this should be writing a new test_package_widget.ipynb that goes along with this work. That notebook should to a very simple local custom polymer widget that sits relative to the notebook so that it works in jupyter notebook (pending fix for jupyter/declarativewidgets#22 on the widget site). The notebook should also use the new associate syntax to declare that widget's resources as stuff that should be bundled with the notebook when downloaded / deployed so that it works there also.

That test notebook should be part of the deliverable before the PR goes in, regardless of the associate syntax we pick.

from dashboards.

/cc @rgbkrk I've got this implemented so that a user can enter details into a cell indicating files that should accompany the notebook when downloaded, and be deployed in its dashboard form, whether that's custom widget files or data files (or other notebooks, although the list considered isn't transitive). I wanted to know if there's already a solution for this problem that people are keen on, or even a better way of declaring that list of files other than the syntax changes I have in mind (to be visible in the notebook when the cells' have been run). Or, really, any comments in general.

from dashboards.

The only primary ways that people have gone after it is with custom metadata in the notebook itself. This is such a persnickety problem we've all avoided that I think posting a possible solution as a PR (I'm assuming to the notebook) will end up helping give it a try. Include screenshots in the PR for the best feedback - it tends to motivate people to give the PR a spin on their local box.

from dashboards.

@rgbkrk Does it make sense to merge this here in incubator to handle the dashboard use case of it, and then take it over to notebook as a more general PR with use case in hand? I'm not sure we were after a generic solution to packing up assets to include with notebooks when you download them, though perhaps we accidentally landed on one.

from dashboards.

Merging the implementation here first then following up with a general PR seems like a good idea. I can't imagine we'll get consensus on the general use case very quickly, but having something working here helps motivate and steer.

from dashboards.

Waiting for travis to complete final test run. Then merging PR.

from dashboards.