matplotlib-devel Mailing List for matplotlib

On 2014年08月15日, 10:53 AM, Derek Homeier wrote:
> On 15 Aug 2014, at 10:39 pm, Eric Firing <efi...@gm...>
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>