Hi Martin,
wingrass: attempt to define python file association
any idea if this possibly interfere with a file association already set by
other python-installations e.g. from www.python.org?
-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/r54612-grass-trunk-mswindows-wingrass-attempt-to-define-python-file-association-tp5027314.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
Hi Helmut,
2013/1/14 Helmut Kudrnovsky <hellik@web.de>:
wingrass: attempt to define python file association
any idea if this possibly interfere with a file association already set by
other python-installations e.g. from www.python.org?
don't know (I am really not a Windows guy). Probably someone else?
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
2013/1/14 Martin Landa <landa.martin@gmail.com>:
wingrass: attempt to define python file association
any idea if this possibly interfere with a file association already set by
other python-installations e.g. from www.python.org?don't know (I am really not a Windows guy). Probably someone else?
I have used solution from [1]. But it simply overrides existing
association if already defined.
Martin
[1] http://nsis.sourceforge.net/File_Association
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Helmut Kudrnovsky wrote:
> wingrass: attempt to define python file association
any idea if this possibly interfere with a file association already set by
other python-installations e.g. from www.python.org?
Yes; it should be reverted.
A GRASS installer should not attempt to install Python other than by
(possibly) downloading and executing the appropriate installer from
python.org.
For wxGUI, it is sufficient to bundle a "private" Python installation
and set the relevant environment variables in the GRASS startup (but
it should be possible to disable this if the system Python is
compatible with GRASS and wxGUI).
This won't work for general-purpose scripting. The only thing which
*will* work is to have a suitable version of Python (plus any
necessary packages) installed system-wide. And that isn't something
which GRASS can do anything about, nor should it try (other than by
providing advice to the user).
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2013/1/14 Glynn Clements <glynn@gclements.plus.com>:
> wingrass: attempt to define python file association
any idea if this possibly interfere with a file association already set by
other python-installations e.g. from www.python.org?Yes; it should be reverted.
OK, in this case please suggest better solution. Currently after
installing GRASS on Windows, the python scripts (eg. r.reclass.area)
do not work. Usually after launching such command Windows ask the user
for application to use or simply open the script in the text editor.
It's bad.
A GRASS installer should not attempt to install Python other than by
(possibly) downloading and executing the appropriate installer from
python.org.
Currently the native installer contains python which is provided
within osgeo4w framework (taken from python.org ASAR). Agreed, in
other words, do not install python if there is already other python
installed. Any idea how to implement in nsis installer?
For wxGUI, it is sufficient to bundle a "private" Python installation
and set the relevant environment variables in the GRASS startup (but
it should be possible to disable this if the system Python is
compatible with GRASS and wxGUI).
Problem are python scripts (like r.reclass.area), lunched from command
line or wxGUI command prompt.
This won't work for general-purpose scripting. The only thing which
*will* work is to have a suitable version of Python (plus any
necessary packages) installed system-wide. And that isn't something
which GRASS can do anything about, nor should it try (other than by
providing advice to the user).
Hm, not sure. Esri ArcGIS contains also installation of Python. I
would assume that Windows user expect that everything is solved within
installation process.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Mon, Jan 14, 2013 at 9:15 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2013/1/14 Glynn Clements <glynn@gclements.plus.com>:
> wingrass: attempt to define python file association
A GRASS installer should not attempt to install Python other than by
(possibly) downloading and executing the appropriate installer from
python.org.Currently the native installer contains python which is provided
within osgeo4w framework (taken from python.org ASAR).
The python version coming with osgeow4 or wingrass is not a Windows
python, it is a msys python. Windows does not know about it.
Agreed, in
other words, do not install python if there is already other python
installed.
osgeow4 or wingrass do not install python such that the OS (Windows)
is aware of it. For that you need to install python the same way like
e.g.
http://www.python.org/ftp/python/2.7.3/python-2.7.3.msi
does.
This won't work for general-purpose scripting. The only thing which
*will* work is to have a suitable version of Python (plus any
necessary packages) installed system-wide. And that isn't something
which GRASS can do anything about, nor should it try (other than by
providing advice to the user).Hm, not sure. Esri ArcGIS contains also installation of Python.
Esri ArcGIS installs system-wide a true Windows version of Python.
Another possibility is to look at the way e.g. LibreOffice or Gimp
install python on Windows (not system-wide).
I found that problems go away if I install
http://www.python.org/ftp/python/2.7.3/python-2.7.3.msi
which is a true Windows system-wide installation.
my 2c
Markus M
Hi Markus,
2013/1/14 Markus Metz <markus.metz.giswork@gmail.com>:
Currently the native installer contains python which is provided
within osgeo4w framework (taken from python.org ASAR).The python version coming with osgeow4 or wingrass is not a Windows
python, it is a msys python. Windows does not know about it.
are you sure about it? See [1].
Martin
[1] http://trac.osgeo.org/osgeo4w/wiki/pkg-python/Python27
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Mon, Jan 14, 2013 at 10:45 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi Markus,
2013/1/14 Markus Metz <markus.metz.giswork@gmail.com>:
Currently the native installer contains python which is provided
within osgeo4w framework (taken from python.org ASAR).The python version coming with osgeow4 or wingrass is not a Windows
python, it is a msys python. Windows does not know about it.are you sure about it? See [1].
According to [1], the python files are first copied to a different
location, then the(-core, -help, -wrapper packages are created.
Windows does not know about it, what the osgeo4w user gets is not a
system-wide Windows installation, python is only available within the
osgeo4w msys environment.
Markus M
Martin
[1] http://trac.osgeo.org/osgeo4w/wiki/pkg-python/Python27
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Markus Metz wrote:
> Hm, not sure. Esri ArcGIS contains also installation of Python.
Esri ArcGIS installs system-wide a true Windows version of Python.
Another possibility is to look at the way e.g. LibreOffice or Gimp
install python on Windows (not system-wide).
AFAIK, those packages only support Python scripting within the
application. That's the easy case.
A system-wide installation means that you can "execute" Python scripts
from a command prompt, from batch files, with system(),
subprocess.Popen(), etc, in the same way that you can execute batch
files (CreateProcess() only works for binary executables, so scripts
can never truly be first-class citizens on Windows).
I found that problems go away if I install
http://www.python.org/ftp/python/2.7.3/python-2.7.3.msi
which is a true Windows system-wide installation.
Right. But this isn't something which GRASS can do unconditionally.
The user may already have a system-wide Python installation for other
reasons, and blindly replacing it with a different version will break
that.
Also, if the user has a system-wide Python, any packages (e.g.
wxPython, numpy, etc) have to match that specific version.
In particular, if the user has Python 3.x, they are almost certainly
going to require the Python launcher:
http://docs.python.org/3/using/windows.html#launcher
For this situation, GRASS can set PY_PYTHON in sthe environment to
force a specific Python interpreter within a GRASS session.
It *might* be feasible to bundle the launcher and, if necessary,
forcibly associate the .py extension with the launcher. This could be
acceptable provided that we can be sure that the existing behaviour is
preserved for non-GRASS Python scripts.
As a last resort, we might need to install Python scripts with a
different extension (e.g. .gpy) to allow them to be associated with a
specific Python interpreter without affecting other packages which use
Python (e.g. ArcGIS).
Note that we will be running into similar issues on Linux as some
distributions start using Python 3.x for "/usr/bin/python". But on
Linux, the fix is much simpler: use "#!/usr/bin/env python" and put a
symlink from $GISBASE/bin/python to any Python 2.x interpreter.
--
Glynn Clements <glynn@gclements.plus.com>