-
-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Add documentation about working in virtualenvs to the Matplotlib faq #5179
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
Conversation
In the framework error message within the OSX backend
doc/faq/virtualenv_faq.rst
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"mpl itself has no issue with virtual environments." ?
|
attn @mdehoon |
doc/faq/virtualenv_faq.rst
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
delete "depends"
|
@tacaswell and @efiring Thanks for the prof reading. I have corrected the typos that you spotted. I am also interested in if people thinks this is understandable from a technical point of view? Given that we have added the check to the OSX backend that makes it error out inside a virtual env I think it is very important that we add some docs about it before the release which are understandable. We have already had a few bug reports about this in the rc's |
doc/faq/virtualenv_faq.rst
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"workaround" should be one word : e.g. https://en.wiktionary.org/wiki/workaround
|
I agree that this is needed, and I think it is reasonably understandable. Some writing tweaks could still be made. Regarding the more important aspect, the substance: I'm a little concerned about advocating |
doc/faq/virtualenv_faq.rst
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The inline also needs the backticks, and notebook/nbagg might be notebook or (alias) nbagg. Correct? Otherwise, I have a little trouble parsing this, and realizing that it is very specific; just using the Jupyter notebook, for example, is not enough. This is in contrast to ordinary gui operations, in which using IPython or the notebook tends to solve all problems, regardless of backend. (Well, most, anyway.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I have changed that to hopefully make it more clear.
|
I agree about the |
|
It is completely necessary to error out in a virtualenv for MacOSX backend? Presumably it would in fact work - as it did in 1.4.3? |
|
That was the decision made by @mdehoon and I tend to agree with it. The issue is that the figure window cannot be bought to the foreground and seemingly random parts of the interaction with the figure doesn't work resulting in puzzling bug reports which are hard to debug |
|
Oh dear - that will be a problem for me, I use the OSX backend a lot. How about a non-default rcparam to enable the OSX backend in virtualenvs? |
|
Does the OSX backend work better in conda environments? |
|
AFAIK Conda envs have the same issue. I don't think a RC param to enable something which is fundamentally broken is a good idea. I would suggest to use the |
|
We can consider changing it to a warning if people prefer that? |
doc/faq/virtualenv_faq.rst
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably start with links to what we're talking about.
https://virtualenv.pypa.io/en/latest/
or, in Python 3.3 and later:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you get this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I must have missed this. I will fix if asap
|
This is good. Reminds me why I sometimes want to throw Macs across the room, but I think this will be very helpful. |
|
If conda envs are affected the same way, should note that here? I use the OSX backend very often in light virtualenvs, so any option that allows me to take responsibility for the risk of OSX misbehavior in a virtualenv would be very good. |
|
@matthew-brett It seems like conda envs work correctly so I have updated the document to reflect this |
|
@matthew-brett I don't have any strong opinion if this should be a warning or an error but this PR is only about the documentation |
|
Anything else I need to do here? I think the question of warning vs error should be handled outside this PR |
|
Other than my one inline comment about linking to virtualenv docs, I think this is good to go. I agree, let's keep this documentation-only, and think about warnings vs. exceptions later. |
|
I have added the links to the virtualenv docs and a link to an alternative workaround |
|
Thanks! |
Add documentation about working in virtualenvs to the Matplotlib faq
The writing could probably still use some work.