Trap D3 runtime version

The version of D3 that gets loaded you first initialize a notebook with py_d3 code in it is obvious: whatever version of D3 you specify in the first %%d3 call in the notebook, or 3.5.11 if you choose not to pin a version then.

Running multiple version of D3 in the same notebook is unsupported, due to the way require.js handles loading (and this is the correct behavior: this has limited utility anyway, and would cause continuous animations, if you have them, to crash).

However, what happens when you reload a pre-existing notebook is less clear. All of the JavaScript on the page gets executed nearly simultaneously, and, near as I can tell, the first version of the D3 library that gets loaded from the CDN is the one that is pinned.

This means that if you declare e.g. %%d3 4.4.4 in a cell at the beginning of the notebook, then use a clean %%d3 later on, the first time you run the notebook every cell will run 4.4.4 code, but every time after that it'll be a lottery (?), with 3.5.11 a likely winner (which will break any of your v.4 code when you try to run it...).

This inconsistent behavior is a very not-nice usability trap. The workaround right now is to always specify the same specific version in all of your %%d3 calls, so that all of the cells "converge" equivalently.

In the long run, this needs to be patched so that behavior is consistent. I think this can be done by exposing a self.initialized variable in the magic initializer. But it needs testing.

ResidentMario / py_d3

Trap D3 runtime version #4