# ParaView w/ Python 3 on Mac - when?
**URL:** https://discourse.paraview.org/t/paraview-w-python-3-on-mac-when/3083
**Category:** ParaView Support
**Tags:** python
**Created:** [November 30, 2019, 12:38am UTC](https://discourse.paraview.org/t/paraview-w-python-3-on-mac-when/3083 "2019-11-30T00:38:22Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@banesullivan](https://discourse.paraview.org/u/banesullivan)
#### Post date: [November 30, 2019, 12:38am UTC](https://discourse.paraview.org/t/paraview-w-python-3-on-mac-when/3083/1 "2019-11-30T00:38:22Z")
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?
[https://www.paraview.org/download/](https://www.paraview.org/download/)
---
### Author:  [@Kenneth\_Moreland](https://discourse.paraview.org/u/Kenneth_Moreland)
#### Post date: [November 30, 2019, 4:19pm UTC](https://discourse.paraview.org/t/paraview-w-python-3-on-mac-when/3083/2 "2019-11-30T16:19:23Z")
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](https://gitlab.kitware.com/paraview/paraview/issues/19434). This is currently targeted for the ParaView 5.8 release.
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [December 2, 2019, 12:49pm UTC](https://discourse.paraview.org/t/paraview-w-python-3-on-mac-when/3083/3 "2019-12-02T12:49:08Z")
> [@Kenneth\_Moreland](#):
>
> The problem is that the system Python for Mac OS is still Python 2.7
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.
---
### Author:  [@tianyikillua](https://discourse.paraview.org/u/tianyikillua)
#### Post date: [December 2, 2019, 3:45pm UTC](https://discourse.paraview.org/t/paraview-w-python-3-on-mac-when/3083/4 "2019-12-02T15:45:16Z")
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](https://gitlab.kitware.com/cmake/cmake/issues/19226).
---
### Author:  [@Michael\_Jackson](https://discourse.paraview.org/u/Michael_Jackson)
#### Post date: [December 2, 2019, 6:08pm UTC](https://discourse.paraview.org/t/paraview-w-python-3-on-mac-when/3083/5 "2019-12-02T18:08:09Z")
Any possibility for Anaconda? There are several large DoD installations that have standardized on Anaconda as the installed python on Windows/Linux/Mac
---
### Author:  [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [December 2, 2019, 7:00pm UTC](https://discourse.paraview.org/t/paraview-w-python-3-on-mac-when/3083/6 "2019-12-02T19:00:00Z")
@ben.boeckel Would you happen to have a link pointing to Apples plans to not have Python3 on macOS? Thanks!
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [December 3, 2019, 12:32am UTC](https://discourse.paraview.org/t/paraview-w-python-3-on-mac-when/3083/7 "2019-12-03T00:32:59Z")
> [@tianyikillua](#):
>
> We just do not need to link against `libpython` under macOS, just like Linux-like systems
ParaView, the application, and `pvpython` _do_ need to link to it. That logic only applies to the Python modules we build.
> [@Michael\_Jackson](#):
>
> Any possibility for Anaconda?
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`.
> [@wascott](#):
>
> Would you happen to have a link pointing to Apples plans to not have Python3 on macOS?
From Apple itself: [https://developer.apple.com/documentation/macos\_release\_notes/macos\_catalina\_10\_15\_release\_notes](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).
> [@apple](#):
>
> # Scripting Language Runtimes
>
> ## Deprecations
>
> - Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to install additional packages. If your software depends on scripting languages, it’s recommended that you bundle the runtime within the app. (49764202)
>
> - Use of Python 2.7 isn’t recommended as this version is included in macOS for compatibility with legacy software. Future versions of macOS won’t include Python 2.7. Instead, it’s recommended that you run python3 from within Terminal. (51097165)
---
### Author:  [@ben.boeckel](https://discourse.paraview.org/u/ben.boeckel)
#### Post date: [December 3, 2019, 12:41am UTC](https://discourse.paraview.org/t/paraview-w-python-3-on-mac-when/3083/8 "2019-12-03T00:41:08Z")
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).
---
### Author:  [@henry2004y](https://discourse.paraview.org/u/henry2004y)
#### Post date: [December 6, 2019, 3:13pm UTC](https://discourse.paraview.org/t/paraview-w-python-3-on-mac-when/3083/9 "2019-12-06T15:13:57Z")
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.
---
### Author:  [@danlipsa](https://discourse.paraview.org/u/danlipsa)
#### Post date: [December 6, 2019, 3:39pm UTC](https://discourse.paraview.org/t/paraview-w-python-3-on-mac-when/3083/10 "2019-12-06T15:39:53Z")
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.