Building documentation and matplotlibrc

Development matplotlib-devel
1

Ben Gamari <bgamari@...149...> 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

2

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

···

On Thu, 09 Dec 2010 20:00:39 +0200, Jouni K. Seppänen <jks@...278...> wrote:

Ben Gamari <bgamari@...149...> 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.

3

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.

···

On Thu, Dec 9, 2010 at 12:34 PM, Ben Gamari <bgamari@...149...> 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.

4

> 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

···

On Thu, 9 Dec 2010 12:57:49 -0600, John Hunter <jdh2358@...149...> wrote:

On Thu, Dec 9, 2010 at 12:34 PM, Ben Gamari <bgamari@...149...> wrote:

5

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

···

On Thu, Dec 9, 2010 at 1:12 PM, Ben Gamari <bgamari@...149...> 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/.

6

> 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

···

On Thu, 9 Dec 2010 13:39:41 -0600, John Hunter <jdh2358@...149...> wrote:

On Thu, Dec 9, 2010 at 1:12 PM, Ben Gamari <bgamari@...149...> wrote:

7

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

···

On Thu, Dec 9, 2010 at 1:52 PM, Ben Gamari <bgamari@...149...> 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.

8

> 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

···

On Thu, 9 Dec 2010 14:09:41 -0600, John Hunter <jdh2358@...149...> wrote:

On Thu, Dec 9, 2010 at 1:52 PM, Ben Gamari <bgamari@...149...> wrote:

9

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

···

On Thu, 09 Dec 2010 15:42:18 -0500, Ben Gamari <bgamari@...149...> 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?

10

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

···

On Thu, 09 Dec 2010 16:44:37 -0500, Ben Gamari <bgamari@...149...> 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?

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

11

Hi all,

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.

With this patch we can indeed finally use the sampledata local dir -
thanks Ben for that!! anyhow, it seems to be quite a radical change,
that might have a bit of impact on what the users can experience, so
I'd like to hear from mpl devels what's the feelings about that.

Anyhow, please note that examples.directory RC param, must not
contains apex (') at the beginning/end of the value, else it would
fail; the example in matplotlibrc.template seems to suggests it's
apex-enclosed:

  #examples.directory : '' # directory to look in if download is false

else you would get:

  IOError: [Errno 2] No such file or directory:
"'/home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/'/axes_grid/bivariate_normal.npy"

it should be made it clearer (or make the get_sample_data() smarter) about that.

Cheers,

···

On Thu, Dec 9, 2010 at 23:04, Ben Gamari <bgamari@...149...> wrote:

On Thu, 09 Dec 2010 16:44:37 -0500, Ben Gamari <bgamari@...149...> wrote:

--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

12

I agree the current behavior needs to be improved. I’m testing a change now which utilizes two functions, now properly documented, and removing the hack in the plot_directive since the file defaults will be preserved. This keeps the current behavior, since rcdefaults is unchanged, but fixes the doc string, and introduces a new function with the desired behavior.

Index: doc/matplotlibrc

···

On Tue, Jan 4, 2011 at 4:40 PM, Sandro Tosi <morph@…12…> wrote:

Hi all,

On Thu, Dec 9, 2010 at 23:04, Ben Gamari <bgamari@…149…> wrote:

On Thu, 09 Dec 2010 16:44:37 -0500, Ben Gamari <bgamari@…149…> 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.

===================================================================
— doc/matplotlibrc (revision 8886)
+++ doc/matplotlibrc (working copy)
@@ -232,7 +232,7 @@

FIGURE

See http://matplotlib.sourceforge.net/matplotlib.figure.html#Figure

-figure.figsize : 6, 4 # figure size in inches
+figure.figsize : 5.5, 4.5 # figure size in inches

#figure.dpi : 80 # figure dots per inch
#figure.facecolor : 0.75 # figure facecolor; 0.75 is scalar gray
#figure.edgecolor : white # figure edgecolor
Index: lib/matplotlib/init.py

— lib/matplotlib/init.py (revision 8886)
+++ lib/matplotlib/init.py (working copy)
@@ -762,6 +762,7 @@

this is the instance used by the matplotlib classes

rcParams = rc_params()
+rcParamsOrig = rcParams.copy()

rcParamsDefault = RcParams([ (key, default) for key, (default, converter) in
defaultParams.iteritems() ])
@@ -843,11 +844,19 @@

def rcdefaults():
“”"

  • Restore the default rc params - the ones that were created at

  • matplotlib load time.

  • Restore the default rc params - these are not the params loaded by

  • the rc file, but mpl’s internal params. See rc_file_defaults for

  • reloading the default params from the rc file

    “”"
    rcParams.update(rcParamsDefault)

+def rc_file_defaults():

  • “”"

  • Restore the default rc params from the original matplotlib rc that

  • was loaded

  • “”"

  • rcParams.update(rcParamsOrig)

_use_error_msg = “”" This call to matplotlib.use() has no effect
because the the backend has already been chosen;
matplotlib.use() must be called before pylab, matplotlib.pyplot,

13

Hi John,

I agree the current behavior needs to be improved. I'm testing a change now
which utilizes two functions, now properly documented, and removing the hack
in the plot_directive since the file defaults will be preserved. This keeps
the current behavior, since rcdefaults is unchanged, but fixes the doc
string, and introduces a new function with the desired behavior.

thanks for working on it!

Index: doc/matplotlibrc

--- doc/matplotlibrc (revision 8886)
+++ doc/matplotlibrc (working copy)
@@ -232,7 +232,7 @@

### FIGURE
# See http://matplotlib.sourceforge.net/matplotlib.figure.html#Figure
-figure.figsize : 6, 4 # figure size in inches
+figure.figsize : 5.5, 4.5 # figure size in inches
#figure.dpi : 80 # figure dots per inch
#figure.facecolor : 0.75 # figure facecolor; 0.75 is scalar gray
#figure.edgecolor : white # figure edgecolor
Index: lib/matplotlib/__init__.py

--- lib/matplotlib/__init__.py (revision 8886)
+++ lib/matplotlib/__init__.py (working copy)
@@ -762,6 +762,7 @@

# this is the instance used by the matplotlib classes
rcParams = rc_params()
+rcParamsOrig = rcParams.copy()

rcParamsDefault = RcParams([ (key, default) for key, (default, converter)
in \
defaultParams.iteritems() ])
@@ -843,11 +844,19 @@

def rcdefaults():
"""
- Restore the default rc params - the ones that were created at
- matplotlib load time.
+ Restore the default rc params - these are not the params loaded by
+ the rc file, but mpl's internal params. See rc_file_defaults for
+ reloading the default params from the rc file
"""
rcParams.update(rcParamsDefault)

+def rc_file_defaults():
+ """
+ Restore the default rc params from the original matplotlib rc that
+ was loaded
+ """
+ rcParams.update(rcParamsOrig)
+
_use_error_msg = """ This call to matplotlib.use() has no effect
because the the backend has already been chosen;
matplotlib.use() must be called *before* pylab, matplotlib.pyplot,

I take the patch is not complete, right? because naively applying it
in a just-untarred source code + configuring doc/matplotlibrc don't
work (ie keeps trying accessing the net)

Cheers,

···

On Wed, Jan 5, 2011 at 15:04, John Hunter <jdh2358@...149...> wrote:
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

14

Well, that is the default behavior. You still have to untar, and set the examples.directory rc parameter as Ben discussed to do a no download doc build. So you’ll want to patch doc/matplotlibrc to set this param.

JDH

···

On Wed, Jan 5, 2011 at 11:41 AM, Sandro Tosi <morph@…12…> wrote:

+def rc_file_defaults():

  • “”"
  • Restore the default rc params from the original matplotlib rc that
  • was loaded
  • “”"
  • rcParams.update(rcParamsOrig)

_use_error_msg = “”" This call to matplotlib.use() has no effect

because the the backend has already been chosen;

matplotlib.use() must be called before pylab, matplotlib.pyplot,

I take the patch is not complete, right? because naively applying it

in a just-untarred source code + configuring doc/matplotlibrc don’t

work (ie keeps trying accessing the net)

15

ehm that's what I meant with "configuring doc/matplotlibrc" - I did that :slight_smile:

$ tail -n2 doc/matplotlibrc
examples.download : False # False to bypass downloading mechanism
examples.directory : /home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/

and sampledata is .. from doc

···

On Wed, Jan 5, 2011 at 18:45, John Hunter <jdh2358@...149...> wrote:

On Wed, Jan 5, 2011 at 11:41 AM, Sandro Tosi <morph@...12...> wrote:

> +def rc_file_defaults():
> + """
> + Restore the default rc params from the original matplotlib rc that
> + was loaded
> + """
> + rcParams.update(rcParamsOrig)
> +
> _use_error_msg = """ This call to matplotlib.use() has no effect
> because the the backend has already been chosen;
> matplotlib.use() must be called *before* pylab, matplotlib.pyplot,

I take the patch is not complete, right? because naively applying it
in a just-untarred source code + configuring doc/matplotlibrc don't
work (ie keeps trying accessing the net)

Well, that is the default behavior. You still have to untar, and set the
examples.directory rc parameter as Ben discussed to do a no download doc
build. So you'll want to patch doc/matplotlibrc to set this param.

--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

16

Is that tilde in you path matplotlib-1.0.1~rc1 correct?

···

On Wed, Jan 5, 2011 at 11:48 AM, Sandro Tosi <morph@…12…> wrote:

So you’ll want to patch doc/matplotlibrc to set this param.

ehm that’s what I meant with “configuring doc/matplotlibrc” - I did that :slight_smile:

$ tail -n2 doc/matplotlibrc

examples.download : False # False to bypass downloading mechanism

examples.directory : /home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/

and sampledata is … from doc /home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/

17

yes, it's the version I'm going to use for the RC, that's because
version 1.0.1~rc1-1 is lower than 1.0.1-1 (debian versions) and so
uploading an RC package will not prevent for the final release to be
uploaded (1.0.1rc1-1 is bigger than 1.0.1-1). Do you think that might
be the problem?

···

On Wed, Jan 5, 2011 at 18:57, John Hunter <jdh2358@...149...> wrote:

On Wed, Jan 5, 2011 at 11:48 AM, Sandro Tosi <morph@...12...> wrote:

So you'll want to patch doc/matplotlibrc to set this param.

ehm that's what I meant with "configuring doc/matplotlibrc" - I did that
:slight_smile:

$ tail -n2 doc/matplotlibrc
examples.download : False # False to bypass downloading mechanism
examples.directory :
/home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/

and sampledata is .. from doc
/home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/

Is that tilde in you path matplotlib-1.0.1~rc1 correct?

--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

18

I’m not sure – tilde has special meanings in paths, eg ~jdhunter is my home directory. But even if you had the wrong path, it should cause an error, not an internet download. Are you running the doc build from the doc directory. It is important that the cwd is doc when you start the doc build.

The code in matplotlib.cbook.get_sample_data reads:

if not matplotlib.rcParams['examples.download']:

    directory = matplotlib.rcParams['examples.directory']

    f = os.path.join(directory, fname)

    if asfileobj:

        return open(f, 'rb')

    else:

        return f

So if the rc file is getting picked up and examples.download is set to False, the code cannot reach the network as far as I can see.

···

On Wed, Jan 5, 2011 at 12:05 PM, Sandro Tosi <morph@…12…> wrote:

yes, it’s the version I’m going to use for the RC, that’s because

version 1.0.1~rc1-1 is lower than 1.0.1-1 (debian versions) and so

uploading an RC package will not prevent for the final release to be

uploaded (1.0.1rc1-1 is bigger than 1.0.1-1). Do you think that might

be the problem?

19

Just to ask an obvious question – are you testing from svn branch. Because the bug is fixed there, not in the rc… I could cut an rc2, just want to make sure we are looking at the same code.

JDH

···

On Wed, Jan 5, 2011 at 12:10 PM, John Hunter <jdh2358@…552…149…> wrote:

The code in matplotlib.cbook.get_sample_data reads:

if not matplotlib.rcParams['examples.download']:

    directory = matplotlib.rcParams['examples.directory']

    f = os.path.join(directory, fname)

    if asfileobj:

        return open(f, 'rb')

    else:

        return f

So if the rc file is getting picked up and examples.download is set to False, the code cannot reach the network as far as I can see.

20

ehm... no, I'm testing it the rc + your patch, sorry :slight_smile: I'm updating
my local svn copy and try again

···

On Wed, Jan 5, 2011 at 19:45, John Hunter <jdh2358@...149...> wrote:

On Wed, Jan 5, 2011 at 12:10 PM, John Hunter <jdh2358@...149...> wrote:

The code in matplotlib.cbook.get_sample_data reads:

if not matplotlib\.rcParams\[&#39;examples\.download&#39;\]:
    directory = matplotlib\.rcParams\[&#39;examples\.directory&#39;\]
    f = os\.path\.join\(directory, fname\)
    if asfileobj:
        return open\(f, &#39;rb&#39;\)
    else:
        return f

So if the rc file is getting picked up and examples.download is set to
False, the code cannot reach the network as far as I can see.

Just to ask an obvious question -- are you testing from svn branch. Because
the bug is fixed there, not in the rc... I could cut an rc2, just want to
make sure we are looking at the same code.

--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi