# Deadline for VTK 9.1 RC1 Merge Requests: October 29, 2020
**URL:** https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206
**Category:** Announcements
**Created:** [May 4, 2020, 7:38pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206 "2020-05-04T19:38:27Z")
**Posts on this page:** 18
**Page:** 1
### Author:  [@TJ\_Corona](https://discourse.vtk.org/u/TJ_Corona)
#### Post date: [May 4, 2020, 7:38pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/1 "2020-05-04T19:38:27Z")
To help the VTK community better anticipate VTK’s release schedule, we are posting a feature deadline for the next release cycle of October 29, 2020. We are hopeful that this approach will give the community enough time to better plan their workflows around VTK’s release, and we think it will help keep the release team vigilant about regularly cutting releases in the future. This does not necessarily mean we will not have a minor release until after the posted date, but it does give some assurances that a release will occur soon after the deadline. Please let us know what you think!
---
### Author:  [@Gilthalas](https://discourse.vtk.org/u/Gilthalas)
#### Post date: [May 4, 2020, 7:42pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/2 "2020-05-04T19:42:16Z")
I LOVE THIS. One my of my bigger complaints was not having any insight into when the next release may be…
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [May 4, 2020, 9:08pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/3 "2020-05-04T21:08:37Z")
Yes, not knowing is what ends up with the stampede of “oh, I need this fixed too” MRs after we announce rc1. Hopefully this will allow us to say “sorry, you had 6 months to get this ready” for such things instead of pushing the release back further and further…
Basically, if you have some use case that is not covered by our CI today, _now_ is the time to start that process with a nightly builder or, at the least, an issue to bring it to our attention. I hope to be getting gitlab-ci up and running more of our target setups over the summer.
---
### Author:  [@psandana](https://discourse.vtk.org/u/psandana)
#### Post date: [August 19, 2020, 6:29pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/4 "2020-08-19T18:29:32Z")
Hi everyone,
I was checking some stuff for my work and I notice that IceT is not in VTK, but Paraview. There were plans to migrate from Paraview. Would you accept such changes for VTK 9.1?
This are the references about this topic:
[https://vtk.org/Wiki/Multiple\_views](https://vtk.org/Wiki/Multiple_views)
[https://vtk.org/Wiki/VTK/MultiPass\_Rendering\_With\_IceT](https://vtk.org/Wiki/VTK/MultiPass_Rendering_With_IceT)
I can open a new thread to discuss this further.
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [August 19, 2020, 9:10pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/5 "2020-08-19T21:10:56Z")
To make VTK’s growth sustainable, it would be great if new non-essential features would not be added to VTK core but to remote modules.
---
### Author:  [@psandana](https://discourse.vtk.org/u/psandana)
#### Post date: [August 19, 2020, 9:17pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/6 "2020-08-19T21:17:29Z")
Is there a special meaning for “remote modules”?
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [August 19, 2020, 9:53pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/7 "2020-08-19T21:53:39Z")
Remote modules are VTK modules that are maintained in separate repositories and pulled into the build tree when enabled by setting CMake variables. I remember that @ben.boeckel wanted to get rid of them, but they are essential for keeping size of VTK core in check. There could be other solutions, but this one is proven to work well in ITK and was successfully used for a few modules in VTK, too.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [August 27, 2020, 3:27pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/8 "2020-08-27T15:27:47Z")
> [@lassoan](#):
>
> I remember that @ben.boeckel wanted to get rid of them, but they are essential for keeping size of VTK core in check.
Correct. Just make them projects that depend on VTK just like you depend on Qt, zlib, or any other project. VTK is now much better behaved and being part of VTK’s build doesn’t grant you any special powers over external projects (unlike the old build system).
---
### Author:  [@psandana](https://discourse.vtk.org/u/psandana)
#### Post date: [August 27, 2020, 8:44pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/9 "2020-08-27T20:44:14Z")
Understood. I tried to get it out from Paraview, but it is more complicated than expected. There are a lot of mixed dependencies.
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [August 27, 2020, 9:40pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/10 "2020-08-27T21:40:19Z")
> [@ben.boeckel](#):
>
> Correct. Just make them projects that depend on VTK just like you depend on Qt, zlib, or any other project. VTK is now much better behaved and being part of VTK’s build doesn’t grant you any special powers over external projects (unlike the old build system).
Qt, zlib, etc. are different because they have no interest in VTK. I don’t expect them to help to make life of VTK developers easier.
VTK’s long-term success highly depends on how well suited it as an algorithm/library development platform. If there is no easy way to distribute VTK-based libraries as packages on PyPI then developers will spend their time, effort, and funding on VTK competitors.
It should be already possible to create and maintain VTK-based Python packages but I don’t know about any examples. Please give us a pointer to at least one project that can serve as an example for us to follow.
The best that I could imagine would be if VTK developers would maintain non-essential features in such VTK-based external packages, because we would then have lots of examples, they would be guaranteed to be up-to-date, and interests of VTK core developers would be naturally aligned with interests of VTK-based library developers. It would also make VTK truly modular and much smaller.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [August 27, 2020, 10:08pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/11 "2020-08-27T22:08:02Z")
> [@lassoan](#):
>
> If there is no easy way to distribute VTK-based libraries as packages on PyPI then developers will spend their time, effort, and funding on VTK competitors.
Remote modules only help those who are building their own VTK anyways. Remove modules are not part of the VTK wheels that we publish. If you want remote modules in a wheel, you’re starting from scratch because you’re also building the vtk wheel at that point.
Python really needs to figure out a way to ship headers and SDKs in wheels if they want C++ packages to be used between wheels. VTK can’t ever interact with the h5py wheel except through the Python interface because there aren’t any HDF5 headers for VTK to use when it compiles its HDF5-using code. We’re not going to solve that problem for Python. Anaconda is probably a better route because they do have allowances for SDKs.
> [@lassoan](#):
>
> The best that I could imagine would be if VTK developers would maintain non-essential features in such VTK-based external packages, because we would then have lots of examples
This is what I want long-term, but convincing anyone to maintain the unmaintained bits of VTK while it lives inside is hard enough.
The closest project to doing this is probably the SMTK stack, but there’s a lot of extra things in there to take out before it’s actually an example for that kind of thing.
---
### Author:  [@banesullivan](https://discourse.vtk.org/u/banesullivan)
#### Post date: [August 28, 2020, 1:54pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/12 "2020-08-28T13:54:00Z")
> [@lassoan](#):
>
> It should be already possible to create and maintain VTK-based Python packages but I don’t know about any examples. Please give us a pointer to at least one project that can serve as an example for us to follow.
There are quite a few packages that have followed in the path of making VTK a dependency and relying on it like any other library with great success. To name just a few: [PyVista](https://github.com/pyvista/pyvista) (and [MNE-Python](https://mne.tools/stable/index.html) by extension), [Mayavi](https://docs.enthought.com/mayavi/mayavi/), [Vedo](https://github.com/marcomusy/vedo), and the _many_ projects that depend on those. I can speak for PyVista and its experience relying on VTK this way - while painful at times (mostly from being in the dark about when the next release is coming and frantically trying to make updates for compatibility when it does come, which this thread seeks to resolve), it has worked quite well because there are VTK wheels on PyPI we can count on working (because they aren’t updated often) for most major OS and Python versions and there is a community on conda-forge maintaining a build recipe for VTK. The reality is that most Python 3D visualization consumers do not need the latest features from VTK, and they can get by with VTK 8.1, so these concerns about growth and maintainability are honestly a non-issue from a (perhaps just mine) downstream perspective.
---
### Author:  [@pieper](https://discourse.vtk.org/u/pieper)
#### Post date: [August 28, 2020, 5:02pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/13 "2020-08-28T17:02:35Z")
I’ll just throw this out as an example of where things work great, but could be improved.
A group of us recently developed [trako](https://pypi.org/project/trako/) which leverages point cloud compression from glTF for use in diffusion tractography streamlines with scalar and tensor values per-vertex. One use case is to convert to/from our existing vtk/vtp format. The pypi package works fine for this with vtk as a dependency, but note that we only want to make use of VTK, not provide a superset of functionality that exposes all of VTK, like PyVista or Mayavi.
We did get feedback from a potential user of the format that our package was way too big to use as a dependency.
On investigation, as shown in [this notebook](https://colab.research.google.com/drive/1KhgQtkrhkMnt8yVOe7rR9dzdchqZ8NCC?usp=sharing), even though we are only using a couple reader/writer classes we end up pulling in 327 megabytes of VTK libraries.
It would be ideal if we could just get the small parts of VTK we actually need for this package.
---
### Author:  [@banesullivan](https://discourse.vtk.org/u/banesullivan)
#### Post date: [August 28, 2020, 5:37pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/14 "2020-08-28T17:37:12Z")
> [@pieper](#):
>
> The pypi package works fine for this with vtk as a dependency, but note that we only want to make use of VTK, not provide a superset of functionality that exposes all of VTK, like PyVista or Mayavi.
That’s totally fair
> [@pieper](#):
>
> On investigation, as shown in [this notebook](https://colab.research.google.com/drive/1KhgQtkrhkMnt8yVOe7rR9dzdchqZ8NCC?usp=sharing), even though we are only using a couple reader/writer classes we end up pulling in 327 megabytes of VTK libraries.
I can’t access that notebook to see the full details… however…
I’d propose not using VTK if you’re only using for file IO. There are plenty of alternatives like [meshio](https://github.com/nschloe/meshio) that will likely meet your needs and is pure Python. After all, VTK is a _visualization_ framework and you should only pull it into your stack if leveraging it for viz. Otherwise, I’d highly recommend pursuing other libs for your task to keep your stack lean and clean.
---
### Author:  [@pieper](https://discourse.vtk.org/u/pieper)
#### Post date: [August 28, 2020, 7:43pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/15 "2020-08-28T19:43:07Z")
> [@banesullivan](#):
>
> I can’t access that notebook to see the full details… however…
Sorry about that, [this link should work now[([Google Colab](https://colab.research.google.com/drive/1KhgQtkrhkMnt8yVOe7rR9dzdchqZ8NCC?usp=sharing)).
> [@banesullivan](#):
>
> There are plenty of alternatives like [meshio](https://github.com/nschloe/meshio) that will likely meet your needs and is pure Python
Thanks for the suggestion, I hadn’t considered that. Unfortunately [it appears meshio only supports unstructured grid and not polydata](https://github.com/nschloe/meshio/issues/527). Also it appears they only support `.vtk` and not `.vtp`, which some of our users have been saving in. Plus of course we are used to VTK and switching to a different library would be a big pain.
And again, our use case generally works fine, it’s just that we get a bigger install than we might want. If there were a way to pip install subsets of VTK it might help projects like trako.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [August 31, 2020, 2:53pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/16 "2020-08-31T14:53:53Z")
> [@pieper](#):
>
> And again, our use case generally works fine, it’s just that we get a bigger install than we might want. If there were a way to pip install subsets of VTK it might help projects like trako.
You can make your own wheels with just what you need from VTK by using a build with all the other stuff disabled, but the PyPI installs will almost always be bigger (because, AFAIK, I can’t put part of VTK in one wheel and other parts in other wheels and also guarantee that you don’t mix-and-match the wrong versions/builds together).
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [August 31, 2020, 4:04pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/17 "2020-08-31T16:04:23Z")
> [@ben.boeckel](#):
>
> I can’t put part of VTK in one wheel and other parts in other wheels and also guarantee that you don’t mix-and-match the wrong versions/builds together
That’s exactly why VTK remote modules can be very useful. They make trivially easy for VTK maintainers (and any developer) to build wheels for VTK and all official remote modules using the exact same build environment and build options.
This seems to works nicely for ITK remote modules - see packages uploaded to PyPI by itkrobot: [Profile of itkrobot · PyPI](https://pypi.org/user/itkrobot/).
@thewtex can you comment on how well remote modules are working out for ITK and if you see them as a good solution for developing and distributing algorithms?
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [August 31, 2020, 4:54pm UTC](https://discourse.vtk.org/t/deadline-for-vtk-9-1-rc1-merge-requests-october-29-2020/3206/18 "2020-08-31T16:54:13Z")
Official VTK wheels have no remote modules. I don’t forsee that ever changing. It does support making your own wheels with them, but a plain `pip install vtk` won’t have them.
I’d rather see them just go into VTK or stay out of its repository. It’s code that isn’t under our code review process and my knee-jerk reaction to remote modules breaking our CI is to just turn them off because coordinating changes is not easy (though not breaking API is obviously better here).