Hello,
you know this question might seems strange, but I'd like to avoid some
examples to be built when creating documentation.
Those examples are the one using mpl.cbook.get_sample_data() to
retrieve data files from the remote svn. In Debian we are not allowed
to prepare a package that downloads "stuff" from the web, so I have to
avoid this.
The fastest solution I see is to actually exclude them from the list
of the examples to build (but still install them, for users to use),
but I didn't understand how 
Another solution would be for you to ship those datafile into the
released tarball, so that it's all consistent and then point the
example to those files, but how? if you find this in some way
unacceptable, I can also download those files separately and add them
when preparing the Debian package, but I have to find a way to tell
get_sample_data() to point to that location...
...and so I'm asking you: what would you feel to be the best solution?
Thanks in advance for your help and suggestions,
···
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Hello,
you know this question might seems strange, but I'd like to avoid some
examples to be built when creating documentation.
Those examples are the one using mpl.cbook.get_sample_data() to
retrieve data files from the remote svn. In Debian we are not allowed
to prepare a package that downloads "stuff" from the web, so I have to
avoid this.
Good policy!
The fastest solution I see is to actually exclude them from the list
of the examples to build (but still install them, for users to use),
but I didn't understand how 
Another solution would be for you to ship those datafile into the
released tarball, so that it's all consistent and then point the
example to those files, but how? if you find this in some way
unacceptable, I can also download those files separately and add them
when preparing the Debian package, but I have to find a way to tell
get_sample_data() to point to that location...
...and so I'm asking you: what would you feel to be the best solution?
I think we should include any necessary data, and also eliminate the downloading from the examples run by the standard backend_driver. The caching doesn't seem to work right, and there are long timeouts. This was a problem for me recently when I was out on a ship, working on mpl on a computer without a live internet connection.
It would be OK to retain some examples with live downloading, but they should not be required for doc generation or for basic testing of mpl.
They don't contribute anything essential to either.
Eric
···
On 07/19/2010 11:10 AM, Sandro Tosi wrote:
Thanks in advance for your help and suggestions,
The primary motivation for the get_sample_data code arose from my
observation that the gallery had become extremely popular, and
appeared to be the way most people learned/experimented with mpl. I
wanted some way to make it easy for a user to download and run any
example from the gallery. One could say, "grab this tarball or
zipfile and unpack it before running this example", but getting the
relative paths right, especially on windows, is difficult for new
users.
I completely agree that we can and should support a mechanism for
users / distributors who want to circumvent the download phase. One
could have an rc param "sampledata.localonly" that would check the mpl
config dir for a sample_data dir (which is where it looks already) and
forgo all the revision control stuff: if the file is there load it,
else raise. Or we could support a special MPLSAMPLEDATA env var which
could point to a dir or even a tar/zip file. Then one could get a svn
co of sample_data, zip it up when going out to sea or packaging mpl,
and configure mpl, presumably via the rc mechanism or env vars to use
the hardcopy.
JDH
···
On Mon, Jul 19, 2010 at 5:22 PM, Eric Firing <efiring@...229...> wrote:
It would be OK to retain some examples with live downloading, but they
should not be required for doc generation or for basic testing of mpl.
They don't contribute anything essential to either.
Bump from this side... Dav Clark just pointed this out to me:
and lo and behold, unfortunately for the upcoming maverick, Ubuntu
didn't update to mpl 1.0:
http://packages.ubuntu.com/hu/maverick/python-matplotlib
If an enterprising user who is knowledgeable in the ways of Debian
could contribute a patch for these data downloading calls to be
modified/disabled, it would be a great help.
It would be a shame to see mpl stuck at 0.99 for a long time just due to this...
Here's to hoping
Cheers,
f
···
On Wed, Jul 28, 2010 at 3:27 PM, Sandro Tosi <morph@...12...> wrote:
I don't want to put pressure on this but... was there any progress?
It would be nice to have this somehow fixed or worked-around, so that
I can upload to debian (experimental branch) and get some testing
there. The fact doc generation requires downloading datafiles from web
it's the only thing left that holds upload of mpl.