make meshio optional

[nschloe]

pyvista is lagging behind with meshio dependencies. This is fine, but poses problems in environment where I must use the latest version. I'd hence like to suggest to make meshio an optional dependency of pyvista.

[adeak]

The <5 constraint was added in #621, February 2020. You released 5.0 this August. I think this is just a case of overly cautious version specifications; perhaps it would be better to just remove that constraint from setup.py altogether, and only introduce such version upper bounds when we have a good reason to suspect future breakage.

@pyvista/developers thoughts?

Alternatively, we could set up something like dependabot to tell us about upstream updates so we can bump versions.

[nschloe]

There's soon be another upgrade, and a bigger one, too.

[MatthewFlamm]

PyVista is "3D plotting and mesh analysis through a streamlined interface for the Visualization Toolkit (VTK)".

meshio seems like a useful addition, but not an essential dependency. There are many possible workflows that would not require meshio.

I'm +1 on making it optional.

I like the idea of automated dependabot if there is pinning. I think the pinning strategy should be consistent barring some known incompatibility. For example, numpy isn't pinned to <2.0.0. This seems like a second discussion to me however.

[banesullivan]

I think making meshio optional is a smart move, but I also think letting users load just about any mesh format out of the box between PyVista's VTK readers and meshio's readers is incredibly useful. Plus meshio is pure Python so besides the versioning issues, it's an incredibly lightweight dependency.

I'm wondering if instead, we can come up with a "contract" between PyVista and meshio so that the general interface that PyVista uses stays consistent across versions. @nschloe, would that be a big ask? I may have some bandwidth to help implement such an interface/contract. That way we can just free the meshio dependency and not worry about this moving forward

[nschloe]

I don't think I understand. What do you mean by "contract"?

[nschloe]

Btw, optional dependencies which are installed by default are still to be implemented in setuptools, see

• Add ability to specify "default" extras_require pypa/setuptools#1139
• https://discuss.python.org/t/adding-a-default-extra-require-environment/4898/117
• https://discuss.python.org/t/possible-default-extras-dependency-categories/1537/12

[tkoyama010]

"contract"

I understood this to be creating a data object to be exchanged between meshio and PyVista (@banesullivan Is this right? ). If that is the case, I agree with this idea. I was uncomfortable with the fact that PyVista calls and reads meshio internally. I think the natural flow is to use meshio to load the mesh and then use the data object to visualize it in PyVista.

[nschloe]

I think this is a separate discussion.

[nschloe]

@banesullivan Could you detail on what you mean by "contract"?

[banesullivan]

What do you mean by "contract"?

I understood this to be creating a data object to be exchanged between meshio and PyVista

More or less, yes -- this is what I was getting after.

It is my opinion that meshio and pyvista are in a symbiotic relationship: pyvista gains from meshio's IO support for formats we/VTK do not support and meshio benefits from pyvista providing a simple to use API for plotting and analysis (to do stuff with the data meshio reads).

I'm wondering if we can lock in that relationship and implement a test upstream in meshio that effectively says "hey, this is the way PyVista is using meshio, let's try not to break this part of the API". That way, pyvista can have no limit on the meshio dependency and if the API changes/that test has to change it will be more clear on how to address downstream in PyVista.

and I'm wondering if we can simplify this method as much as possible:

pyvista/pyvista/utilities/fileio.py

Line 582 in a2e9f58

def from_meshio(mesh):

[banesullivan]

In the meantime, I am +1 for merging #1939 and leaving this issue open to figure out how to improve the interoperability between meshio and pyvista

[adeak]

I think pyvista is clearly downstream from meshio. Meshio could do whatever it wants with its meshes. It would be weird for meshio to specifically assimilate like that.

I believe the best we could ask for is a well-defined public API that's hopefully not too unstable (but I'd note that we break things all the time too). We could then test the public API ourselves and find breakage in CI, before any release. Still no pinning needed.

[tkoyama010]

I'm sorry that my argument may have come across as burdensome to meshio. My image is matplotlib for numpy's array object, numpy doesn't need to care about matplotlib (as far as I know), and that's my stance on meshio as well. In any case, it's not something that should be discussed here, so I'll create a new Discussion.

[tkoyama010]

Please discuss in #1946.