Remi Rampin

Using an older version of the library would mean that some modules don't work. This is unavoidable, but IMHO better than having VisTrails report that these modules "don't exist". But...

The former; "dynamic" means no Python source generation. Of course it's not "truly dynamic" if generating from the _static_ intermediate files.

After the discussion in today's meeting: @rexissimus will try and come up with a nice wrapping system, with intermediate representation (but w/o Python code generation?) and use it for VTK...

Looks to be related somehow to the upgrade logic (or submodules?)

File is [histogram.xml from DAT](https://github.com/VisTrails/VisTrails/blob/1a1f08d08a613de3b7464fe454f3b1e99341b173/vistrails/packages/matplotlib/dat-plots/histogram.xml)

There is indeed a Group involved.

Also, the remapping functions (passed as function_remap, src_port_remap, etc) don't get the controller, which leads to weird workarounds like the [global _controller in vtk's upgrade code](https://github.com/VisTrails/VisTrails/blob/9b8bc082bcd540cb687dea9b7a109d0d99ddc67d/vistrails/packages/vtk/init.py#L200-L210). But I don't know...

Ok, I added some of the d3.js examples to examples/web/   

> I see why you want to have the user control which files need to be accessible from the local web server in the general case. However, I wonder if...

What is sent is already a rich-text version the output, such as the _string_ `` plus eventually some HTML for those objects which have rich IPython representation (via `_repr_html_()` methods)....