Re: [matplotlib-devel] Building documentation and matplotlibrc
Ben Gamari writes: > That being said, I've tracked down the reason for the configuration in > doc/matplotlibrc not being used. It seems that sphinx runs the examples > in their current directory (I suppose this is to be expected). > > It seems that there is a (as far as I can tell undocumented, please fix > this) MATPLOTLIBRC environment variable which can be used to override > the location of the matplotlibrc used. This could be useful in > specifying the matplotlibrc used during the documentation build process > but unfortunately this would require an absolute path which, again, > complicates the packaging (i.e. I don't know the best way to accomplish > this). Suggestions? I don't see why the path must be absolute, though I haven't tried. Is there some problem having a different global matplotlibrc $HOME/.matplotlib/matplotlibrc or $MATPLOTLIBDATA/matplotlibrc, possibly setting $HOME or $MATPLOTLIBDATA from your build script? -- Jouni K. Seppänen http://www.iki.fi/jks -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, 09 Dec 2010 18:37:34 +0200, Jouni K. Seppänen wrote:
> Ben Gamari writes:
>
> > That being said, I've tracked down the reason for the configuration in
> > doc/matplotlibrc not being used. It seems that sphinx runs the examples
> > in their current directory (I suppose this is to be expected).
> >
> > It seems that there is a (as far as I can tell undocumented, please fix
> > this) MATPLOTLIBRC environment variable which can be used to override
> > the location of the matplotlibrc used. This could be useful in
> > specifying the matplotlibrc used during the documentation build process
> > but unfortunately this would require an absolute path which, again,
> > complicates the packaging (i.e. I don't know the best way to accomplish
> > this). Suggestions?
>
> I don't see why the path must be absolute, though I haven't tried. Is
> there some problem having a different global matplotlibrc
> $HOME/.matplotlib/matplotlibrc or $MATPLOTLIBDATA/matplotlibrc,
> possibly setting $HOME or $MATPLOTLIBDATA from your build script?
An absolute path is necesary because the current working directory
changes for each example. To check this I added,
import sys
sys.stderr.write('SAMPLE cwd=%s\n'%os.getcwd())
sys.stderr.write('SAMPLE matplotlibrc=%s\n'%matplotlib.matplotlib_fname())
to the beginning of cbook.get_sample_data(). During the documentation
build I then saw output like,
reading sources... [ 12%] examples/api/date_demo
SAMPLE cwd=/home/bgamari/trees/matplotlib/matplotlib-1.0.1/examples/api
SAMPLE matplotlibrc=/home/bgamari/.matplotlib/matplotlibrc
reading sources... [ 12%] examples/api/date_index_formatter
SAMPLE cwd=/home/bgamari/trees/matplotlib/matplotlib-1.0.1/examples/api
SAMPLE matplotlibrc=/home/bgamari/.matplotlib/matplotlibrc
I suppose the only way around this is to patch the absolute path into
doc/matplotlibrc with sed, and then invoke doc/make.py with
MATPLOTLIBRC="$(CURDIR)/doc/matplotlibrc". I'm very confused how you
found that specifying a relative path in download.path worked. If the
cwd changes as seen above then the documentation was entirely correct in
claiming an absolute path is necessary. I really do wish there as a way
to prevent spinx from changing the cwd.
- Ben
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
Ben Gamari writes: > An absolute path is necesary because the current working directory > changes for each example. Oh, right, the examples are in a lot of different subdirectories. > I'm very confused how you found that specifying a relative path in > download.path worked. If the cwd changes as seen above then the > documentation was entirely correct in claiming an absolute path is > necessary. I just tested that the relative path works fine by making the path relative and trying cbook.get_sample_data; it's just not much use if your current working directory keeps changing. -- Jouni K. Seppänen http://www.iki.fi/jks -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, 09 Dec 2010 20:00:39 +0200, Jouni K. Seppänen wrote: > Ben Gamari writes: > > > An absolute path is necesary because the current working directory > > changes for each example. > > Oh, right, the examples are in a lot of different subdirectories. > Precisely, this is the problem. Regardless, after making the necessary changes to use absolute paths (after painfully realizing that the MATPLOTLIB environment variable expects the directory of the desired matplotlibrc, not the file path; documentation would have been nice here) the configuration is _still_ having no effect. While matplotlib.matplotlib_fname() seems to be reporting the correct matplotlibrc path, examples.download is still True despite setting this to False in the file. I've placed a debug message writing to sys.stderr at the beginning of matplotlib.rc_params(), but unfortunately I have seen no output from it. Considering the rest of my debugging output works just fine, I'm quite confused. Is this function not invoked? Cheers, - Ben -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, Dec 9, 2010 at 12:34 PM, Ben Gamari wrote: > Regardless, after making the necessary changes to use absolute paths > (after painfully realizing that the MATPLOTLIB environment variable > expects the directory of the desired matplotlibrc, not the file path; > documentation would have been nice here) the configuration is _still_ > having no effect. While matplotlib.matplotlib_fname() seems to be > reporting the correct matplotlibrc path, examples.download is still True > despite setting this to False in the file. Sorry to be joining this a bit late. Why do you need to set the MATPLOTLIBRC variable. The file doc/matplotlibrc is used by the doc build process, so if you patch in your changes there, you should be good. Specifically, we set the parameters backend : Agg docstring.hardcopy : True and these are picked up at build time since the rest table formatting of the API docs depends on the latter setting. And yes, the relative paths in sphinx doc builds are a major headache. Sorry you are having so much trouble. We struggled mightily against them in trying to get the plot directive working. In my experience, setting relative paths with respect to the doc root (where conf.py lives) works in most cases. -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, 9 Dec 2010 12:57:49 -0600, John Hunter wrote: > On Thu, Dec 9, 2010 at 12:34 PM, Ben Gamari wrote: > > > Regardless, after making the necessary changes to use absolute paths > > (after painfully realizing that the MATPLOTLIB environment variable > > expects the directory of the desired matplotlibrc, not the file path; > > documentation would have been nice here) the configuration is _still_ > > having no effect. While matplotlib.matplotlib_fname() seems to be > > reporting the correct matplotlibrc path, examples.download is still True > > despite setting this to False in the file. > > Sorry to be joining this a bit late. Why do you need to set the > MATPLOTLIBRC variable. The file doc/matplotlibrc is used by the doc > build process, so if you patch in your changes there, you should be > good. It seems that this may have been broken from the beginning. After noticing that my changes were not taking effect, I added some debug output and found that sphinx was changing the current working directory (every example gets built with its own directory being the working directory). I fail to see how doc/matplotlibrc could be currently used given most examples are not built from doc/. > and these are picked up at build time since the rest table formatting > of the API docs depends on the latter setting. > Are you certain this configuration isn't leaking in from some other source? > And yes, the relative paths in sphinx doc builds are a major headache. Are you referring to the fact that sphinx's above-mentioned chdir behavior? Cheers, - Ben -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, Dec 9, 2010 at 1:12 PM, Ben Gamari wrote: > It seems that this may have been broken from the beginning. After > noticing that my changes were not taking effect, I added some debug > output and found that sphinx was changing the current working directory > (every example gets built with its own directory being the working > directory). I fail to see how doc/matplotlibrc could be currently used > given most examples are not built from doc/. Well, the matplotlibrc file is checked for when the python process is started, and the current directory when matplotlib is imported is used. Since we launch the build process in the doc directory next to make.py, doc is the current working directory when the plot directive extension is imported and this is used to build the examples. So it is not the directory that the example is in that is important, but the current directory when matplotlib is imported. On import the matplotlib.rc_params function is called to set matplotlib.rcParams. The rc_params function in turn calls matplotlib_fname, which does the following search * current working dir * environ var MATPLOTLIBRC * HOME/.matplotlib/matplotlibrc * MATPLOTLIBDATA/matplotlibrc Hope this helps! JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, 9 Dec 2010 13:39:41 -0600, John Hunter wrote: > On Thu, Dec 9, 2010 at 1:12 PM, Ben Gamari wrote: > > > It seems that this may have been broken from the beginning. After > > noticing that my changes were not taking effect, I added some debug > > output and found that sphinx was changing the current working directory > > (every example gets built with its own directory being the working > > directory). I fail to see how doc/matplotlibrc could be currently used > > given most examples are not built from doc/. > > Well, the matplotlibrc file is checked for when the python process is > started, and the current directory when matplotlib is imported is > used. Since we launch the build process in the doc directory next to > make.py, doc is the current working directory when the plot directive > extension is imported and this is used to build the examples. So it > is not the directory that the example is in that is important, but the > current directory when matplotlib is imported. > Ahh, so matplotlib is not reimported with every example? I was under the impression sphinx operated more like make (1 process per target). I suppose that explains it then. > On import the matplotlib.rc_params function is called to set > matplotlib.rcParams. The rc_params function in turn calls > matplotlib_fname, which does the following search > Any idea why my debugging messages are ineffective? Or, even better, any idea why setting the examples.download in doc/matplotlibrc isn't being reflected in rc_params? I'll examine this more closely in about 30 minutes once I make it to the office. Cheers, - Ben -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, Dec 9, 2010 at 1:52 PM, Ben Gamari wrote: > Any idea why my debugging messages are ineffective? Or, even better, any > idea why setting the examples.download in doc/matplotlibrc isn't being > reflected in rc_params? I'll examine this more closely in about 30 > minutes once I make it to the office. I am not sure. Perhaps it is working but in the confusion you never had everything set right at the same time. Try setting in doc/matplotlibrc examples.download : False examples.directory : somedir/relative/to/doc Then flush the sphinx build directory and try again. Perhaps stick some debug print in matplotlib.matplotlib_fname and cbook.get_sample_data and let us know. Good luck! JDH -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, 9 Dec 2010 14:09:41 -0600, John Hunter wrote: > On Thu, Dec 9, 2010 at 1:52 PM, Ben Gamari wrote: > > > Any idea why my debugging messages are ineffective? Or, even better, any > > idea why setting the examples.download in doc/matplotlibrc isn't being > > reflected in rc_params? I'll examine this more closely in about 30 > > minutes once I make it to the office. > > I am not sure. Perhaps it is working but in the confusion you never > had everything set right at the same time. Try setting in > doc/matplotlibrc > > examples.download : False > examples.directory : somedir/relative/to/doc > Already done. > Then flush the sphinx build directory and try again. Perhaps stick > some debug print in matplotlib.matplotlib_fname and > cbook.get_sample_data and let us know. I have already done this. This is how I know that rc_examples.download is set to True in get_sample_data(). It turns out the debugging messages I made reference to in my last message were being output and I just missed them in the noise. Right after matplotlib is initialized with matplotlib.rc_params() it seems that rcParams['examples.download'] is set to False as expected. By the time execution makes it to get_sample_data(), however, this value has somehow been set to True. To try identifying where this happens I have tried putting some debug output in RcParams.__setitem__(). Unfortunately this doesn't show anyone setting examples.download after the initial loading of matplotlibrc. Any ideas how/where this might get overridden? - Ben -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] PATCH: fix libpng URLs for OS X makefile
This patch is for make.osx. Note it also changes the python version to 2.7. https://gist.github.com/735337 Uri ... Uri Laserson Graduate Student, Biomedical Engineering Harvard-MIT Division of Health Sciences and Technology M +1 917 742 8019 laser...@mit.edu -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, 09 Dec 2010 15:42:18 -0500, Ben Gamari wrote: > To try identifying where this happens I have tried putting some debug > output in RcParams.__setitem__(). Unfortunately this doesn't show anyone > setting examples.download after the initial loading of matplotlibrc. Any > ideas how/where this might get overridden? > Found it! It seems that matplotlib's sphinx extension calls matplotlib.rcdefaults() after rendering each figure, thus resetting examples.download to True (as set in rcsetup.py). The documentation claims that this function will "Restore the default rc params - the ones that were created at matplotlib load time." Despite the apparent attempt at clarification in this docstring, it's still not clear what the "default rc params" actually are. Is this supposed to be the parameters loaded from matplotlibrc (which seems to be what the sphinx extension expects) or the factory default values? rcdefaults()'s implementation appears to implement the latter, updating rcParams from rcParamsDefault in rcsetup.py, which appears to describe the factory default values. Perhaps we should rcParamsDefault.update(rcParams) after loading matplotlibrc? - Ben -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
Ben Gamari writes: > It seems that matplotlib's sphinx extension calls > matplotlib.rcdefaults() after rendering each figure, thus resetting > examples.download to True (as set in rcsetup.py). Right, and it sets figure.figsize after it. I guess you will want to set examples.download in the same function. > The documentation claims that this function will "Restore the default rc > params - the ones that were created at matplotlib load time." > rcdefaults()'s implementation appears to implement the latter, updating > rcParams from rcParamsDefault in rcsetup.py, which appears to describe > the factory default values. Perhaps we should > rcParamsDefault.update(rcParams) after loading matplotlibrc? I think you're better off modifying the sphinx extension. rcdefaults has a useful purpose, and the extension is trying to use it for that purpose: to avoid having the user's configuration mess up the documentation. If you were to update rcParamsDefault with the matplotlibrc parameters, you might accidentally change the example output. -- Jouni K. Seppänen http://www.iki.fi/jks -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, 09 Dec 2010 16:44:37 -0500, Ben Gamari wrote: > rcdefaults()'s implementation appears to implement the latter, updating > rcParams from rcParamsDefault in rcsetup.py, which appears to describe > the factory default values. Perhaps we should > rcParamsDefault.update(rcParams) after loading matplotlibrc? > As expected, doing the update of rcParamsDefault proposed above (patch below) allows the examples.download setting to persist throughout the documentation build. It seems like either the documentation build process or rcParamsDefault has been badly broken for a very long time. Is rcParamsDefault really supposed to be the factory defaults or is this just a bug? If the former, we will need to introduce a variant of matplotlib.rcdefaults() to reset the configuration to that specified in matplotlibrc. - Ben diff --git a/lib/matplotlib/__init__.py b/lib/matplotlib/__init__.py --- a/lib/matplotlib/__init__.py +++ b/lib/matplotlib/__init__.py @@ -764,13 +772,13 @@ Please do not ask for support with these customizations active. # this is the instance used by the matplotlib classes rcParams = rc_params() - -rcParamsDefault = RcParams([ (key, default) for key, (default, converter) in \ -defaultParams.iteritems() ]) - rcParams['ps.usedistiller'] = checkdep_ps_distiller(rcParams['ps.usedistiller']) rcParams['text.usetex'] = checkdep_usetex(rcParams['text.usetex']) +rcParamsDefault = RcParams([ (key, default) for key, (default, converter) in \ + defaultParams.iteritems() ]) +rcParamsDefault.update(rcParams) + def rc(group, **kwargs): """ Set the current rc params. Group is the grouping for the rc, eg. -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, 09 Dec 2010 23:55:05 +0200, Jouni K. Seppänen wrote: > Ben Gamari writes: > > > It seems that matplotlib's sphinx extension calls > > matplotlib.rcdefaults() after rendering each figure, thus resetting > > examples.download to True (as set in rcsetup.py). > > Right, and it sets figure.figsize after it. I guess you will want to set > examples.download in the same function. > NAK. This seems like an _awful_ hack. If the user specifies in matplotlibrc that they don't want to download sample data (or any preference for that matter), then they _really_ don't want to download sample data and we should take their word for this. It's one-time hacks like this that make matplotlib the nightmare to package that it is. Wholesale overriding of the user's preferences seems like a big no-no, even when it comes to generating documentation. If a particular example _absolutely needs_ to override a specific rc option then it should modify that option and only that option. After this, the configuration should be returned to the user's default. > > The documentation claims that this function will "Restore the default rc > > params - the ones that were created at matplotlib load time." > > > rcdefaults()'s implementation appears to implement the latter, updating > > rcParams from rcParamsDefault in rcsetup.py, which appears to describe > > the factory default values. Perhaps we should > > rcParamsDefault.update(rcParams) after loading matplotlibrc? > > I think you're better off modifying the sphinx extension. rcdefaults has > a useful purpose, and the extension is trying to use it for that > purpose: to avoid having the user's configuration mess up the > documentation. If you were to update rcParamsDefault with the > matplotlibrc parameters, you might accidentally change the example > output. > I'm not sure I understand what this purpose might be. If the user sets a preference, then they want that preference to be reflected in _all_ matplotlib output, including the examples. By overriding matplotlibrc, we are doing nothing but setting ourselves up to thoroughly confuse the user (not to mention lowly packagers like me). If the user takes a block of code from an example then he expects that the output in ipython will be identical to that generated in the documentation. If it is not, he's forced to embark on a wild goose chase through the code looking for the line where some developer thought their example was too good for my carefully chosen preferences (or simply give up in frustration). - Ben -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] PATCH: fix libpng URLs for OS X makefile
Hi,
This patch reminded me to ask why the builtin libpng, zlib and
libfreetype on Mac OS 10.5 and later are not used to build Matplotlib,
removing the need to download these extra libraries. I was pleased to
discover that Snow Leopard shipped with libpng and libfreetype as part
of X11, only to find that even my old Leopard installation had them.
I've been successfully building Matplotlib against them on both
platforms. Besides skipping the download step, these libraries have
the advantage of being correct universal binaries, eliminating another
potential stumbling block. The only problem would be if these
libraries were outdated, but I haven't come across any problems yet.
For the record, I set the following environment variables in
~/.profile on Snow Leopard:
# These compiler flags ensure 32-bit + 64-bit code generation, as
Snow Leopard produces 64-bit code by default
export MACOSX_DEPLOYMENT_TARGET=10.6
export CFLAGS="-arch i386 -arch x86_64 -isysroot
/Developer/SDKs/MacOSX10.6.sdk"
export LDFLAGS="-arch i386 -arch x86_64
-syslibroot,/Developer/SDKs/MacOSX10.6.sdk"
export FFLAGS="-m32 -m64"
I then build a Matplotlib egg with:
CFLAGS=${CFLAGS}" -I/usr/X11/include -I/usr/X11/include/freetype2"
LDFLAGS=${LDFLAGS}" -L/usr/X11/lib" python setupegg.py bdist_egg
I've been meaning to publish my installation instructions for
numpy/scipy/matplotlib/ipython on Snow Leopard somewhere for quite a
while, but that will have to wait for another day... I've tried to
trim down my installation procedure to the minimum steps that will
guarantee a working system without introducing extra libraries /
Pythons / etc, so there might be some interest in it.
Ludwig
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
