On 2014/08/15, 10:53 AM, Derek Homeier wrote: > On 15 Aug 2014, at 10:39 pm, Eric Firing <efiring.oc...@gmail.com> > 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) > > 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 > > Cheers, Derek > ------------------------------------------------------------------------------ > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > ------------------------------------------------------------------------------ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
