sorry, my initial setup of digest makes it hard to get at the thread <br>structure directly, so hopefully this gets in the right place.<br><br>the feedback has been very good, impressive community (and product, of course) <br>
you have built here!<br><br> > * We need to maintain the ability to install ipython without setuptool.<br><br>whoa, very "there is no spoon." just went back and read some tickets that <br>mention setuptools/distutils. will respect the community's desires, here!<br>
<br>so i guess, if primarily-javascript packages *were* to be installed via python, <br>the IPython Way could be to have some %load_ext cells at the <br>beginning of the notebook that would somehow change the static <br>lookup path at runtime. i'll revisit my investigation of the extensions! once <br>
there is one example like this, it should be easy to repeat the pattern.<br><br> > Before we start actually coding on the require.js stuff or<br> > reorganizing that stuff, we need to figure out what we want to do<br>
> exactly. Here is an IPEP for us to work all of that out:<br><br>thanks for the pointer to the IPEP5, very good scope! while i am learning to <br>love node, i might avoid bringing in the node dependency until <br>
someone really has that itch to scratch... i could imagine the 0mq layer being <br>perfect for interacting between python and node... under the correct conditions.<br><br>ghost.py can handle the testing requirements, though it will crank up the <br>
travis test runs by a pretty serious amount, due to the installation of qt and <br>friends... ah! but The Other Notebook already uses qt, so maybe this isn't as <br>bad of a hit. here's the ghost.py .travis.yml that is the recipe i have used<br>
for getting it running:<br><br> <a href="https://github.com/jeanphix/Ghost.py/blob/master/.travis.yml">https://github.com/jeanphix/Ghost.py/blob/master/.travis.yml</a><br><br>having node around to do npm might not actually meet the needs of <br>
the notebook plugin builder (see below)... webassets looks good, but doesn't <br>handle the dependency tree. tough choices ahead.<br><br> > * We have to serve these files on the web. I don't want to have our<br>
> web server walking all over a users system to pull files as that is a<br> > huge security risk. We need to isolate the location of these files.<br><br>yes, definitely a concern... need to wrap my head around this... what makes the <br>
most sense? options:<br><br>- copy stuff into the ipython location<br> - seems bad<br>- have multiple static_paths<br> - my current implementation, relies on runtime setuptools<br>- collect all static deps into a tmpdir which only contains the files needed<br>
- has potential...<br><br> > * Some plugins don't have any python code so I am not sure it makes<br> > sense to bundle things into a python package.<br><br>indeed, i have fought with this demon a few times, most recently with apache <br>
allura's homerolled asset management system. putting my sysadmin hat on, <br>i'd have the fewest dependency management systems possible... apt-get/yum + pip.<br>it's an immediate turnoff if i have to do much more than that. packaging as <br>
python does have the whole pypi advantage, though.<br><br>of course, what could end up happening is that the plugins would have versions <br>as well, and it could be that two different .ipynb's you wanted to look at <br>
would use different versions. this suggests, perhaps, that the plugins should <br>be installed into the notebook itself, which also chills me to the bone. <br><br>i guess we need to understand how a user would want to use these... definitely <br>
have to do more thinking.<br><br> > But, I would like to learn more about your usage cases. There might<br> > be other ways of supporting what you want to do:<br> > 1) Use an existing cell type with metadata.<br>
> 2) Provide a custom UI for an existing cell type but don't change the<br> > notebook format.<br> > 3) Actually add a new cell type to the notebook format officially if it<br> > is something that a majority of our users would use often.<br>
<br>my long-term vision is to build on what mathematica/jmp/tableau can do: support <br>freeform exploration by a developer/researcher/student of a data-driven <br>problem, which gradually solidifies into a dashboard (for lack of a better <br>
term) that allows an end user to play in a constrained data space, but access <br>advanced features.<br><br>while getting there, i want to better be able to document what i am thinking <br>about it one, context-switching-free space that versions/merges well.<br>
<br>i never thought of doing anything that would do (3): i am indeed <br>sensitive to the long-term viability of data formats, and want to do whatever i <br>can to avoid contributing to "data death"... all the stuff i want to do is very <br>
web-focused (for both UI and output), and is therefore inherently text-based... <br>it might just be Really Boring text if you are at the command line (hi, SVG!). <br>i was thinking about it primarily from a UI point of view, the current <br>
implementation of which centers around the IPython.Cell subclasses... so <br>basically what i want is what you describe in (2).<br><br>my use cases for custom cells are sort of summed up (mostly as <br>implementation ideas) in this ticket on my "write some d3 visualizations with <br>
blockly" project:<br><br> <a href="https://github.com/bollwyvl/blockd3/issues/10">https://github.com/bollwyvl/blockd3/issues/10</a><br><br>but here's some riffing on what i've learned in the last 24 hours :) <br>
<br>use cases:<br><br>- VisualCodeCell <a href="http://code.google.com/p/blockly/">http://code.google.com/p/blockly/</a><br> - motivation<br> - i've helped students reach the the "a ha" moment with <br>
blockly's spiritual ancestor, scratch, but feel like the problems <br> that python is able to tackle are much greater. i see the ipython <br> notebook as a great home for the blockly python functionality, as it <br>
can be learned by the absolute novice... when i was a python novice, <br> i think i had the "a ha" moment about five years ago when i learned <br> about tab completion and ? and ?? in the ipython console!<br>
<br> i have been experimenting with blockly (which can generate python) a <br> good deal, but exclusively for javascript. presently blockly is kind <br> of lame for a python workflow.<br>
- implementation<br> - CodeCell. blockly xml would fit nicely inside cell metadata, which i have yet to explore, but need to!<br> - challenges<br> - the downside here is that any editing of the python outside of the <br>
web environment (or if you didn't have the ipython-blockly plugin i <br> envision), the blockly environment can't reverse-engineer its xml <br> from python. however, since blockly is more aimed at the novice, this <br>
might not cause that much of an issue.<br>- DiagramCell <a href="http://code.google.com/p/svg-edit/">http://code.google.com/p/svg-edit/</a><br> - motivation<br> - i love me some svg... it is deeply ingrained in my day-to-day design <br>
and communication workflow with inkscape, and has become increasingly <br> important from my web application development tasks with the meteoric <br> rise of d3. svgedit is Almost As Good as inkscape, and for a lot of <br>
things i want to do, it would be sufficient for a lot of quick <br> vector-based documentation things that i'd want to attach.<br> - implementation<br> - MarkdownCell<br> - challenges<br>
- none, really<br>- SpreadsheetCell <a href="https://github.com/bollwyvl/blockd3/issues/SlickGrid">https://github.com/bollwyvl/blockd3/issues/SlickGrid</a><br> - motivation<br> - some data really is tabular. i would love to be able to whip up a <br>
quick table (not using markdown!) and then pop that into a numpy <br> calculation chain.<br> <br> also, being able to quickly walk around higher-order numpy arrays <br> would be great, suggesting an excel-like sheet navigation for a given <br>
array.<br> - implementation<br> - CodeCell. perhaps some metadata for formatting<br> - challenges<br> - not trying to implement Resolver One here, but a little bit of <br> functions would be cool... i like some of the things that the google <br>
spreadsheet has done to blow out a calculation into a bunch of cell <br> from input into one cell<br>- TangleCell <a href="http://worrydream.com/Tangle/">http://worrydream.com/Tangle/</a><br> - motivation<br>
- the tangle reactive document paradigm is awesome. i have done some work with integrating this with markdown, but it never felt right, <br> and took a lot of `exec` to work properly, which always gave me the <br>
willies. writing constraints directly on the backend and then just <br> tying them to frontend in markdown seems like the high road.<br> - implementation<br> - MarkdownCell<br>- ControlCell<br>
- motivation<br> - sometimes, i just want a button or a slider for changing a value.<br> - implementation<br> - CodeCell. metadata.