Move all pyvista specific code into pyvista

[PeterPyPan]

It is currently impossible to use the core of the pymeshfix without installing pyvista. It is true that using pip install pymeshfix --nodependencies will not install pyvista (see #16 ), but this is not possible when pyvista is part of a requirements.txt file for example. Also, we don't want no dependencies at all, we just don't want any unnecessary dependencies for the core of the library (like pyvista, depending on imageio, appdirs, scooby, meshio and vtk).

To me it seems backwards that pymeshfix has a pyvista interface at all, and this code is not just included into pyvista. pymeshfix could be specified as a pyvista requirement and all plotting and vtk interfaces could be implented at the pyvista side.
This would imo be much more logical because you will not have to deal with any optional requirements anymore. If you want to use the core of pymeshfix, you just install pymeshfix. If you want to use a pyvista interface and fix meshes and plot them, use pyvista, which includes pymeshfix as a utility.

Is there any reason why pymeshfix is not a dependency of pyvista?

I really believe the functionality in pymeshfix is very useful. However, the unnecessary dependency of pyvista will push away people that are only looking for a way to fix meshes or perform mesh validity checks.

I would be willing to contribute and create a pull request for both pymeshfix and pyvista with the necessary changes.

[banesullivan]

Is there any reason why pymeshfix is not a dependency of pyvista?

It's all because of the license on MeshFix. See #7 and a similar details in pyvista/pyvista#240

[banesullivan]

To me it seems backwards that pymeshfix has a pyvista interface at all, and this code is not just included into pyvista.

Indeed, it is incredibly backwards. I would recommend emailing the creators of the original MeshFix software to let them know your thoughts on their license choice and how it's hindering adoption and usage of the software.

See https://github.com/MarcoAttene/MeshFix-V2.1

[akaszynski]

I'm actually of the opinion of keeping each module as independent as possible. While pymeshfix is quite useful, it's not applicable for all users and any additional dependencies tend to cause issues during CI/CD. Even meshio, a pure python module, has had issues in the past with certain versions of Python. Adding pymeshfix into the mix, which must be compiled, might also lead to installation issues upon the release of Python 3.9 should we be late on updating the build scripts.

The pyansys module is another example. It's heavily reliant on pyvista for unstructured grids, but most pyvista users won't regularly use ANSYS MAPDL, so there's no reason to include it as a dependency within pyvista. Doing so would invite integration hell to our doorstep, and I have enough of that with my day job :)

---

I really believe the functionality in pymeshfix is very useful. However, the unnecessary dependency of pyvista will push away people that are only looking for a way to fix meshes or perform mesh validity checks.

This was actually a tough choice to make. VTK isn't a light dependency, and they were a year late for a Python 3.8 release (and will probably be for Python 3.9). I could remove pyvista as a hard dependency and then raise an ImportError when attempting to plot the mesh. Still, since pyvista works for 3.5 - 3.8 for all three major OSes, I'm not sure it's necessary at this point to remove it.

[banesullivan]

Also, PyVista is already a soft dependency here... it's listed in the requirements.txt for the development install when testing and building documentation. As a consumer of this package, you shouldn't touch that file. Simply rely on pip for the install with pip install pymeshfix --nodependencies

pymeshfix/pymeshfix/meshfix.py

Lines 10 to 14 in b673532

	try:
	import pyvista as pv
	PV_INSTALLED = True
	except ImportError:
	PV_INSTALLED = False

[banesullivan]

I suppose we could make different extras dependency options in the setup.py so that if a downstream project wants to depend on pymeshfix without pyvista they could do that... but it would go against #16 (comment)

because you cannot have --no-depends as an option in the downstream project's setup.py

Perhaps we have a [all] option for installing PyVista and all its glory and leave the default without it? This will be up to you @akaszynski as it may provide us a headache with more users complaining that PyVista wasn't installed than this scenario

[akaszynski]

Perhaps we have a [all] option for installing PyVista and all its glory and leave the default without it?

Perhaps, but that might still violate meshfix's license as you mentioned. I think adding an [all] option would be nice though, and perhaps including some advanced examples on the pyvista docs page.

[banesullivan]

To clarify, that [all] option would be for pymeshfix not pyvista - adding pymeshfix to pyvista's deps list (optional or not) and/or including pymeshfix in any examples there would violate the terms of the license

[PeterPyPan]

Thank you for the discussion and clarification on the issues with the MeshFix license. My first thought was indeed to make pyvista an extras_require option. But I understand that for normal python users, it is not common to install a package with ‘pip install pymeshfix[all]’.

Another option could be to split the pymeshfix package into 2 subpackages: pymeshfix-core and pymeshfix-vista. The pymeshfix.core would only contain the wrappers of MeshFix and any pyvista related functionality would be in pymeshfix.vista. This subpackage structure creates 2 wheels pymeshfix-core and pymeshfix-vista and can have their own required dependencies. These 2 packages are separated on pypi, but once installed they act as submodules from the same pymeshfix package.

[PeterPyPan]

Also, PyVista is already a soft dependency here... it's listed in the requirements.txt for the development install when testing and building documentation. As a consumer of this package, you shouldn't touch that file. Simply rely on pip for the install with pip install pymeshfix --nodependencies

pymeshfix/pymeshfix/meshfix.py

Lines 10 to 14 in b673532

	try:
	import pyvista as pv
	PV_INSTALLED = True
	except ImportError:
	PV_INSTALLED = False

If pyvista is specified in the setup.py file under install_requires (which is the case), it is not a soft dependency. I agree that if pyvista is not installed, the code treats it as a soft dependency, but as a package, pymeshfix has a hard requirement on pyvista.

If I want to create a library that depends on pymeshfix, there is no way the users of my library can install my library using pip install <my_library> --nodependencies to end up with an environment that has pymeshfix, but not pyvista.

[banesullivan]

Fair point... it'll have to be up to @akaszynski on whether we split this up into a pymeshfix-core (no pyvista) and pymeshfix (pyvista) modules to help folks like you depend on the software without PyVista and its stack.

[banesullivan]

On further thought, I'm not terribly opposed to just making PyVista an optional depend in pymeshfix's setup.py. In most cases, it seems folks already have PyVista installed before installing pymeshfix so it wouldn't be all that bad

[akaszynski]

It wouldn't be too hard to split up pymeshfix-core and pymeshfix, it's just a matter of finding time to.

[banesullivan]

Yeah, I sure do not have the time to help with splitting it up. I'd be in favor of just dropping the pyvista depend for the sake of time/effort and having a clear notice in the installation instructions that people probably also want pyvista. e.g.:

From PyPI:

pip install pymeshfix pyvista

[akaszynski]

Maybe that's best. Just a simple ImportError for those who want to do advanced visualization.

[PeterPyPan]

If that would be helpful, I can create a PR with the changes in the setup file and changes in the readme.

[akaszynski]

That's ok. There's more than just the setup changes as I need to run unit testing without installing pyvista and it's a non-trivial fix.