On Thu, Jan 6, 2011 at 11:50 AM, John Hunter <jdh2...@gmail.com> wrote:
> On Thu, Jan 6, 2011 at 11:36 AM, Benjamin Root <ben.r...@ou.edu> wrote:
> > On Thu, Jan 6, 2011 at 11:15 AM, John Hunter <jdh2...@gmail.com> wrote:
> >>
> >> On Thu, Jan 6, 2011 at 10:58 AM, Benjamin Root <ben.r...@ou.edu> wrote:
> >>
> >> > I thought that problem was already addressed in a previous patch?
> John,
> >> > could this be another "gremlin"? Or did I mis-understand the whole
> >> > issue
> >> > absolute path problem?
> >>
> >> My understanding is that because sphinx switches the current working
> >> directory during execution, this path must be absolute. We could get
> >> around this by processing a relative path internally in mpl at rc load
> >> time, and converting it into an absolute path assuming the path is
> >> relative to the directory containing the rc file.
> >>
> >> JDH
> >
> >
> > I actually think that would be a better solution. Python's os.path
> module
> > is very powerful with functions like isabs(), abspath(), expanduser(),
> > expandvars() and realpath(). Of course, one could easily go overboard
> with
> > this, but I am sure we could probably allow for something real simple
> like
> > expandvars() so that packagers could utilize environment variables for
> the
> > build process?
>
> Here is a candidate patch...this will be processed once on module load
> time. I considered doing it in the validate method of the rc params
> in rcsetup, but I am not sure this is better because if users are
> overriding the variable at runtime, we should probably just let them
> do what they want.
>
> I am not sure if this qualifies as a "one time hack" that makes mpl so
> difficult to maintain -- Sandro and Ben can weigh in -- but at least
> we are doing it to make their lives easier :-)
>
> Index: lib/matplotlib/__init__.py
> ===================================================================
> --- lib/matplotlib/__init__.py (revision 8898)
> +++ lib/matplotlib/__init__.py (working copy)
> @@ -762,6 +762,13 @@
>
> # this is the instance used by the matplotlib classes
> rcParams = rc_params()
> +
> +if rcParams['examples.directory']:
> + if not os.path.isabs(rcParams['examples.directory']):
> + _basedir, _fname = os.path.split(matplotlib_fname())
> + _fullpath = os.path.join(_basedir, rcParams['examples.directory'])
> + rcParams['examples.directory'] = _fullpath
> +
> rcParamsOrig = rcParams.copy()
>
> rcParamsDefault = RcParams([ (key, default) for key, (default, converter)
> in \
> @@ -770,6 +777,8 @@
> rcParams['ps.usedistiller'] =
> checkdep_ps_distiller(rcParams['ps.usedistiller'])
> rcParams['text.usetex'] = checkdep_usetex(rcParams['text.usetex'])
>
> +
> +
> def rc(group, **kwargs):
> """
> Set the current rc params. Group is the grouping for the rc, eg.
>
I like the idea. Obviously we would need to make it very clear exactly what
relative filepaths are going to be relative to.
A comment on the patch. Unless matplotlib_fname() is guaranteed to return
an absolute filename, then we need to use realpath() on _basedir so that the
final joined filename will also be absolute. The reason for using
realpath() instead of abspath() is that in case there are any symbolic links
in the name from matplotlib_fname(), these will be qualified so that the
filepath matplotlib sees is the same filepath that spinx sees.
Also, a little oddity that I discovered in reading the docs for
os.path.join(), turns out that if any element is already an absolute path,
then it ignores all elements prior to that. In this patch, everything is ok
because we already check for isabs(). Just thought I ought to point that
out because I never knew that and that would certainly be a nasty bug to try
and track down...
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
