matplotlib-devel Mailing List for matplotlib

On Wednesday 22 June 2005 06:35 pm, Fernando Perez wrote:
> Stephen Walton wrote:
> > Fernando Perez wrote:
> >>Well, it could be something like $HOME/.tex.cache, where $HOME can be
> >>determined via a routine like the below (this is what ipython uses to
> >>try and guess a sensible value for $HOME):
> >
> > I *like* it.
>
> Though I'd personally vote for matplotlib holding $HOME/.matplotlib/ as a
> directory, and putting in there a tex.cache dir, the matplotlibrc file, and
> anything else it may need in the future.
I second that notion. In fact, I have been meaning to suggest this on the list 
for some time now. Thank for reminding me.
> I *really* don't like the idea that matplotlib will begin to put a bunch of
> differently named things under $HOME with various .foo names. Ipython also
> started with .ipythonrc, and I quickly moved to an .ipython/ directory,
> where I stuff anything I need. It's future-proof, clean, and gives an easy
> way for users to clean up if needed, without having to guess 'how many dot
> files/directories does this thing create'?
>
> So if you were to ask for my opinion, I'd vote +100 on matplotlib moving to
> a single directory for holding *ALL* user and configuration data, which
> would default to $HOME/.matplotlib, and which could be overridden if the
> $MATPLOTLIBDIR environment variable is defined. That's exactly how ipython
> works, so it must be the perfect solution :)
+101
Darren

Stephen Walton wrote:
> Fernando Perez wrote:
> 
> 
>>Well, it could be something like $HOME/.tex.cache, where $HOME can be 
>>determined via a routine like the below (this is what ipython uses to 
>>try and guess a sensible value for $HOME):
> 
> 
> I *like* it.
Though I'd personally vote for matplotlib holding $HOME/.matplotlib/ as a 
directory, and putting in there a tex.cache dir, the matplotlibrc file, and 
anything else it may need in the future.
I *really* don't like the idea that matplotlib will begin to put a bunch of 
differently named things under $HOME with various .foo names. Ipython also 
started with .ipythonrc, and I quickly moved to an .ipython/ directory, where 
I stuff anything I need. It's future-proof, clean, and gives an easy way for 
users to clean up if needed, without having to guess 'how many dot 
files/directories does this thing create'?
So if you were to ask for my opinion, I'd vote +100 on matplotlib moving to a 
single directory for holding *ALL* user and configuration data, which would 
default to $HOME/.matplotlib, and which could be overridden if the 
$MATPLOTLIBDIR environment variable is defined. That's exactly how ipython 
works, so it must be the perfect solution :)
Cheers,
f

Fernando Perez wrote:
> Well, it could be something like $HOME/.tex.cache, where $HOME can be 
> determined via a routine like the below (this is what ipython uses to 
> try and guess a sensible value for $HOME):
I *like* it.

Stephen Walton wrote:
> Fernando Perez wrote:
> 
> 
>>It may be simpler than that:
> 
> 
> So os.environ does change the environment under Python and its 
> children. The remaining question is what should TEXMFOUTPUT be? 
> /home/user/.tex.cache will not work across all platforms.
Well, it could be something like $HOME/.tex.cache, where $HOME can be 
determined via a routine like the below (this is what ipython uses to 
try and guess a sensible value for $HOME):
#----------------------------------------------------------------------------
class HomeDirError(Error):
 pass
def get_home_dir():
 """Return the closest possible equivalent to a 'home' directory.
 We first try $HOME. Absent that, on NT it's $HOMEDRIVE\$HOMEPATH.
 Currently only Posix and NT are implemented, a HomeDirError 
exception is
 raised for all other OSes. """ #'
 try:
 return os.environ['HOME']
 except KeyError:
 if os.name == 'posix':
 raise HomeDirError,'undefined $HOME, IPython can not proceed.'
 elif os.name == 'nt':
 # For some strange reason, win9x returns 'nt' for os.name.
 try:
 return 
os.path.join(os.environ['HOMEDRIVE'],os.environ['HOMEPATH'])
 except:
 try:
 # Use the registry to get the 'My Documents' folder.
 import _winreg as wreg
 key = wreg.OpenKey(wreg.HKEY_CURRENT_USER,
 
"Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders")
 homedir = wreg.QueryValueEx(key,'Personal')[0]
 key.Close()
 return homedir
 except:
 return 'C:\\'
 elif os.name == 'dos':
 # Desperate, may do absurd things in classic MacOS. May 
work under DOS.
 return 'C:\\'
 else:
 raise HomeDirError,'support for your operating system not 
implemented.'
Cheers,
f

Fernando Perez wrote:
> It may be simpler than that:
So os.environ does change the environment under Python and its 
children. The remaining question is what should TEXMFOUTPUT be? 
/home/user/.tex.cache will not work across all platforms.

Stephen Walton wrote:
> John Hunter wrote:
> 
> 
>>We might have to do something like
>>
>> os.popen('export TEXMFOUTPUT=/some/path; run some command')
>>
>>and then deal with platform and shell dependent differences in how to
>>set environment variables. Is there a better way? Me thinks it is
>>better to make this a FAQ and advise people working in non-writable
>>dirs to set this var themselves.
>>
> 
> I agree with this last. On Unix, you could do
> 
> os.popen('/bin/sh -c "export TEXMFOUTPUT=/some/path; run some command"')
> 
> and be pretty sure it would work on all systems. But Windows would be a 
> pain. I agree with the FAQ solution. This seems like a very rare 
> problem to me, to be honest.
It may be simpler than that:
planck[~/test]> cat env.py
#!/usr/bin/env python
import os
print 'before'
os.system('env | grep TEXMFOUTPUT')
os.environ['TEXMFOUTPUT'] = '/some/path'
print 'after'
os.system('env | grep TEXMFOUTPUT')
planck[~/test]> ./env.py
before
after
TEXMFOUTPUT=/some/path
planck[~/test]>
Cheers,
f

John Hunter wrote:
>We might have to do something like
>
> os.popen('export TEXMFOUTPUT=/some/path; run some command')
>
>and then deal with platform and shell dependent differences in how to
>set environment variables. Is there a better way? Me thinks it is
>better to make this a FAQ and advise people working in non-writable
>dirs to set this var themselves.
>
I agree with this last. On Unix, you could do
os.popen('/bin/sh -c "export TEXMFOUTPUT=/some/path; run some command"')
and be pretty sure it would work on all systems. But Windows would be a 
pain. I agree with the FAQ solution. This seems like a very rare 
problem to me, to be honest.

On Jun 21, 2005, at 1:09 PM, John Hunter wrote:
> Fernando> I also just saw pylab crash when a user was trying to
> Fernando> run with $PWD being something he didn't have write
> Fernando> access to. Are there any checks in the code to fall
> Fernando> back to /tmp or something sensible if texmanager can't
> Fernando> write the temp files it needs? Sorry for not giving a
> Fernando> traceback, but I only saw this on someone else's screen
> Fernando> while helping them, and for some odd reason it's not
> Fernando> happening on my box.
>
> This is probably failing on the tex/latex temporary files. I spent
> some time initially trying to figure out how to get these to go into
> ~/.tex.cache but didn't succeed. If anyone knows how to direct
> tex/latex to put the various *.aux, *.log, etc, files in a specified
> directory, pass it my way.
I get this when mpl complains about not being able to create a 
.ttffont.cache (or whatever it's called) file. I'll submit a bug on 
the tracker later.
Cheers!
Andrew

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:
 Stephen> TEXMFOUTPUT Normally, TeX puts its output files in
 Stephen> the current directory. If any output file cannot be
 Stephen> opened there, it tries to open it in the directory
 Stephen> specified in the environment variable TEXM- FOUTPUT.
 Stephen> There is no default value for that variable. For
 Stephen> example, if you say tex paper and the current directory
 Stephen> is not writable, if TEXMFOUTPUT has the value /tmp, TeX
 Stephen> attempts to create /tmp/paper.log (and /tmp/paper.dvi, if
 Stephen> any output is produced.)
Hmm, that looks familiar -- I think I did come across that. But this
will be a bit of a pain to set from matplotlib, since we are making
calls to os.popen. We might have to do something like
 os.popen('export TEXMFOUTPUT=/some/path; run some command')
and then deal with platform and shell dependent differences in how to
set environment variables. Is there a better way? Me thinks it is
better to make this a FAQ and advise people working in non-writable
dirs to set this var themselves.
Thanks for the help...
JDH