[IPython-dev] custom web notebook cells

Brian Granger ellisonbg@gmail....
Sat Dec 15 15:00:33 CST 2012


On Fri, Dec 14, 2012 at 9:05 PM, Nicholas Bollweg
<nick.bollweg@gmail.com> wrote:
> sorry, my initial setup of digest makes it hard to get at the thread
> structure directly, so hopefully this gets in the right place.
>
> the feedback has been very good, impressive community (and product, of
> course)
> you have built here!
>
>     > * We need to maintain the ability to install ipython without
> setuptool.
>
> whoa, very "there is no spoon." just went back and read some tickets that
> mention setuptools/distutils. will respect the community's desires, here!

Haha, very funny way of putting it.  You should ask Fernando abou
setuptools some time...

> so i guess, if primarily-javascript packages *were* to be installed via
> python,
> the IPython Way could be to have some %load_ext cells at the
> beginning of the notebook that would somehow change the static
> lookup path at runtime. i'll revisit my investigation of the extensions!
> once
> there is one example like this, it should be easy to repeat the pattern.

We could have the notebook server copy the static assets into a
special directory upon starting.  That wouldn't be too difficult.

>     > Before we start actually coding on the require.js stuff or
>     > reorganizing that stuff, we need to figure out what we want to do
>     > exactly.  Here is an IPEP for us to work all of that out:
>
> thanks for the pointer to the IPEP5, very good scope! while i am learning to
> love node, i might avoid bringing in the node dependency until
> someone really has that itch to scratch... i could imagine the 0mq layer
> being
> perfect for interacting between python and node... under the correct
> conditions.

I haven't mentioned it before, but I am having very conflicted
thoughts about require.js.  On the one hand, we really need something
like it, but on the other I really don't like the constraints that it
places on a project.  I think we need to investigate this further (in
the context of IPEP 5).

> ghost.py can handle the testing requirements, though it will crank up the
> travis test runs by a pretty serious amount, due to the installation of qt
> and
> friends... ah! but The Other Notebook already uses qt, so maybe this isn't
> as
> bad of a hit. here's the ghost.py .travis.yml that is the recipe i have used
> for getting it running:
>
>     https://github.com/jeanphix/Ghost.py/blob/master/.travis.yml
>
> having node around to do npm might not actually meet the needs of
> the notebook plugin builder (see below)... webassets looks good, but doesn't
> handle the dependency tree. tough choices ahead.
>
>     > * We have to serve these files on the web.  I don't want to have our
>     >   web server walking all over a users system to pull files as that is
> a
>     >   huge security risk.  We need to isolate the location of these files.
>
> yes, definitely a concern... need to wrap my head around this... what makes
> the
> most sense? options:
>
> - copy stuff into the ipython location
>   - seems bad
> - have multiple static_paths
>   - my current implementation, relies on runtime setuptools
> - collect all static deps into a tmpdir which only contains the files needed
>   - has potential...

Yes, I am liking this third option.

>     > * Some plugins don't have any python code so I am not sure it makes
>     >   sense to bundle things into a python package.
>
> indeed, i have fought with this demon a few times, most recently with apache
> allura's homerolled asset management system. putting my sysadmin hat on,
> i'd have the fewest dependency management systems possible... apt-get/yum +
> pip.
> it's an immediate turnoff if i have to do much more than that. packaging as
> python does have the whole pypi advantage, though.

Yes, I really don't want to have to invent yet another package format
for all of this.

> of course, what could end up happening is that the plugins would have
> versions
> as well, and it could be that two different .ipynb's you wanted to look at
> would use different versions. this suggests, perhaps, that the plugins
> should
> be installed into the notebook itself, which also chills me to the bone.
>
> i guess we need to understand how a user would want to use these...
> definitely
> have to do more thinking.
>
>     > But, I would like to learn more about your usage cases.  There might
>     > be other ways of supporting what you want to do:
>     > 1) Use an existing cell type with metadata.
>     > 2) Provide a custom UI for an existing cell type but don't change the
>     >    notebook format.
>     > 3) Actually add a new cell type to the notebook format officially if
> it
>     >    is something that a majority of our users would use often.
>
> my long-term vision is to build on what mathematica/jmp/tableau can do:
> support
> freeform exploration by a developer/researcher/student of a data-driven
> problem, which gradually solidifies into a dashboard (for lack of a better
> term) that allows an end user to play in a constrained data space, but
> access
> advanced features.

This very much matches our overall vision.

> while getting there, i want to better be able to document what i am thinking
> about it one, context-switching-free space that versions/merges well.
>
> i never thought of doing anything that would do (3): i am indeed
> sensitive to the long-term viability of data formats, and want to do
> whatever i
> can to avoid contributing to "data death"... all the stuff i want to do is
> very
> web-focused (for both UI and output), and is therefore inherently
> text-based...
> it might just be Really Boring text if you are at the command line (hi,
> SVG!).
> i was thinking about it primarily from a UI point of view, the current
> implementation of which centers around the IPython.Cell subclasses... so
> basically what i want is what you describe in (2).
>
> my use cases for custom cells are sort of summed up (mostly as
> implementation ideas) in this ticket on my "write some d3 visualizations
> with
> blockly" project:
>
>     https://github.com/bollwyvl/blockd3/issues/10
>
> but here's some riffing on what i've learned in the last 24 hours :)

I think there is a big design pattern that is emerging in the
notebook.  Currently CodeCells have an input area and output area.
Obviously, these were originally created for code and the output of
the code.  But, with the Javascript plugins, the output area has
really become more than merely output.  In fact here is how I view it
now...

* The input area is used for python code that initializes a "widget".
That Python code is used to create the widget, configure it, provide
input to it, etc.
* The output area is used for the widget UI.  Widgets can be arbitrary
JS/HTML/CSS.  Widgets can make calls back to the kernel and receive
further JSON data back.  Widgets can even be nested.

Here is an example that I have started to work on.  The new Web Audio
API allows Javascript to access the raw audio data from a microphone.
Using this, it is possible to create a widget that records audio and
processes and visualizes the audio in JS+Python+matplotlib+d3+etc.
Essentially, these widgets become mini-applications that can leverage
the power of both Python and JavaScript.  I think the importance of
JavaScript in this vision cannot be overstated.  Libraries like d3 are
really transforming the landscape of what is possible, not just in the
web browser, but across all platforms.

I think there is a lot of design work to do to make it easy to write
these widgets and allow them to communicate with Python.  But this is
what we have funding for and will start to work on in Jan.

> use cases:
>
> - VisualCodeCell http://code.google.com/p/blockly/
>     - motivation
>         - i've helped students reach the the "a ha" moment with
>           blockly's spiritual ancestor, scratch, but feel like the problems
>           that python is able to tackle are much greater. i see the ipython
>           notebook as a great home for the blockly python functionality, as
> it
>           can be learned by the absolute novice... when i was a python
> novice,
>           i think i had the "a ha" moment about five years ago when i
> learned
>           about tab completion and ? and ?? in the ipython console!
>
>           i have been experimenting with blockly (which can generate python)
> a
>           good deal, but exclusively for javascript. presently blockly is
> kind
>           of lame for a python workflow.
>     - implementation
>         - CodeCell. blockly xml would fit nicely inside cell metadata, which
> i have yet to explore, but need to!
>     - challenges
>         - the downside here is that any editing of the python outside of the
>           web environment (or if you didn't have the ipython-blockly plugin
> i
>           envision), the blockly environment can't reverse-engineer its xml
>           from python. however, since blockly is more aimed at the novice,
> this
>           might not cause that much of an issue.

I don't see any reason this is not possible.

> - DiagramCell http://code.google.com/p/svg-edit/
>     - motivation
>         - i love me some svg... it is deeply ingrained in my day-to-day
> design
>           and communication workflow with inkscape, and has become
> increasingly
>           important from my web application development tasks with the
> meteoric
>           rise of d3. svgedit is Almost As Good as inkscape, and for a lot
> of
>           things i want to do, it would be sufficient for a lot of quick
>           vector-based documentation things that i'd want to attach.
>     - implementation
>         - MarkdownCell
>     - challenges
>         - none, really

This would be awesome and I think it too would fit within our vision.

> - SpreadsheetCell https://github.com/bollwyvl/blockd3/issues/SlickGrid
>     - motivation
>         - some data really is tabular. i would love to be able to whip up a
>           quick table (not using markdown!) and then pop that into a numpy
>           calculation chain.
>
>           also, being able to quickly walk around higher-order numpy arrays
>           would be great, suggesting an excel-like sheet navigation for a
> given
>           array.
>     - implementation
>         - CodeCell. perhaps some metadata for formatting
>     - challenges
>         - not trying to implement Resolver One here, but a little bit of
>           functions would be cool... i like some of the things that the
> google
>           spreadsheet has done to blow out a calculation into a bunch of
> cell
>           from input into one cell

While we didn't put this into our grant specifically, it is something
we have thought about.  I think it is mostly a question of designing
the base architecture well and them having someone tackle it..

> - TangleCell http://worrydream.com/Tangle/
>     - motivation
>         - the tangle reactive document paradigm is awesome. i have done some
> work with integrating this with markdown, but it never felt right,
>           and took a lot of `exec` to work properly, which always gave me
> the
>           willies. writing constraints directly on the backend and then just
>           tying them to frontend in markdown seems like the high road.
>     - implementation
>         - MarkdownCell

We need to think more about how to handle things like this.  It is
related to our discussions about literate programming and markdown
cell templates.

> - ControlCell
>     - motivation
>         - sometimes, i just want a button or a slider for changing a value.
>     - implementation
>         - CodeCell. metadata.

This one is definitely at the core of our grant and will be one of the
first things we do once we have the base architecture done.

Cheers,

Brian

> _______________________________________________
> IPython-dev mailing list
> IPython-dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



--
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com


More information about the IPython-dev mailing list