It looks like the public builds of ParaView 5.7 are shipping with Python 3.7 for Windows and Linux 
but not Mac yet… is there an expected timeline for this?
This is a known issue. The problem is that the system Python for Mac OS is still Python 2.7, which complicates releasing binaries using a different version.
Releasing binaries with Python 3 is being worked on. You can check the status on this bug report. This is currently targeted for the ParaView 5.8 release.
1 Like
And Apple’s future plans is to just remove it. Python3 won’t be part of macOS in the future. I think the best we can do is either ship a Python3 that doesn’t support pip and such (as with our Windows and Linux binaries) or to require usage of the python.org installed Python. Due to the way macOS’ runtime binary stuff works, we have to expect any system Python in a specific place; we can’t work with an “arbitrary” libpythonXY.dylib like Linux and Windows can.
We just do not need to link against libpython under macOS, just like Linux-like systems, see https://gitlab.kitware.com/cmake/cmake/issues/19226.
Any possibility for Anaconda? There are several large DoD installations that have standardized on Anaconda as the installed python on Windows/Linux/Mac
1 Like
@ben.boeckel Would you happen to have a link pointing to Apples plans to not have Python3 on macOS? Thanks!
ParaView, the application, and pvpython do need to link to it. That logic only applies to the Python modules we build.
Not in the official builds. Your own builds will be able to support that. However, due to the same restriction, your Anaconda will be expected in a given location for a build (i.e., no environments). The solution here is to provide a conda forge stock (or whatever it is called) of ParaView and Anaconda users get it via conda install paraview.
From Apple itself: https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_release_notes. Even Python2 is going away in the future (though we don’t care because we won’t support Python2 packages by the time 10.16 is released anyways).
Note that Windows and Linux do support “arbitrary” Python installations with the official packages via LD_LIBRARY_PATH and PATH due to the way libraries are looked up (via the basename, falling back to RPATH entries on Linux). macOS, if you want the binaries to work out-of-the-box, must have absolute paths to dependent libraries. This is fine for ParaView-shipped libraries because we can rely on @executable_path to find them wherever the .app bundle is located. But an external Python must be referenced via /System/Library/Frameworks/Python.framework/Versions/3/Python (I probably typo’d somewhere there).
One can use DYLD_LIBRARY_PATH to override it, however I don’t know if this will work in the long-term on signed applications (e.g., Apple programs and applications already ignore this due to SIP). It also does not work for double-clicking an application, so the GUI would need to be launched from a terminal to work with this at all (assuming the dynamic loader continues to honor the setting for signed applications).
One thing that keep confusing me is what actually is pvpython. Is Paraview.simple just a regular python module? If so then why do we need pvpython as a wrapper over python? I checked the official documents and also searched on Google, but I couldn’t find a clear answer.
pvpython is just python with the correct PYTHONPATH and LD_LIBRARY_PATH passed in. Using a separate executable spares the user of knowing where the python modules and libraries are in the ParaView install or build hierarchy.
There is another more subtle differences because python has all functionality built in while pvpython accesses the python functionality through dynamic libraries but it would work the same most of the time.
1 Like