OSX framework detection

Development matplotlib-devel
#1

I don’t know much about Anaconda, but since this is hardcoded in macros, the only way I see this failing
is if they somehow incorrectly define WITH_NEXT_FRAMEWORK in pyconfig.h without actually building
the framework. Though, if I understand correctly, Anaconda provides a framework version of the interpreter
pythonw and a non-frameworked python? But matplotlib is probably only built against one of them, thus
not getting the correct header version…

Cheers,
          Derek

···

On 15 Aug 2014, at 10:39 pm, Eric Firing <efiring.ocean@...149...> wrote:

On 2014/08/15, 9:37 AM, Derek Homeier wrote:

Just to make sure I understand - this is about whether the MPL macosx
backend would run with non-framework Python at all? It certainly
should not, as _macosx.m has been enforcing an error in this case for
some versions. That put aside, when I disable the error at the end of
_macosx.m I found the OSX backend to still work as it used to under
OS X 10.9 with the Fink Python installation (which is not built as a
framework, and unfortunately unlikely to change in foreseeable time).

It sounds like whatever mechanism _macosx.m has been using to determine whether it is running inside a Python Quartz app, does not work in all cases--I gather it works with Fink, but it certainly does not with Anaconda. Any idea why, and how this might be fixed? Wx does detect this correctly, and refuses to run if in a script invoked with Anaconda's python rather than pythonw, for example. (As an aside, wx is not available yet for python 3 except in phoenix development daily builds, so my comment above is based on a test some time ago with python 2.7)

#2

Hi Derek,

···

the framework. Though, if I understand correctly, Anaconda provides a framework version of the interpreter

pythonw and a non-frameworked python?

This is right – the GUI backends to matplotlib cause python to crash, but not pythonw. This is annoying, since the two binaries

are equivalent under most other python installs. E.g. the mac system python manpage reads:

To support multiple versions, the programs named python and pythonw now

just select the real version of Python to run, depending on various set-

tings. (As of Python 2.5, python and pythonw are interchangeable; both

execute Python in the context of an application bundle, which means they

have access to the Graphical User Interface; thus both can, when properly

programmed, display windows, dialogs, etc.)

So people don’t usually think to invoke different anaconda python commands, leading to unexpected crashes (especially when using tools like pytest, which invoke python, run a test that needs MPL, and crash).

This definitely seems like Anaconda’s problem rather than matplotlib’s (it affects any program that tries to import Qt, e.g.)

chris

#3

Hi Chris,

the framework. Though, if I understand correctly, Anaconda provides a framework version of the interpreter
pythonw and a non-frameworked python?

This is right -- the GUI backends to matplotlib cause python to crash, but not pythonw. This is annoying, since the two binaries
are equivalent under most other python installs. E.g. the mac system python manpage reads:

     To support multiple versions, the programs named python and pythonw now
     just select the real version of Python to run, depending on various set-
     tings. (As of Python 2.5, python and pythonw are interchangeable; both
     execute Python in the context of an application bundle, which means they
     have access to the Graphical User Interface; thus both can, when properly
     programmed, display windows, dialogs, etc.)

So people don't usually think to invoke different anaconda python commands, leading to unexpected crashes (especially when using tools like pytest, which invoke python, run a test that needs MPL, and crash).

well, the way it is currently designed to would be to ‘crash’ resp. exit with an error right on starting up the
non-framework interpreter. But besides that it’s curious that its python actually crashes with the macosx
backend, which I have never seen with Fink’s non-framework Python. Just tested this with 1.4.0rc3 and
Python2.7 (previously with 1.5.x HEAD in Python3.4), and it works the same - the same little quirks,
but no signs of performance or stability problems.

This definitely seems like Anaconda's problem rather than matplotlib's (it affects any program that tries to import Qt, e.g.)

So it affects other backends besides macosx or even all? Yes, this seems to be rather Anaconda-specific.
I’ve looked for anything special in the build options, but besides adding the right include and linker paths
there isn’t really anything.

Cheers,
          Derek

#4

Just to make sure I understand - this is about whether the MPL
macosx backend would run with non-framework Python at all? It
certainly should not, as _macosx.m has been enforcing an error in
this case for some versions. That put aside, when I disable the
error at the end of _macosx.m I found the OSX backend to still
work as it used to under OS X 10.9 with the Fink Python
installation (which is not built as a framework, and
unfortunately unlikely to change in foreseeable time).

It sounds like whatever mechanism _macosx.m has been using to
determine whether it is running inside a Python Quartz app, does
not work in all cases--I gather it works with Fink, but it
certainly does not with Anaconda. Any idea why, and how this might
be fixed? Wx does detect this correctly, and refuses to run if in
a script invoked with Anaconda's python rather than pythonw, for
example. (As an aside, wx is not available yet for python 3 except
in phoenix development daily builds, so my comment above is based
on a test some time ago with python 2.7)

I don�t know much about Anaconda, but since this is hardcoded in
macros, the only way I see this failing is if they somehow
incorrectly define WITH_NEXT_FRAMEWORK in pyconfig.h without actually
building the framework. Though, if I understand correctly, Anaconda
provides a framework version of the interpreter pythonw and a
non-frameworked python? But matplotlib is probably only built against
one of them, thus not getting the correct header version�

Not exactly. Anaconda builds python without the --enable-framework option, and then somehow makes their own python.app directory and binary. Their bin/python has no connection to framework things; their bin/pythonw and bin/python.app point to an executable inside their framework directory, which is also named python.app, but is of course in a different location. No clue as to why they do it this way; they might have had a good reason. In any case, WITH_NEXT_FRAMEWORK is not defined in sysconfig. Nevertheless, when I was running their buggy ipython, which was being run with python rather than pythonw (or equivalent), matplotlib was *not* objecting to using the macosx backend--it was the default--and it was not segfaulting, but neither was it producing usable plot windows.

They have fixed their ipython on python 3, so now the osx backend works.

Eric

···

On 2014/08/15, 10:53 AM, Derek Homeier wrote:

On 15 Aug 2014, at 10:39 pm, Eric Firing <efiring.ocean@...149...> > wrote:

On 2014/08/15, 9:37 AM, Derek Homeier wrote:

Cheers, Derek
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel