variants

[tpaviot]

Comment:

Alghouth occt is available in both vtk and notvtk versions, which makes sense, pythonocc doesn't wrap the vtk part of occt. As a consequence, there's no need to take the variants into account for pythonocc build, only the 'novtk' build should be performed.

[Krande]

Hey @tpaviot!

Your point is definitively valid as the build matrix is quite big when compiling against both variants.

The reason for compiling pythonocc-core against both 'novtk' and 'all' variants of occt was to provide an alternative for anyone who wants to use pythonocc-core AND that directly or indirectly through other packages might rely on the VTK compilation options of occt.

In hindsight I've come to think that my assumption about the number of users that need the VTK capabilities in occt AND also uses pythonocc-core might be unfounded. And if these options are needed, it might be better to rely on self-compiled packages in a dedicated anaconda channel.

If @looooo agrees, then I would support limiting the next release of pythonocc-core to just the 'novtk' variant.

[tpaviot]

@Krande I understand your point of view, after opening this issue I realized some users might need to download the vtk pythonocc variant if ever occt-vtk is already used by another package. That makes sense. If the "no vtk variant" is kept as default, then it's ok, no need to change anything to the build matrix, unless you're concerned with energy consumption on the azure cloud side!