[GRASS-dev] Python script test

[Michael Barton]

On Jul 20, 2008, at 12:33 PM, Glynn Clements wrote:

>
> Michael Barton wrote:
>
>> I haven't tried this without wxPython, but I thought it was needed  
>> for
>> the parser code. I'll test it with GRASS 6.4
>
> g.parser calls G_parser(); if the module has at least one required
> option but you don't provide any (or if you use --ui), G_parser() will
> call G_gui(), which uses either Tcl/Tk or wxPython depending upon the
> setting of GRASS_GUI (if it's set to wxpython, you get the wxPython
> dialogs, otherwise you get the Tcl/Tk dialogs).
>
> If you have GRASS_GUI=wxpython, it's safe to assume that you have
> wxPython installed. If you have GRASS_GUI=tcltk (or, for that matter,
> GRASS_GUI=text), you'll get the Tcl/Tk GUI. The fact that the script
> which calls g.parser is written in Python doesn't affect it.
>
>> I also wondered about using g.tempfile. The only reason to use it  
>> that
>> I can think of is that the temp file ends up in a GRASS mapset rather
>> than the global gmp directory.
>
> I'm not sure if that's good or bad.
>
> The use of <mapset>/.tmp by G_tempfile() is for a very specific
> reason.
>
> New cell/fcell are created in that directory and rename()d into place
> when the map is closed. But rename() requires that the source and
> destination are on the same partition (rename() just adds and removes
> directory entries; it doesn't "move" the file's contents).
>
> /tmp and /home are often separate partitions, so trying to create
> temporary files in /tmp or $TMPDIR and rename() them into the mapset
> directory will quite possibly fail.
>
> The easiest way to ensure that the file is created on the same
> partition as the mapset's cell/fcell directory is to create the
> temporary files within the mapset directory (if you decide to mount a
> separate partition at <mapset>/.tmp, you lose).
>
> But, unless you're playing filesystem games with rename() (or link()),
> there isn't actually any need for temporary files to go into the
> mapset directory. They could just as easily go into e.g. the
> /tmp/grass-<user>-<pid> directory. That may be more efficient, e.g. if
> /tmp is a hard disk but GISDBASE is on an NFS share.
>
> Ultimately, it doesn't particularly matter. In any case, the grass.py
> module provides a tempfile() function which (currently) uses
> g.tempfile, although it could be changed to use e.g. os.tempnam() if
> that was preferred.

I committed your changes to the r_in_aster.py script and did some tests.

Init.sh is not updating PYTHONPATH on my Mac for some reason. I've  
looked at the code and it seems fine. I DO have a PYTHONPATH. So I'm  
not sure why it is not updating it. If I change it manually, by simply  
pasting your code (export PYTHONPATH="$GISBASE/etc/python: 
$PYTHONPATH") into the GRASS prompt, PYTHONPATH IS modified  
appropriately and r_in_aster.py works fine with the new grass.py  
library.

The only odd difference that I notice is that the source file is  
init.sh and the startup in the binary is Init.sh. This is especially  
odd since case doesn't matter when running programs on a Mac. I'm  
copying William Kyngesbury in case he has some insight.

I set GRASS_GUI=tcltk and restarted GRASS. r_in_aster.py launches with  
a TclTk GUI, even though it is a Python script. What you said made  
sense, but I wanted to test to make sure that something odd didn't  
happen.

With respect to the tempfile question, what happens on Windows when  
you use g.tempfile vs. Python's tempfile.TemporaryFile()? Overall, it  
seems like the Python tempfile module is easier to work with and  
potentially more secure.

Michael