[vtk-developers] Speeding up `import vtk`

[Ben Boeckel]

[ Yes, this is a necro on this thread, but I'd like to see this happen. ]

On Thu, Sep 08, 2016 at 11:14:21 -0600, David Gobbi wrote:
> As usual, I'm a stickler for backwards compatibility and would rather go in
> the other direction,

How about fixing `vtk` for VTK9? I don't like having it be a separate
module because that means we have to ship things twice and the only
difference is the `__init__.py` file.

Currently `import vtk` (the obvious thing to do) is basically like doing
a `find_package(VTK REQUIRED)` that doesn't support `COMPONENTS`. You
get everything built, but you also have no idea if what you need is
actually present until you get your `AttributeError`.

I'd rather see scripts explicitly request `vtk.FiltersParallel` (or
similar) if they need it rather than just hoping it dumped the right
things into the global namespace. If we want to keep having this
pattern, ParaView's `paraview.simple` module provides everything needed
to "hit the ground running" (though I don't see it as a long-term
maintainable way to use VTK or ParaView via Python). VTK could also have
`vtk.simple` which does this. The problem with having it at the root
level is that it denies any advanced usage of the module which does
request exactly what is required.

With all the other big changes coming in VTK9, I think it would be a
good time to tackle this.

--Ben

P.S. For those curious, this came up because we recently had one module
have more "load commands" than the loader on macOS supports
(vtkPVAnimation) which triggered an `ImportError`. Because `import vtk`
loads all modules, this meant that any loading of `import vtk` was
broken just because this one was, even tests which don't care about it
at all.