[IPython-dev] custom web notebook cells

[Brian Granger]

Nicholas,

Hi!

On Fri, Dec 14, 2012 at 5:13 AM, Nicholas Bollweg
<nick.bollweg at gmail.com> wrote:
> hi everybody! longtime user, first time poster.
>
> i've been kicking around a lot of ideas of things to do with ipython
> notebook: while the bulk of stuff is clientside, to get there, i think i
> need to do custom cells, which is a little more than ellisonbg's
> "jsonhandlers" branch does. further, as the specific capabilities exposed
> will require some pretty big depndencies (pdf generation, numpy, etc.) I am
> thinking about doing everything as python modules that are installed into
> the environment, rather than as purely drop-in javascript assets.
>
> i've started the work on github here:
> https://github.com/bollwyvl/ipython/tree/custom_cells
>
> and a strawman cell provider here (does not contain working code, though it
> does load!):
> https://github.com/bollwyvl/ipython/tree/blockly
>
> any insight is welcome!

Can you talk more about the usage cases you have for new cell types?
Can you give examples?

The notebook document format is sort of our contract with the
universe.  We want to be able to have an extremely precise and
testable definition of what constitutes an IPython notebook, so that
everyone can open them, share them, convert them, run them etc.  If we
allow custom cell types, all of that goes out the door, so I don't see
how we can support custom cell types.  The notebook document format
would stop being the notebook document format.

But, I would like to learn more about your usage cases.  There might
be other ways of supporting what you want to do:

* Use an existing cell type with metadata.
* Provide a custom UI for an existing cell type but don't change the
notebook format.
* Actually add a new cell type to the notebook format officially if it
is something that a majority of our users would use often.

> to get my stuff in, i have used the setuptools iter_entry_points method I am
> familiar with... and defined a new entry_point, ipnotebook. plugins provide
> their list of assets and where one might find their static paths. can anyone
> comment on how this is (potentially) different from The IPython Way? The
> extensions stuff in the doc didn't look like they would be useful, so i gave
> up on trying to use that.

I am very interested in learning more about this.  Right now my
jsplugins/handlers branch uses a pretty simple way of installing
additional Js code = a user just drops it into a special dir in the
.ipython directory.  It would be nice if these Js plugins were regular
python modules that could be installed as usual.  But something to
keep in mind:

* 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.
* Some plugins don't have any python code so I am not sure it makes
sense to bundle things into a python package.
* We need to maintain the ability to install ipython without setuptool.

Do you have ideas on how we can improve the user experience of
installing and managing Js plugins?

> the structure of working with cells in master is pretty rigid right now,
> with the enumerated list of cells type in the code explicitly in the front
> end in several places, js and html. my initial work (in a addition to
> inadvertently recreating some of ellisonbg's work on the tornado app) has
> been to refactor all of those cases of adding buttons or whatever into
> something that looks at a window.IPython-scope plugin registry.... this is
> defined in cell.js right now, but maybe should be someplace else.

That rigidity is merely a reflection of the notebook format.

> after i did discover ellisonbg's stuff, i saw the most recent work was on
> dependencies... during my stuff, i will look into frontend and backend asset
> managers: require.js and webassets come to mind. this would have the
> pleasant benefit of clearing up some of the mathjax complications, and would
> make plugin development a lot more robust, if not simpler... also, if a user
> installed the kitchen sink of plugins, which started adding a lot of
> javascript assets, ideally a user should not see significant notebook
> slowdown until they were actually using new features.

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:

https://github.com/ipython/ipython/wiki/IPEP-5:-Javascript-structure-and-testing

This is very much a draft, but let's move this forward before we jump
in so we know where we are headed.

> looking forward to working on this over the holidays, and would love to have
> some fun things to show come 2013!

Great!

Cheers,

Brian

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



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