Re: [matplotlib-devel] matplotlib 1.0.1rc available for testing, building
2011/1/4 Russell E. Owen : > I'm not sure what to do about 64-bit Python 2.7. It does not even > support Mac OS X 10.5 due to tcl/tk issues that I think were resolved > too late for python 2.7.1. In my opinion a matplotlib built against > ActiveState's Python 2.7 (which is 64-bit and supports 10.5 and 10.6) > might be of more use. Opinions? Here's the state of the art for numpy: http://article.gmane.org/gmane.comp.python.numeric.general/41799. So from my point of view mpl Mac OS X py2.7 32+64bit should be built on Mac OS X 10.6 and should not support < 10.6. Friedrich -- 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
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Wed, Jan 5, 2011 at 10:42 PM, Sandro Tosi wrote: > On Thu, Jan 6, 2011 at 02:31, John Hunter wrote: > > mpl1> grep rc_file lib/matplotlib/sphinxext/plot_directive.py > > > > Surely I have it right now! > > Indeed, and it works fine!!! the only thing to notice is that > examples.directory must be an absolute path, but that set, the doc > build process gets files from the location specified. > > 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? Ben Root -- 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
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, Jan 6, 2011 at 10:58 AM, Benjamin Root 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 -- 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
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, Jan 6, 2011 at 11:15 AM, John Hunter wrote: > On Thu, Jan 6, 2011 at 10:58 AM, Benjamin Root 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? Ben Root -- 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
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, Jan 6, 2011 at 11:36 AM, Benjamin Root wrote: > On Thu, Jan 6, 2011 at 11:15 AM, John Hunter wrote: >> >> On Thu, Jan 6, 2011 at 10:58 AM, Benjamin Root 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. -- 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
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, Jan 6, 2011 at 11:50 AM, John Hunter wrote: > On Thu, Jan 6, 2011 at 11:36 AM, Benjamin Root wrote: > > On Thu, Jan 6, 2011 at 11:15 AM, John Hunter wrote: > >> > >> On Thu, Jan 6, 2011 at 10:58 AM, Benjamin Root 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
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, Jan 6, 2011 at 12:15 PM, Benjamin Root wrote: > 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.. matplotlib_fname() always returns absolute path. I have not used realpath, but if you think there is a use for it here, feel free to post an amended patch. JDH -- 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
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, Jan 6, 2011 at 12:22 PM, John Hunter wrote: > matplotlib_fname() always returns absolute path. I have not used > realpath, but if you think there is a use for it here, feel free to > post an amended patch. There is an exception to this -- if MATPLOTLIBRC or MPLCONFIGDIR are relative paths, then matplotlib_fname will return a relative path too. -- 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
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, Jan 6, 2011 at 12:32 PM, John Hunter wrote: > On Thu, Jan 6, 2011 at 12:22 PM, John Hunter wrote: > > > matplotlib_fname() always returns absolute path. I have not used > > realpath, but if you think there is a use for it here, feel free to > > post an amended patch. > > There is an exception to this -- if MATPLOTLIBRC or MPLCONFIGDIR are > relative paths, then matplotlib_fname will return a relative path too. > Ah, all the more reason to apply abspath() or realpath(). To decide which to use, let's consider the case of someone (like a developer) having multiple builds of matplotlib in separate directories, and uses a symlink to point to whichever he wants to use at the moment. The question is, in this use-case, would we want the symbolic link pathname, or the absolute pathname? I don't mess around with docs enough to know which I would want. I have attached a modified patch (which uses realpath(), but could easily be changed to abspath()). I also included some comments to more fully document what is going on and the rational for the logic being taken. Ben Root P.S. - Just to make sure, I noticed that rcParamsOrig is only in the maintenance branch. It was intended to leave the development branch "broken" for now until we get this working properly? Index: lib/matplotlib/__init__.py === --- lib/matplotlib/__init__.py (revision 8898) +++ lib/matplotlib/__init__.py (working copy) @@ -762,6 +762,23 @@ # this is the instance used by the matplotlib classes rcParams = rc_params() + +if rcParams['examples.directory']: +# paths that are intended to be relative to matplotlib_fname() +# are allowed for the examples.directory parameter. +# However, we will need to fully qualify the path because +# spinx requires absolute paths. +if not os.path.isabs(rcParams['examples.directory']): +_basedir, _fname = os.path.split(matplotlib_fname()) + +# Sometimes matplotlib_fname() can return relative paths, +# Also, using realpath() guarentees that spinx will use +# the same path that matplotlib sees (in case of weird symlinks). +_basedir = os.path.realpath(_basedir) + +_fullpath = os.path.join(_basedir, rcParams['examples.directory']) +rcParams['examples.directory'] = _fullpath + rcParamsOrig = rcParams.copy() rcParamsDefault = RcParams([ (key, default) for key, (default, converter) in \ -- 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
Re: [matplotlib-devel] Building documentation and matplotlibrc
On Thu, Jan 6, 2011 at 1:24 PM, Benjamin Root wrote: > Ah, all the more reason to apply abspath() or realpath(). To decide which > to use, let's consider the case of someone (like a developer) having > multiple builds of matplotlib in separate directories, and uses a symlink to > point to whichever he wants to use at the moment. > > The question is, in this use-case, would we want the symbolic link pathname, > or the absolute pathname? I don't mess around with docs enough to know > which I would want. > > I have attached a modified patch (which uses realpath(), but could easily be > changed to abspath()). I also included some comments to more fully document > what is going on and the rational for the logic being taken. OK, I incorporated your changes and committed. Thanks. > P.S. - Just to make sure, I noticed that rcParamsOrig is only in the > maintenance branch. It was intended to leave the development branch > "broken" for now until we get this working properly? That's correct, but I just did a big merge of all the branch changes so the trunk is fixed as well now. JDH -- 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
