You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the discussion of the pull request, @efiring suggested a procedure (#6358 (comment)) that did work after adding one final step. Inside the Conda enviroment you want to develop matplotlib in, the procedure is as follows (mostly copied from @efiring):
Use conda to make a test environment with the desired python version, and use conda to install matplotlib in it.
Use conda to uninstall matplotlib.
In your github clone of matplotlib, make a feature branch, and make the desired changes to it.
In the root of that clone directory run pip install ..
Install the Framework version of python with conda install python.app.
Open a new terminal and activate the conda environment (or run hash -r (bash) / rehash (zsh) in the old terminal to make sure your shell finds the conda version of pythonw instead of the OSX version).
You should not be setting PYTHONPATH that way; there is no need to put site-packages on it because that location is compiled in. If you need to disable your PYTHONPATH that is your own special case, not a general condition for using conda. The same applies to DYLD_FALLBACK_LIBRARY_PATH. I'm sure it doesn't need to be set as you have it for the conda environment, and normally it would not even exist. If it is in your environment then at most you need to unset it when entering the conda environment.
It's not in my regular enviroment. I didn't come up with this myself, this solution is advertized in README.osx:
Note that your environment is somewhat important. Some conda users have
found that, to run the tests, their PYTHONPATH must include
/path/to/anaconda/.../site-packages and their DYLD_FALLBACK_LIBRARY_PATH
must include /path/to/anaconda/lib.
When I first tried your suggestion (steps 1-4 above), I had these variables set and it worked. I then thought that perhaps I could now turn them off again, but when I did, first the freetype lib could no longer be found (which was fixed by setting local_freetype to True in setup.cfg) and when that was fixed libpng started complaining:
I hope we can get this straight and understand what is going on here. I am still pretty sure that having a PYTHONPATH set should not be needed, and I doubt that the DYLD variable is really needed in general either. It would be good to get this sorted out in README.osx as well.
Have you tried my original instructions (that is, with a fresh conda environment) with neither PYTHONPATH nor DYLD_FALLBACK_LIBRARY_PATH set? My guess is that the problem you encountered was a result of having started with those variables set. Otherwise I don't understand why you ran into the ImportError, and I don't. I do have local_freetype set to True in setup.cfg; this is necessary to make the image comparisons with text pass.
@efiring Is it possible that you have some custom built libs that your install finds, e.g. from Macports / Homebrew? I have Macports installed and I see now that I also have libpng there. I tried upgrading libpng, but to no avail.
$ otool -L /Users/patrick/anaconda/envs/mpl_dev3/lib/python2.7/site-packages/matplotlib/_png.so
/Users/patrick/anaconda/envs/mpl_dev3/lib/python2.7/site-packages/matplotlib/_png.so:
libpng16.16.dylib (compatibility version 34.0.0, current version 34.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 2577.0.0)
$ pkg-config libpng --libs
-L/opt/local/lib -lpng16
Seems like it is indeed building against the Macports install, i.e. if it uses pkg-config to find libpng...
As mentioned in #11006 (comment), things seem to have gotten a bit simpler on my most recent try (other machine by now, so clean environment compared to the one used for the above discussion of this issue).
For reference, here's what I need now to get it correctly installed from scratch (inside a clean matplotlib clone):
Having this week made my first matplotlib branch, I must admit I found the developers' installation instructions slightly terrifying! I would have been a lot more comfortable with something conda based, as that's what I'm used to.
I've no idea if this would be realistic for matplotlib, but in iris we have a yml file that defines its dependencies and everything you could possibly need during testing (sample data, sphinx, flake8, black, etc.) This makes creating a conda development environment ridiculously easy.
Still needs clarification on the handling of some optional dependencies (maybe even only check if they are used in the tests). I'm happy to get feedback if the yml works.
Activity
tacaswell commentedon May 13, 2016
Can you put that text into a PR into the documentation?
egpbos commentedon May 15, 2016
Actually, two more steps are necessary:
Edit
$CONDA_ENV_PATH/bin/activate; at the bottom of the file add:Edit
$CONDA_ENV_PATH/bin/deactivate; at the top of the file add:I'll write it in the docs some time soon.
jenshnielsen commentedon May 15, 2016
Conda supports putting activation scrips in a activate.d and deactivate.d directory http://conda.pydata.org/docs/using/envs.html#saved-environment-variables I suggest doing that instead of modifying the activate and deactivate directly
egpbos commentedon May 15, 2016
Sounds good, will do.
efiring commentedon May 15, 2016
You should not be setting PYTHONPATH that way; there is no need to put site-packages on it because that location is compiled in. If you need to disable your PYTHONPATH that is your own special case, not a general condition for using conda. The same applies to DYLD_FALLBACK_LIBRARY_PATH. I'm sure it doesn't need to be set as you have it for the conda environment, and normally it would not even exist. If it is in your environment then at most you need to unset it when entering the conda environment.
egpbos commentedon May 15, 2016
It's not in my regular enviroment. I didn't come up with this myself, this solution is advertized in
README.osx:When I first tried your suggestion (steps 1-4 above), I had these variables set and it worked. I then thought that perhaps I could now turn them off again, but when I did, first the freetype lib could no longer be found (which was fixed by setting local_freetype to True in setup.cfg) and when that was fixed libpng started complaining:
efiring commentedon May 16, 2016
I hope we can get this straight and understand what is going on here. I am still pretty sure that having a PYTHONPATH set should not be needed, and I doubt that the DYLD variable is really needed in general either. It would be good to get this sorted out in README.osx as well.
Have you tried my original instructions (that is, with a fresh conda environment) with neither PYTHONPATH nor DYLD_FALLBACK_LIBRARY_PATH set? My guess is that the problem you encountered was a result of having started with those variables set. Otherwise I don't understand why you ran into the ImportError, and I don't. I do have local_freetype set to True in setup.cfg; this is necessary to make the image comparisons with text pass.
egpbos commentedon May 16, 2016
Ok, I did the following (in a terminal without DYLD vars, but with a PYTHONPATH with only paths to some custom modules, no critical stuff):
Then in
python:In
pythonw:egpbos commentedon May 16, 2016
Second try, in the same env (in the matplotlib_2 dir):
Then in
python:And in
pythonwthe same.egpbos commentedon May 16, 2016
Third try: without my custom PYTHONPATH, new conda env, inside the matplotlib_2 dir
Then
python(w)says, again:egpbos commentedon May 16, 2016
Finally, inside mpl_dev3:
export DYLD_FALLBACK_LIBRARY_PATH=/Users/patrick/anaconda/envs/mpl_dev3/lib pythonwSo, indeed, PYTHONPATH does not seem necessary, but DYLD_FALLBACK_LIBRARY_PATH, I can't seem to go without...
egpbos commentedon May 16, 2016
@efiring Is it possible that you have some custom built libs that your install finds, e.g. from Macports / Homebrew? I have Macports installed and I see now that I also have libpng there. I tried upgrading libpng, but to no avail.
egpbos commentedon May 16, 2016
Related: #3416.
$ otool -L /Users/patrick/anaconda/envs/mpl_dev3/lib/python2.7/site-packages/matplotlib/_png.so /Users/patrick/anaconda/envs/mpl_dev3/lib/python2.7/site-packages/matplotlib/_png.so: libpng16.16.dylib (compatibility version 34.0.0, current version 34.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 60.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 2577.0.0) $ pkg-config libpng --libs -L/opt/local/lib -lpng16Seems like it is indeed building against the Macports install, i.e. if it uses pkg-config to find libpng...
7 remaining items
egpbos commentedon Apr 9, 2018
As mentioned in #11006 (comment), things seem to have gotten a bit simpler on my most recent try (other machine by now, so clean environment compared to the one used for the above discussion of this issue).
For reference, here's what I need now to get it correctly installed from scratch (inside a clean matplotlib clone):
And then run with
pythonwto use the macosx backend (or switch to Agg or TkAgg in matplotlibrc).rcomer commentedon Jan 1, 2021
Having this week made my first
matplotlibbranch, I must admit I found the developers' installation instructions slightly terrifying! I would have been a lot more comfortable with somethingcondabased, as that's what I'm used to.I've no idea if this would be realistic for
matplotlib, but iniriswe have a yml file that defines its dependencies and everything you could possibly need during testing (sample data, sphinx, flake8, black, etc.) This makes creating acondadevelopment environment ridiculously easy.timhoffm commentedon Jan 1, 2021
There's a draft for a conda yml at #17096.
Still needs clarification on the handling of some optional dependencies (maybe even only check if they are used in the tests). I'm happy to get feedback if the yml works.
rcomer commentedon Oct 22, 2022
The Conda yml file is now on
mainand is nicely documented here:https://matplotlib.org/stable/devel/development_setup.html#create-a-dedicated-environment
So I wonder if this issue could be closed.
timhoffm commentedon Oct 22, 2022
Yes, I think this can be closed. Thanks for the notification!