8000 macosx broken on python 3.4 non-framework builds, shaky on framework · Issue #3367 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]
Skip to content

macosx broken on python 3.4 non-framework builds, shaky on framework #3367

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
efiring opened this issue Aug 14, 2014 · 14 comments
Closed

macosx broken on python 3.4 non-framework builds, shaky on framework #3367

efiring opened this issue Aug 14, 2014 · 14 comments
Labels
OS: Apple status: upstream fix required
Milestone
v1.4.0

Comments

@efiring
Copy link
Member
efiring commented Aug 14, 2014

To reproduce: on Mavericks with Anaconda 2.0.1, python 3.4, Anaconda's default mpl 1.3.1, in ipython:

%matplotlib
import numpy as np
import matplotlib as plt
plt.plot(np.random.randn(10000))

This brings the plot up in a window that cannot even be resized.
I made a modified version of ipython the ipython script:

efiring@manini2:~/anaconda/envs/python3/bin$ diff ipython ipythonf
1c1
< #!/Users/efiring/anaconda/envs/python3/bin/python3

---
> #!/Users/efiring/anaconda/envs/python3/python.app/Contents/MacOS/python

and with this, the plot seems OK, except that it doesn't always register the "enter" event; when the window is selected, moving the cursor from outside to inside sometimes triggers interactivity (the cursor position is shown when inside the axes), but sometimes it doesn't. Moving the cursor inside more slowly seems to help, but it is not very predictable. This flakiness is confirmed with mpl 1.4.0rc3 using homebrew python3.4 with pip-installed ipython; these now link to the framework build.
I was not successful in building mpl from git in the Anaconda environment; shared libraries were not found. Therefore I have not tested the rc3 with the Anaconda default python 3.4.
@efiring efiring added this to the v1.4.0 milestone Aug 14, 2014
@tacaswell
Copy link
Member

@mdehoon any thoughts?

If we are going the drop-osx-backend route, I assume we should only do it for python3?

@efiring
Copy link
Member Author
efiring commented Aug 14, 2014

Although it is better on 2.7, I think it still has known problems and major limitations with non-framework builds. Abandoning it would be unfortunate--it is the only interactive backend that is always available on the Mac, without requiring installation of some other enormous and problematic package (e.g., TkTcl, PyQt4, PySide).

@efiring
Copy link
Member Author
efiring commented Aug 15, 2014

Progress: it seems that Anaconda is inconsistent, and the intention is for ipython to be run under a framework, but this is not yet happening in 3.4. Chris Barkier and I are still arguing for the framework simply to be the standard python there, so that the ipython script would not have to do anything special, wx apps would work, etc.

@efiring
Copy link
Member Author
efiring commented Aug 15, 2014

@mdhoon, the "flakiness" that I noted even with the framework python occurs in 2.7 and 3.4--but only when the cursor is moving between my terminal window and the plot window, not when it enters the plot window from the desktop background. So, there is some sort of interaction between the terminal app and the plot window. It is in the "minor irritation" category, but if you can think of a way of fixing it with a small change in the macosx backend, that would be good.

@efiring
Copy link
Member Author
efiring commented Aug 15, 2014

@mdhoon, another question: Is there an easy way to detect at runtime whether mpl is in a python framework build? If there is, then at the very least a warning could be generated if the macosx backend is loaded.

@WeatherGod
Copy link
Member

I have a vague recollection of attempts to detect the framework build back
during the sprints for SciPy 2013. Maybe there is something in the mailing
list archives on that?

On Thu, Aug 14, 2014 at 8:15 PM, Eric Firing notifications@github.com
wrote:

@mdhoon, another question: Is there an easy way to detect at runtime
whether mpl is in a python framework build? If there is, then at the very
least a warning could be generated if the macosx backend is loaded.

—
Reply to this email directly or view it on GitHub
#3367 (comment)
.

@mdehoon
Copy link
Contributor
mdehoon commented Aug 15, 2014

@efiring : Previously we had a runtime check to see if Python is a framework build, but it turned out not to be reliable; see issue #665 . In Python 2 there is a MacOS module that can be used instead:
$ python
Python 2.7.6 (default, Jan 20 2014, 14:59:13)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import MacOS
MacOS.linkmodel
'framework'

but this module has disappeared in Python 3:
$ python3.4
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import MacOS
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named 'MacOS'

Currently we are checking at compile-time whether we have a framework build (by checking for WITH_NEXT_FRAMEWORK in the C code; this variable is declared in pyconfig.h).
Since Python 2.7 and 3.2, the information in pyconfig.h is accessible from Python through the sysconfig module. So there we can do:

import sysconfig
print(sysconfig.get_config_var('WITH_NEXT_FRAMEWORK'))
1

Do we still support Python 3.0 and 3.1? If so, somebody needs to check which of these methods work there. If not, then we can use these methods to check at run-time if we are using a framework build.

It would be good also if you guys can also check if these methods give the correct answer on your machines.

@mdehoon
Copy link
Contributor
mdehoon commented Aug 15, 2014

@efiring : I have not noticed any flakiness with the macosx backend with regular python. If this problem occurs with ipython only, the origin may lie there.

@tacaswell
Copy link
Member

< 8000 a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/ivanov/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/ivanov">@ivanov sorry to keep bothering you, Ybut you are a known ipython/mpl connection. Can you bring this to the attention of the proper people in ipython land?

@efiring
Copy link
Member Author
efiring commented Aug 15, 2014

@mdehoon,

  1. We do not support Python 3.0 or 3.1, so using sysconfig is OK.
  2. Homebrew python 3.4.1 yields
In [2]: print(sysconfig.get_config_var('WITH_NEXT_FRAMEWORK'))
1

but Anaconda 2.7 and 3.4 both yield 0. Presumably this means that even though Anaconda 2.7 has a python.app, it is somehow not a true framework build.
I note that homebrew sysconfig.get_config_var('CONFIG_ARGS') includes '--enable-framework=/usr/local/Cellar/python3/3.4.1/Frameworks' but Anaconda's does not.
3) The "flakiness" that I mentioned--the interaction with the terminal, in which moving the cursor from the terminal into the plot window doesn't always activate the interactivity of the plot window--occurs from the plain python prompt, so it is not an ipython-specific problem. It might be related to my terminal configuration, which includes "focus follows mouse" for moves from one terminal window to another.

[TAC, edit to fix medhoon's user id]

@efiring
Copy link
Member Author
efiring commented Aug 15, 2014

I have removed the release_critical label because I think the Anaconda-specific problem will be solved promptly by Anaconda. There are still a bunch of problems floating around:

  1. The interaction with terminal. Minor. One can live with it.
  2. Possible problems in setting default backend: It doesn't look like we can sort all this out quickly, if at all, so I don't think it should block a release.
  3. Ipython problem on Mavericks with qt: severe, and affects us badly, but it looks like entirely an ipython problem at this point; it occurs even when mpl has not been imported.

@efiring
Copy link
Member Author
efiring commented Aug 15, 2014

The revised Anaconda ipython for 3.4 is out, and it works.

@efiring
Copy link
Member Author
efiring commented Aug 15, 2014

Regarding problem 3 above, see ipython/ipython#6189.

@tacaswell
Copy link
Member

This seems to have been a combination of up-stream issues. I am tagging at as such an closing as the ipython PRs have been merged and anaconda builds have been updated.

@tacaswell tacaswell mentioned this issue Aug 17, 2014
Closed
@tacaswell tacaswell mentioned this issue Sep 5, 2014
Closed
@cbrnr cbrnr mentioned this issue Nov 23, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
OS: Apple status: upstream fix required
Projects
None yet
Milestone
v1.4.0
Development

No branches or pull requests
4 participants
@efiring @mdehoon @tacaswell @WeatherGod
0