These are chat archives for ipython/ipython

25th
Sep 2014
Jason Grout
@jasongrout
Sep 25 2014 00:00
and suppose I wanted a special type of link that converted values to the types expected? Like hooking up a float slider with a textbox, where we want to convert types?
Or, of course, I could do any sort of other transformation of the data. I can now encapsulate all of that in a sort of link widget that's easily handled in python.
Thomas Kluyver
@takluyver
Sep 25 2014 00:01
well, if you want to write it in Python, then the values have to round trip through the kernel
Jason Grout
@jasongrout
Sep 25 2014 00:02
right; but I could write it in javascript too.
to keep things working on a static page
Thomas Kluyver
@takluyver
Sep 25 2014 00:02
if you want to write it in JS...I'm not sure, but I think we should say that's out of scope until we can focus on these issues more clearly
Jason Grout
@jasongrout
Sep 25 2014 00:02
but I suppose you could generalize the link metadata to have adapters of some sort.
Thomas Kluyver
@takluyver
Sep 25 2014 00:02
I don't think widgets should become a generic framework to construct JS applications
at least, not yet
Jason Grout
@jasongrout
Sep 25 2014 00:02
I guess we're quickly getting to the point where widgets are packages of js code.
Thomas Kluyver
@takluyver
Sep 25 2014 00:03
yes, with oh-so-convenient hooks to load them from the kernel
Jason Grout
@jasongrout
Sep 25 2014 00:03
right, like you said. However, some trivial JS linking goes a long way.
Thomas Kluyver
@takluyver
Sep 25 2014 00:03
but I don't think that means we should accomodate doing all sorts of crazy things in widgets just because it's convenient
the widgets are there to sync models between frontend and kernel, not to build complex JS applications which can be saved as a document
Jason Grout
@jasongrout
Sep 25 2014 00:04
allowing, accommodating, encouraging, supporting, and mandating are different things. Perhaps it should still be allowed.
Thomas Kluyver
@takluyver
Sep 25 2014 00:05
allowed is fine, but that doesn't require saving things into the notebook format
Jason Grout
@jasongrout
Sep 25 2014 00:05
the javascript link originally was built because the round-trip time latency was sad for very trivial linking
Thomas Kluyver
@takluyver
Sep 25 2014 00:05
if it's merely allowed, I'm fine with saying "you have to rerun the notebook to get all this stuff working" - that's going to be the experience with most widgets anyway
simple linking might be in scope, but I'm wary of trying to do things like that via a backbone model
Jason Grout
@jasongrout
Sep 25 2014 00:06
anyways, It's probably fine to have display(link(...)) be a euphemism for "persist this thing!". A little annoying, but understandable.
for us. probably confusing for others, anyway :).
Thomas Kluyver
@takluyver
Sep 25 2014 00:07
yeah, I'm not convinced about that, either
then link has both an inappropriate model and an inappropriate view
Jason Grout
@jasongrout
Sep 25 2014 00:07
see the hoops you're making us jump through :)
Thomas Kluyver
@takluyver
Sep 25 2014 00:08
:P
Jason Grout
@jasongrout
Sep 25 2014 00:10
anyways, gotta run.
Thomas Kluyver
@takluyver
Sep 25 2014 00:10
OK
see you
Thomas Kluyver
@takluyver
Sep 25 2014 00:46
When I run the JS tests, I see a bunch of errors like:
    uncaughtError: "function () {
        return this.evaluate(function () {
            return IPython._status == 'idle';
        });
    }" did not evaluate to something truthy in 10000ms
anyone else seen that?
Jessica B. Hamrick
@jhamrick
Sep 25 2014 00:49
Which part of the js tests?
I’ve been seeing some errors like this in js/notebook, but they’re not actually test failures:
Page Error!
line 2 of evaluate
line 4 of evaluate
line 4 of evaluate
ReferenceError: Can't find variable: IPython
Thomas Kluyver
@takluyver
Sep 25 2014 00:51
looks like all parts of it
I was just running js/widgets
I see those error messages as well
Jessica B. Hamrick
@jhamrick
Sep 25 2014 00:52
Hmm, I haven’t seen your error in js/notebook, but I’ll run js/widgets and see if they show up there
Thomas Kluyver
@takluyver
Sep 25 2014 00:52
js/tree runs OK, but I see the same errors in js/notebook
Jessica B. Hamrick
@jhamrick
Sep 25 2014 00:52
Ah ok, I probably won’t see them in js/widgets then
Thomas Kluyver
@takluyver
Sep 25 2014 00:52
it looks like it's having trouble starting websockets
ah, I bet it's websocket protocols
I think tornado 4 only supports something newer than what phantom supporst
maybe there's a newer version of phantom I can use
nope, looks like I have the latest
yep, downgrading tornado fixed it
though I do still see those other warnings
Thomas Kluyver
@takluyver
Sep 25 2014 00:58
ipython/ipython#6542
Jessica B. Hamrick
@jhamrick
Sep 25 2014 01:04
Huh, looks like it sometimes is associated with an error: https://travis-ci.org/ipython/ipython/jobs/36212663#L4845
(Actually I think that error will go away if the test is rerun, but clearly something happened to cause it to spew all those messages)
Thomas Kluyver
@takluyver
Sep 25 2014 01:06
hmm, I bet those errors are coming from the condition that it's testing
if IPython never gets created, then it evaluates that condition again and again, showing those errors each time, until eventually it times out
Jessica B. Hamrick
@jhamrick
Sep 25 2014 01:11
That makes sense
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 03:13
@takluyver I just updated PR #6532 - doing what you advised.
Nicholas Bollweg
@bollwyvl
Sep 25 2014 14:01
sorta related to #6542... has anyone built casper tests as notebooks?
Jason Grout
@jasongrout
Sep 25 2014 15:28
In thinking more about widget persistence and the document format---it would be helpful if we could explicitly say to save a certain model. It doesn't have to be by default, but perhaps a persist=True key could trigger it.
Jonathan Frederic
@jdfreder
Sep 25 2014 16:22
@jasongrout I think that could work, but we still have an argument about where, if anywhere, notebook level models should be stored
If we use @minrk 's approach, would we just append it to the first cell?
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 16:35
@takluyver Regarding your description of what we are doing, I would not have worded it better! We don't want to make the whole system part of IPython, just that we would like that IPython's infrastructure does not forbid it.
(cf comment in PR #6454)
sometimes, an unexpected application or use of a technology is what makes it popular
Jessica B. Hamrick
@jhamrick
Sep 25 2014 16:57
Is there a meeting today?
Min RK
@minrk
Sep 25 2014 16:57
yup
spinning up now
Jonathan Frederic
@jdfreder
Sep 25 2014 16:57
ugh I hate this, I hear it ring, but no notifications show
Thomas Kluyver
@takluyver
Sep 25 2014 17:05
@SylvainCorlay making it possible is fine, but I think the saving and restoring piece is much more ambitious than what we want to do with the notebook format
I think the saving applications piece should be built outside or maybe on top of the notebook file format, at least for the moment, not into the notebook format itself
and I don't think the non-widget-widgets, like link, belong in IPython
Jason Grout
@jasongrout
Sep 25 2014 17:11
me too!
:)
Kyle Kelley
@rgbkrk
Sep 25 2014 17:40
URL if you want to try it out
(for now)
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 17:46
Sorry that I could not join. The Google call is "full" but listening on youtube
Jonathan Frederic
@jdfreder
Sep 25 2014 17:47
If you can find @jasongrout , you could sit in with him, he is in the call.
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 17:47
Yeah, cannot attach 2 headphones - don't know why I wrote keyboard
Jonathan Frederic
@jdfreder
Sep 25 2014 17:48
ah
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 17:55
Rather than implementing checkpoints, why not let people work of integration of their favorite version control into the web app?
Generally, in the case of Large output / image displayed in the notebook, their could be a threshold / warning to the user
Kyle Kelley
@rgbkrk
Sep 25 2014 18:03
Lost internet completely. :(
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:04
well apparently not
Kyle Kelley
@rgbkrk
Sep 25 2014 18:04
and I'm back
Can someone send me the hangouts link?
Kyle Kelley
@rgbkrk
Sep 25 2014 18:04
ha
video call full
Too popular today
Thanks @SylvainCorlay
:)
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:05
Kyle Kelley
@rgbkrk
Sep 25 2014 18:05
Well, I'm at least going to say one thing.
Now that I've been working more directly with the team and understand more of the architecture
It's time for me to jump into that section, do another custom store.
And revisit those pain points, raise them in issues in PRs.
Now that we're booked up, if someone wants to get in that can't I can jump out
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:09
There is some delay on the youtube video
I like on_bulk_change. Atomic is confusing
hey, can I join the call
Adrienne Wantulok
@awantulok
Sep 25 2014 18:11
Internet keeps going in and out so someone else can jump in my place.
Kyle Kelley
@rgbkrk
Sep 25 2014 18:12
cool, thanks
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:13
still full
Jessica B. Hamrick
@jhamrick
Sep 25 2014 18:14
@SylvainCorlay I see your icon in the call, so maybe it thinks you’ve joined even if you haven’t?
Kyle Kelley
@rgbkrk
Sep 25 2014 18:15
thats weird
I see you in there
Matthias Bussonnier
@Carreau
Sep 25 2014 18:19
@minrk @SylvainCorlay this is javscriptique : https://github.com/letsgetrandy/brototype
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:20
guys sorry, got disconnected again
Jonathan Frederic
@jdfreder
Sep 25 2014 18:20
Can @jasongrout @SylvainCorlay hear us?
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:20
I missed most of the meeting
could not hear Thomas' reply sorry
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:27
besides the discussion on hipchat vs github. Is there an alternative to google hangout ?
Kyle Kelley
@rgbkrk
Sep 25 2014 18:28
Appear.in
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:28
yeah, but no image and not mic
andrewjchen
@andrewjchen
Sep 25 2014 18:28
Damian Avila
@damianavila
Sep 25 2014 18:29
I don't have good experiences with appear.in
didn't
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:31
@takluyver regardless of persistence, any issue with the idea of view-less model?
Thomas Kluyver
@takluyver
Sep 25 2014 18:35
I'm finding it hard to reason about without a use case that I think it's suitable for
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:35
the link is one usecase.
Thomas Kluyver
@takluyver
Sep 25 2014 18:36
but I think a viewless model is completely the wrong way to implement a link
because it's not a model
Jonathan Frederic
@jdfreder
Sep 25 2014 18:37
I've used viewless models before just to synchronous variables between JS and Python
Thomas Kluyver
@takluyver
Sep 25 2014 18:37
oh, in the JS RPC thing you did at Scipy?
What was that called again?
Jonathan Frederic
@jdfreder
Sep 25 2014 18:37
nah that thing was only Comms
Thomas Kluyver
@takluyver
Sep 25 2014 18:37
aha
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:38
A widget is not a model, it has a model.
Thomas Kluyver
@takluyver
Sep 25 2014 18:38
yeah, but a widget as the term is generally used is a GUI element, i.e. a view
which makes even less sense for a link
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:38
We agreed that Widget was a bad name.
Jonathan Frederic
@jdfreder
Sep 25 2014 18:39
Lets call them XObjects!
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:39
It could be called ClientObject
Jonathan Frederic
@jdfreder
Sep 25 2014 18:39
X - like cross python javascript
but seriously, ClientObject seems like a good option
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:39
@jdfreder yes, I had already typed it. I like XObject
Thomas Kluyver
@takluyver
Sep 25 2014 18:40
but this is about more than the naming. The widget framework is designed to solve the problem of synchronising state between kernel and frontend, and displaying a visual representation of that state
Min RK
@minrk
Sep 25 2014 18:40
And when they do things, like move around, they could be called 'Active', or 'ActiveXObjects'
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:40
:D
Jonathan Frederic
@jdfreder
Sep 25 2014 18:40
Haha @minrk
Thomas Kluyver
@takluyver
Sep 25 2014 18:40
what you're talking about is a fundamental reworking of what the entire widget framework does, and that's something that, if we do attempt it, should at least be left until after 4.0
Jonathan Frederic
@jdfreder
Sep 25 2014 18:41
Well we could s/Widget/ClientObject and s/DOMWidget/Widget
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:41
the renaming is fundamental reworking?
Agree with jdfreder
Thomas Kluyver
@takluyver
Sep 25 2014 18:42
the renaming isn't, but you want to solve a much broader problem than the widget framework is intended to do
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:42
it works pretty well :)
Thomas Kluyver
@takluyver
Sep 25 2014 18:42
look at it this way: a Widget on the frontend consists of a Model, a Comm, and if you display it, a view
Link creates a Model and a Comm, neither of which it actually uses
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:43
it uses it on creation and destruction of the link
Thomas Kluyver
@takluyver
Sep 25 2014 18:43
and we were thinking about adding a completely useless view
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:43
we don't want to add a view, we want completely viewless model!
Thomas Kluyver
@takluyver
Sep 25 2014 18:43
but it's not a model!
and it's not communicating
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:43
XObject
Thomas Kluyver
@takluyver
Sep 25 2014 18:44
changing the name doesn't magically change the way it's been designed
WidgetModel inherits from backbone's Model class
Jonathan Frederic
@jdfreder
Sep 25 2014 18:44
I think in a way it is a model, it just represents a single boolean - does the link exist or not
linkwidget.delete is like setting that to false
Thomas Kluyver
@takluyver
Sep 25 2014 18:44
no
by that argument, you could claim absolutely anything was a model
it's just a component of an application
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:45
What is bad about being multi paradigm? Not every widget is stateful, and therefore not every widget needs to synchronize data.
Like the button,
Thomas Kluyver
@takluyver
Sep 25 2014 18:46
so we have comms, and we have custom messages, and yes, things like Button kind of stretch the definitions a bit
Jonathan Frederic
@jdfreder
Sep 25 2014 18:46
Or the textbox submit event
Thomas Kluyver
@takluyver
Sep 25 2014 18:46
but button still uses the comm and the view, just not the model part
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:47
link uses the comm and has no view.
Thomas Kluyver
@takluyver
Sep 25 2014 18:47
Link really uses nothing besides the comm opening event
Jonathan Frederic
@jdfreder
Sep 25 2014 18:47
But it could
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:47
on comm open, there is info on the widgets to sync
Thomas Kluyver
@takluyver
Sep 25 2014 18:48
but this doesn't need a comm - you could do display(JS(...)) to create something
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:48
Yes, but I need a comm to close it.
All the job of referring to the client object is handled via the widget infrastructure.
Thomas Kluyver
@takluyver
Sep 25 2014 18:50
comms are not there to make Python's garbage collection affect JS. If you can use them like that, then great, but this doesn't belong in IPython.
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:52
hum, by close I mean unlink
Thomas Kluyver
@takluyver
Sep 25 2014 18:52
again, a generic remote object layer for JS sounds fascinating, and if you can build it on top of IPython, I'd love to see that, but it's not what the widget infrastructure is designed for, and I don't want to try to bolt it on in a hurry
if you want to do that inside IPython, it needs a full design and implementation cycle, not a quick renaming of one or two classes
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:53
I don't think that it is what we are asking, just to not put limitations designed to forbid it.
Thomas Kluyver
@takluyver
Sep 25 2014 18:55
and again, we're happy not to forbid that - but it shouldn't go into IPython at the moment, and we shouldn't design widget persistence around it
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 18:56
The feature looks like a byproduct of the current design of persistence of widgets (persisting model states). Which is great!
(still not willing to fly to ny on friday ;) )
Thomas Kluyver
@takluyver
Sep 25 2014 18:57
I'm hazy on what the current design is - I'm trying to avoid the need for a notebook level UUID-keyed blob of widget data
if viewless models are OK to create, but we're not dealing with them in core IPython at the moment, we can get away with not persisting them, which I suspect makes life easier
(of course, if you want to write custom code that stores that in metadata or in a sidecar file, that's fine - but I don't want to bake more complexity than we need to into the specified nbformat)
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 19:00
Ok, then you are fine with #6532 ? it is your solution after all
Thomas Kluyver
@takluyver
Sep 25 2014 19:01
yep
I may also make Widget() throw an error in Python, but that needn't be part of that PR
I think that's fine as stands
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 19:02
ok, I don't mind Widget() raising an error.
Jonathan Frederic
@jdfreder
Sep 25 2014 19:02
Makes sense to me
epifanio
@epifanio
Sep 25 2014 19:04
Hi, i’m tring to run the leaflet widget (on master, with python2) but i can’t have it running, .. i want try to debug, how can i check which profile is actually being used and which (path) custom.js is loaded ?
Sylvain Corlay
@SylvainCorlay
Sep 25 2014 19:06
ok, as soon as it is merged, we will update the controversial link PR to reflect that in the design. (And also fix the on('destroy') clean up)
Thomas Kluyver
@takluyver
Sep 25 2014 19:06
@epifanio you can see the profile using get_ipython().profile
as for custom.js, I think you'll need to use browser debug tools to see that
epifanio
@epifanio
Sep 25 2014 19:13
yes that’s why i was asking .. seems the profile showed in the js console is not the one i was passing by command line
i use in the command line : --ipython-dir=/home/epilib/Envs/env1/.ipython
then when i load the notebook in the browser and I check the console i see : Uncaught SyntaxError: Unexpected token }
at line 69
that is in the custom.js that is in my home : /home/epinux/.ipython not the one i gave from command line : /home/epilib/Envs/env1/.ipython
i can temporary try to remove the .ipython dir from my home and see if something changes
Thomas Kluyver
@takluyver
Sep 25 2014 19:16
it could be a bug - we don't try overriding --ipython-dir at the command line very often
epifanio
@epifanio
Sep 25 2014 19:23
moving out the .ipython dir from my home changed the logs, now they looks like http://paste.debian.net/123101/
the last one is the leaflet one when i run : initialize_notebook()
the others are related to other extensions, i didn’t had them before . so i need to check. seems there is confusion on which ipython dir is loaded and which extension
epifanio
@epifanio
Sep 25 2014 19:31
yes, it gaves a 404 on a missed nbextension dir , also if I have it in : /home/epilib/Envs/env1/.ipython (provided by commandline)
but i had a copy of it in my home … sop I didn’t notoced that before. I guess the leaflet issue .. is because the js are in /home/epilib/Envs/env1/.ipython/nbextension/ but it was looking for them in my home/.ipython
Thomas Kluyver
@takluyver
Sep 25 2014 19:32
aha
sounds like there might be a bug somewhere, unless it's browser caching of JS again
epifanio
@epifanio
Sep 25 2014 19:42
i tried on firefox, on that browser i can remove cache and history and try it again
epifanio
@epifanio
Sep 25 2014 19:51
I can confirm it, i removed the full cache/history from firefox then from then this the log from the terminal : https://gist.github.com/e9535e908060363d051c
epifanio
@epifanio
Sep 25 2014 19:59
i’ve access to an other computer when i can do the test again
in the meintime i can try to make a fresh .ipython dir in my home and install the leaflet plugin into it, i guess that should fix the problem in loading it.
thanks!
epifanio
@epifanio
Sep 25 2014 20:41
i tried the leaflet widget using the standard ipython directory in my home but still having trouble : https://gist.github.com/41a681f3e43c77d27ca3 i have all the files inplace now
@ellisonbg is this my fault or should I open an issue on the widget repository ?
Thomas Kluyver
@takluyver
Sep 25 2014 20:46
@jdfreder @SylvainCorlay @jasongrout : I had a new idea about widget persistence over lunch. Well, new to me, anyway - you may have already thought about it.
Jonathan Frederic
@jdfreder
Sep 25 2014 20:46
?
Thomas Kluyver
@takluyver
Sep 25 2014 20:46
The two extremes of saving widgets would be:
  1. Just save an ID where the view is, and only rebuild the widget if the kernel knows that ID - so widgets are persisted for a refresh, but not if you kill the kernel.
  2. Save the model contents where each view is, and reconstruct a static representation of the widget with no connection to the kernel
This message was deleted
This message was deleted
Jonathan Frederic
@jdfreder
Sep 25 2014 20:49
There's an edit pencil icon you can click to change your gitter messages :)
Thomas Kluyver
@takluyver
Sep 25 2014 20:50
there you go
what if we stored both together? So when loading a notebook, it queries the kernel for each model ID, and reconnects the dynamic widget if it can; if not, it just builds the snapshot.
Where 'snapshot' can include arbitrary JS interactions within the widget (e.g. connected subwidgets in a container), but links to widgets elsewhere in the document are broken
Jonathan Frederic
@jdfreder
Sep 25 2014 20:52
That's how the widget persistence PR works now, except it stores the data at the notebook level.
Thomas Kluyver
@takluyver
Sep 25 2014 20:52
OK
storing the data at the notebook level is part of what I'm trying to avoid
because that's going to be horrible for version control.
Jonathan Frederic
@jdfreder
Sep 25 2014 20:55
I know, I understand that, you have to understand my position too. Models in the live notebook live independent of the cells, even the cell that creates them. Saving the notebook such that the model data is moved into the cells where the views are feels wrong, especially since at load time the model will just end up at the notebook level again.
But we could make either method work
Thomas Kluyver
@takluyver
Sep 25 2014 20:57
that makes sense, but from an end user perspective, the position of a slider is not an abstract number stored separately from the slider itself
Jonathan Frederic
@jdfreder
Sep 25 2014 20:58
Yes, but does the file format reflect what the end user sees, our how the software actually works?
I guess it depends on how much we value our JSON format being human legible.
Thomas Kluyver
@takluyver
Sep 25 2014 21:01
we're getting at the important questions :)
to which, of course, I don't know the answer
Jonathan Frederic
@jdfreder
Sep 25 2014 21:03
Yes :)
Thomas Kluyver
@takluyver
Sep 25 2014 21:03
I'll keep thinking, and I'm sure there'll be more group discussion about this ;-)
Jonathan Frederic
@jdfreder
Sep 25 2014 21:04
You mean I can't just merge my persistence PR as is? Darn! ;)
Thomas Kluyver
@takluyver
Sep 25 2014 21:06
I know, those big green merge buttons look so tempting
Min RK
@minrk
Sep 25 2014 22:03
I don't think it's super important that the JSON format be human legible, but the spatial relationship is still important when passing through things like diff. Binary blobs (b64 images) make diffing hard, because there are large meaningless chunks, but at least they are spatially confined.
With models being keyed by UUID in a single top-level dictionary, the dict would change ~100% every time, because the location in the file has nothing to do with the location in the document, and even the internal order of objects is randomized because the UUIDs are generated each session. It's basically an arbitrary key-value store, very much unlike traditional output.
If we implemented traditional output as simple references to a key-value store, then I would have probably been more supportive of separate input/output files in the original document format.
Min RK
@minrk
Sep 25 2014 22:09
There is a lot appealing about the 'notebook' document only being structure (list of inputs, with a skeleton of output), and output being a data store of the side effect information.
We decided to put it all in one file, because the only output we supported was simple, mostly-text representations, possibly with some images.
version control gets way easier, load times get way faster, etc.
The massive complexity of widgets seems to violate our fundamental assumptions about the simplicity of notebook output, so I think it makes sense to reconsider the whole thing from scratch.
(unfortunately)
Thomas Kluyver
@takluyver
Sep 25 2014 22:15
do you think we should try to do that reconsidering before 3.0? If not, do we go ahead with the nbformat changes anyway, or hold them until we can think about this more?
Min RK
@minrk
Sep 25 2014 22:19
I don't know - widgets in the file format is a lot more complex than I anticipated.
If it is something like 'new output type' and 'top-level or cell-level model store', we can do that in a minor-format revision
I just need to make sure to define the validation and graceful failure behavior for unrecognized output types (additional unrecognized keys are already handled)
Thomas Kluyver
@takluyver
Sep 25 2014 22:23
adding references to an external store could potentially not break backwards compatibility - e.g. if they used a new output_type = 'reference'
though we couldn't be sure about that until we'd done a fair bit of designing with it
Min RK
@minrk
Sep 25 2014 22:40
right