-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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.
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
optionally create pythonw link in virtualenv for framework python builds on osx #54
Comments
note, possibly duplicates #47, but the issue there is a bit more muddier.
|
+1 on this. What is the ".Python" directory that wants linking in Instead, I see this:
This bug manifests in various ways: http://stackoverflow.com/questions/3692928/why-doesnt-the-save-button-work-on-a-matplotlib-plot |
* makes Framework bundle virtualenvs play nicer with OSX widgets * based on work at https://github.com/gldnspud/virtualenv-pythonw-osx * Needs code review (fragile, path based, uses tmpfiles) TODO: * What is the general fix for this for non-Framework installs?
The reason there was no |
shouldfix: creating a virtualenv from an OSX Framework build should no longer require XCode to run successfully. implementaion: if ``install_name_tool`` missing, download binaries from macosxforge, and install them to a temp directory rejected: download and compile .c source. TODOS: * review for python2/3 issues * cleanup of tempfiles? Assume the system will do it? * test for robustness * review implications of not having XCode for packages, if any * integrate with pypa#54 pull or its descendents. (trivial) Possible Test Code: #!/bin/sh deactivate # virtualenv on system (Framework) python # assuming I have XCode or ``install_name_tool`` in path. python virtualenv.py t_install_name_tool # creates with no issue t_install_name_tool/bin/python -c "" # remove it from path sudo mv /usr/bin/install_name_tool{,2} # should create with no issue, using tmpfile python virtualenv.py t_tmp_install_name_tool t_tmp_install_name_tool/bin/python -c "" # clean up sudo mv /usr/bin/install_name_tool{2,} command rm -rf t_{,tmp_}install_name_tool
shouldfix: creating a virtualenv from an OSX Framework build should no longer require XCode to run successfully. implementaion: if ``install_name_tool`` missing, download binaries from macosxforge, and install them to a temp directory rejected: download and compile .c source. TODOS: * review for python2/3 issues * cleanup of tempfiles? Assume the system will do it? * test for robustness * review implications of not having XCode for packages, if any * integrate with pypa#54 pull or its descendents. (trivial) Possible Test Code: #!/bin/sh deactivate # virtualenv on system (Framework) python # assuming I have XCode or ``install_name_tool`` in path. python virtualenv.py t_install_name_tool # creates with no issue t_install_name_tool/bin/python -c "" # remove it from path sudo mv /usr/bin/install_name_tool{,2} # should create with no issue, using tmpfile python virtualenv.py t_tmp_install_name_tool t_tmp_install_name_tool/bin/python -c "" # clean up sudo mv /usr/bin/install_name_tool{2,} command rm -rf t_{,tmp_}install_name_tool The original patch was cleaned up, tested against at Python 2.5, 2.6, 2.7, 3.2, and verified to work. Signed-off-by: Yesudeep Mangalapilly <[email protected]>
A fix for this in sight? I still have the issue with shy Matplotlib windows |
This issue is 4,5 years old and requires ugly hacks to make matplotlib run on Mac OSX. Can we please fix this? |
I second this. I installed python 2.7 and then created virtualenv using following commands:
But I get following message when I try to import
Workaround mentioned by @nils-werner works. But its huge blocker for beginners who want to work with matplotlib(not only) in jupyter notebook in virtualenv. I wrote detailed guide how to work around this issue, http://blog.rousek.name/2015/11/29/adventure-with-matplotlib-virtualenv-and-macosx/ |
Ugh....... I just hit this as well, following an upgrade to matplotlib 1.5 (which now fails to import a backend, as documented above by @stlk). I'm using a brew installed python 3.5. |
Was going through an intro to visualization using python chapter, and I can't even begin writing the first code sample in jupyter because I keep hitting this issue on a mac... I'm using the system python that comes with mac + virtualenv. |
+1 |
+1 |
For the mean time, the utility that’s linked in this issue (and on the FAQ) still worked for me: $ # install the utility
$ pip install git+https://github.com/gldnspud/virtualenv-pythonw-osx.git
$ # enter the virtualenv with virtualenvwrapper (or manually)
$ workon my-venv
$ # double-check that this is your venv Python binary
$ which python
/Users/macbook/.virtualenvs/my-venv/bin/python
$ # fix it, using magic
$ fix-osx-virtualenv `which python`/../.. Yes, it’s quite simple, but took me a while to figure out. I have no idea what this does, but as a result Matplotlib works by simply invoking it using that venv Python binary – no need for a wrapper shell function. |
I know this solution but:
|
It doesn't feel like an ideal solution, but an easy workaround is to use virtualenvwrapper and then use the hooks to configure things. Install virtualenv-pythonw-osx and virtualevnwrapper, source the virtualenvwrapper.sh file in order to create the hook scripts, then add the following to the
This will automatically fix any virtual environment when you activate them via the |
+1 |
1. Exposed matplotlib scatter plot API to the user via kwargs 2. added large scale scatter plot support 3. parameterized heatmap streaming aggregator In progress: 1. bar chart is still in progress TODOs: 1. need to remove numpy dependency 2. need to support customizable view style 3. need to support user defined point size for large scale plot
+1 |
1 similar comment
+1 |
Just hit this bug, too. The workaround suggested are not exactly elegant. Would be great to get fixed! |
Try changing the matplotlib backend to get matplotlib to work in a virtual environment: There are (at least) two solutions I've used, with some additional methods included below. Both outlined here should to the same thing with a slightly different approach: If you already installed matplotlib using pip on your virtual environment, you can... 1. Add a new matplotlibrc file for your virtual environment
Write _OR_ 2. Edit the matplotlibrc file referenced by your virtual environment
Note/Update: if you get a syntax error in your virtual environment, you might need to simply run:
This displays the matplotlibrc file referenced by the matplotlib package in your virtual environment. Follow the path and open the matplotlibrc file. Edit the file's [Also - A third approach]
(see sources below for further explanation and additional methods) Sources: |
@wwp3 Great write-up, thanks! I have had good luck with this option:
|
Working on improving the Matplotlib docs for this issue @stlk any objections to using part of your guide for the fix to the Jupyter notebook issue (We already have the terminal python/ipython covered ) |
@jenshnielsen Feel free to use it, I'm happy it's helpful. |
+1 |
Is this solved? If so, can someone close the issue? |
It's not |
Absolutely not. It is worse than ever before as it crashes on
|
Is there a PR that fixes this? If so, have the people encountering the issue tested it and confirms that it resolves the problem? If there isn't, is anyone working on one? It's going to be more or less impossible for anyone who can't reproduce the issue (which needs, I guess, an OSX installation at a minimum to do) to develop a fix, so we're relying on contributions here. @nils-werner thanks for the clear description of how to reproduce. If you could add environment details (all I see in the thread is "OSX", but nothing specific about whether it's all versions, what version of virtualenv and python and how they were installed, whether certain other things need to be installed, how to install them, etc) that would be helpful as well. Then hopefully someone with access to a suitable environment can produce a PR and reference it here. At that stage, we can review the PR and take it from there. |
@pfmoore I have been using the workaround in my earlier comment, which still consistently works for me. – Though I’m not sure how that works. Also see the following comment by @nils-werner. (For the record: OS X 10.11.6, Python 3.5.2, matplotlib-1.5.3.) |
@nils-werner The only reason it's worse it that we explicitly check for a framework build before running the OSX backend in Matplotlib https://github.com/matplotlib/matplotlib/blob/master/src/_macosx.m#L3071 The alternative is a soft failure where the gui is only partially functional. WXPython has a similar check build in which prevents you from using WXPython from a non framework build. The best workaround is to use venv from the standard library if you are using python3 |
OK, so I guess if no-one is working on a PR, the resolution here is either:
Cool. I'm not sure if it's worth leaving the issue open in that case - there's a clear workaround, and any code fix would be a new PR anyway. I suggest we close the issue - comments? |
Any updates on this? It would be nice to have this fixed instead of having to use workarounds. |
@wwp3 Great, thanks! I successfully fixed it with this option:
$ cd ~/.matplotlib |
@stlk that was helpful thank you |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Just add a comment if you want to keep it open. Thank you for your contributions. |
Your first solution is so great and have solved my problem. Thx! |
http://groups.google.com/group/python-virtualenv/browse_thread/thread/83fa4a12d22a30c8/744e19c194f1618a?#744e19c194f1618a details how wxpython might be enabled for python on OSX in virtualenvs by analogy with the way it currently works for win32 and cygwin installation modes.
Ian's previous discussion along these lines is here:
http://groups.google.com/group/python-virtualenv/browse_thread/thread/b119a3c26aa49238
and the code that does it at the moment is listed here:
http://github.com/gldnspud/virtualenv-pythonw-osx/
Can we get this baked into the core distribution? What would need to change about the approach?
The text was updated successfully, but these errors were encountered: