8000 Add documentation about working in virtualenvs to the Matplotlib faq by jenshnielsen · Pull Request #5179 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content

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

Merged
merged 10 commits into from
Oct 21, 2015

Conversation

jenshnielsen
Copy link
Member

The writing could probably still use some work.

In the framework error message within the OSX backend
============

When running :mod:`matplotlib` in a virtual environment you may discover a
few issues. :mod:`matplotlib` itself works problemless in virtual envirnments.
Copy link
Member

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." ?

@tacaswell
Copy link
Member

attn @mdehoon

@tacaswell tacaswell added this to the next point release (1.5.0) milestone Oct 4, 2015

When running :mod:`matplotlib` in a virtual environment you may discover a
few issues. :mod:`matplotlib` itself works problemless in virtual envirnments.
However, the GUI frameworks that :mod:`matplotlib` depends uses for interactive
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete "depends"

@jenshnielsen
Copy link
Member Author

@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

<https://github.com/pypa/virtualenv/issues/54>`__ and `here
<https://github.com/pypa/virtualenv/issues/609>`__

Until this is fixed a work around is needed. The best known work around,
Copy link
Contributor

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

@efiring
Copy link
Member
efiring commented Oct 5, 2015

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 --system-site-packages as a viable option. My impression is that this is a route to hard-to-debug trouble. This is just an impression based on thrashing around with virtualenv a few months ago, after which I gave up on --system-site-packages, and concluded that virtualenv was not worth the fuss for any mpl gui other than tkagg.

some familiarity with the Matplotlib backends as found in :ref:`What is a
backend? <what-is-a-backend>`.

If you only use the ``IPython/Jupyter`` inline and ``notebook/nbagg`` backends
Copy link
Member

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.)

Copy link
Member Author

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.

@jenshnielsen
Copy link
Member Author

I agree about the --system-site-packages I was trying to hint something about that in the original comment but have made it more clear now. I still think we need to comment on it because it's mentioned in a lot of docs/posts on the internet.

@matthew-brett
Copy link
Contributor

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?

@jenshnielsen
Copy link
Member Author

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

@matthew-brett
Copy link
Contributor

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?

< 8000 span data-view-component="true">

@matthew-brett
Copy link
Contributor

Does the OSX backend work better in conda environments?

@jenshnielsen
Copy link
Member Author

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 PYTHONHOME workaround

@jenshnielsen
Copy link
Member Author

We can consider changing it to a warning if people prefer that?

Introduction
============

When running :mod:`matplotlib` in a virtual environment you may discover a
Copy link
Member

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:

https://docs.python.org/3/library/venv.html

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you get this?

Copy link
Member Author

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

@mdboom
Copy link
Member
mdboom commented Oct 6, 2015

This is good. Reminds me why I sometimes want to throw Macs across the room, but I think this will be very helpful.

@matthew-brett
Copy link
Contributor

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.

@jenshnielsen
Copy link
Member Author

@matthew-brett It seems like conda envs work correctly so I have updated the document to reflect this

@jenshnielsen
Copy link
Member Author

@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

@jenshnielsen
Copy link
Member Author

Anything else I need to do here? I think the question of warning vs error should be handled outside this PR

@mdboom
Copy link
Member
mdboom commented Oct 19, 2015

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.

@jenshnielsen
Copy link
Member Author

I have added the links to the virtualenv docs and a link to an alternative workaround

@mdboom
Copy link
Member
mdboom commented Oct 21, 2015

Thanks!

mdboom added a commit that referenced this pull request Oct 21, 2015
Add documentation about working in virtualenvs to the Matplotlib faq
@mdboom mdboom merged commit 0672154 into matplotlib:v1.5.x Oct 21, 2015
@jenshnielsen jenshnielsen deleted the virtualenvdocs branch November 9, 2015 09:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
0