Hi All,
On 28/01/14 17:05, Moritz Lennert wrote:
On 28/01/14 12:07, Markus Metz wrote:
On Mon, Jan 27, 2014 at 12:16 AM, Glynn Clements
"Executing" a script uses the registry associations for the script's
extension.
This matters for using os.system("python.exe <script>") from within
a Python script, right?
WinGRASS does not set registry associations for Python scripts, nor
does it install Python system-wide. This is because we do not want to
modify an existing Python installation.
And I think that part should never be changed.
And that is what is currently causing the issues AFAIU: when calling a
.py script (or at least when a .py script is called from a .py script)
the system-wide installation is called and if that is not compatible, we
have an issue. But as mentioned elsewhere in this thread, it is even
more complicated because in certain situations is the the GRASS Python
interpreter which is called, but some of the libraries used are those of
the system-wide installation.
FWIW, I would start by modifying %PATH% before running os.system(),
so that the bundled python.exe and all of its DLLs are in the Windows
path, preceeding any other folders from which a system-wide Python
could pick them up. Worth a try, I think, before moving on to more
complex solutions. In addition, one should probably never use
os.system("python.exe"), but rather os.system("path-to-bundled-
python\python.exe")
If this helps, it would be straight-forward to replace
all os.system() calls in all existing scripts with a version that
first sets the path correctly -- and then never use os.system()
directly in a GRASS script.
Another approach would be to have GRASS modify the local registry
settings for the Python shell association, then restore the previous
settings upon exit -- but that would be rather messy.
Best,
Ben
Out of the current discussion I see the following options:
- Leave correct system-wide installation to the user and not to the
GRASS-dev team. This could include some help in form of installation
check and proposal for installation during WinGRASS install and adequate
doc.
- Try to make sure that any call to any Python script in GRASS is done
via the GRASS Python interpreter (through .bat scripts, with adquate
GRASS_PYTHON settings, etc). I'm not sure how we can ensure that none of
the system-wide libraries are called in this case (e.g. MAXREPEAT issue).
- Creating a virtualenv when installing/launching GRASS and executing
all Python calls within this virtualenv. AFAIU, this means that those
who want to combine other Python tools with GRASS either have to install
them all in that virtualenv.
- Maybe use the Python launcher, set a specific Python version through
the launcher and explicitely call that version in GRASS. Again, I don't
know how well this works with other Python installations (in my small
experiment I had trouble mixing Python 2 and 3 [1].
In summary, again within the limits of my understanding, it seems that
the choices are between
1) how much burden we put on the user or not
2) how much we want to encapsulate GRASS into an isolated Python
environment, possibly making interaction with other Python tools on the
system more difficult.
All obviously with the additional question of how much dev power we
can/want to put into this issue.
I also have to say that I prefer that we take the time to find a good
solution, despite all the frustration this is creating.
Moritz
[1] http://lists.osgeo.org/pipermail/grass-dev/2013-July/065197.html
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
benducke@fastmail.fm