On Wed, Apr 9, 2014 at 4:07 AM, Glynn Clements gl...@gclements.plus.com wrote:
Packages which include command-line programs (e.g. compilers)
typically either modify the environment variables (e.g. PATH) via the
registry[1], or provide a .bat/.cmd file which must be run to set up
the
Hi Markus,
2014-05-07 21:50 GMT+02:00 Markus Metz markus.metz.gisw...@gmail.com:
On Wed, Apr 30, 2014 at 9:51 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
By all means provide fall-backs, workarounds, alternatives, or
whatever, but anything which tries to make
On Thu, May 8, 2014 at 9:22 AM, Sören Gebbert
soerengebb...@googlemail.comwrote:
On MS Windows, users do have a free choice of what they install. Third
party software packages are on MS Windows completely independent of
each other. If you don't like this, you have to change the MS Windows
On Thu, May 8, 2014 at 9:52 AM, Vaclav Petras wenzesl...@gmail.com wrote:
On Thu, May 8, 2014 at 9:22 AM, Sören Gebbert
soerengebb...@googlemail.com wrote:
On MS Windows, users do have a free choice of what they install. Third
party software packages are on MS Windows completely
Vaclav Petras wrote:
I think this is very common in companies and public institutions. I
know several companies with much more restrictive guideline (no
internet connection, USB sticks not allowed, ...). So you can't expect
that user have a free choice.
Hi, I don't understand how this
On Wed, Apr 30, 2014 at 9:51 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
By all means provide fall-backs, workarounds, alternatives, or
whatever, but anything which tries to make such things mandatory is
going to get reverted. Again.
really nice attitude
Markus Metz wrote:
People installing GRASS want to use GRASS. They want GRASS to work out
of the box. They can use any Python version they want, as long as
WinGRASS uses its embedded Python version. Users will not notice it.
You're assuming that users have a free choice as to what they
Markus Metz wrote:
GRASS has to check each time it is started if a compatible system-wide
.py file association is available. This is IMHO nonsense.
Performing that test would be nonsense.
Any application depends upon certain functionality being provided by
the underlying platform. There are
Moritz Lennert wrote:
Can everyone agree on that solution (not meaning that you consider it
the best solution, but that you can live with it) ?
I can live with anything that doesn't require significant work to undo
(i.e. revert to the state where the platform's native mechanisms are
used
On 27/04/14 22:52, Markus Metz wrote:
I do not understand this ongoing discussion on WinGRASS7+Python. My
proposed solution caters for all possibilities, in particular:
- an existing incompatible .py file assocation
[add your workaround here]
- changes in any existing .py file association
On Mon, Apr 28, 2014 at 9:37 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
...
From the current discussion I take that the .bat file solution is one that
will satisfy those who want GRASS to just work on MS Windows without
putting any burden on the user. In order to not dissatisfy
Hamish wrote:
I think that's more a reflection on the way things are done in the MS
Windows world: the last program to install itself wins.
yes
Which leads to
the usual 1st trouble shooting step on Windows after seeing if a
rebooting helps: try uninstalling then reinstalling the program. Then
On Sat, Apr 26, 2014 at 1:16 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Martin Landa wrote:
By all means provide fall-backs, workarounds, alternatives, or
whatever, but anything which tries to make such things mandatory is
going to get reverted. Again.
really nice attitude ;-)
I do not understand this ongoing discussion on WinGRASS7+Python. My
proposed solution caters for all possibilities, in particular:
- an existing incompatible .py file assocation
[add your workaround here]
- changes in any existing .py file association after GRASS has been installed
[add your
Markus Metz wrote:
ESRI assumes that their system-wide Python installation will never
change. That is rather ignorant. I don't think GRASS should mimik the
aggnorant ignorance of ESRI.
I think that's more a reflection on the way things are done in the MS
Windows world: the last program to
On Sun, Apr 27, 2014 at 7:34 PM, Hamish hamish.webm...@gmail.com wrote:
Markus Metz wrote:
ESRI assumes that their system-wide Python installation will never
change. That is rather ignorant. I don't think GRASS should mimik the
aggnorant ignorance of ESRI.
I think that's more a
Markus Metz wrote:
It's easier to check if the file is a python script and if so than
to force to use bundled version of Python.
So long as I have commit access, GRASS isn't going to be forcing the
use of a non-system Python.
But an existing system Python on MS Windows can change or
Martin Landa wrote:
By all means provide fall-backs, workarounds, alternatives, or
whatever, but anything which tries to make such things mandatory is
going to get reverted. Again.
really nice attitude ;-) Martin
At least I'm not saying you ARE going to use our version of Python,
2014-04-26 13:16 GMT+02:00 Glynn Clements gl...@gclements.plus.com:
At least I'm not saying you ARE going to use our version of Python,
whether you like it or not.
please ask the Windows users, 99.9% they don't care or they will not
understand your question. The question is completely
On Sat, Apr 26, 2014 at 6:42 AM, Glynn Clements gl...@gclements.plus.comwrote:
It's easier to check if the file is a python script and if so than
to force to use bundled version of Python.
So long as I have commit access, GRASS isn't going to be forcing the
use of a non-system
wenzeslaus wrote
Please consider this scenario:
1. user installs ArcGIS which installs Python system-wide
2. user installs GRASS GIS which will use system-wide Python
2. may or may not work out of the box ... there are a lot of uncertain
issues to consider (version, dependencies, etc. etc.)
On Fri, Apr 25, 2014 at 5:18 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Martin Landa wrote:
It's easier to check if the file is a python script and if so than
to force to use bundled version of Python.
So long as I have commit access, GRASS isn't going to be forcing the
use of a
Hi,
2014-04-25 9:36 GMT+02:00 Markus Metz markus.metz.gisw...@gmail.com:
It's easier to check if the file is a python script and if so than
to force to use bundled version of Python.
So long as I have commit access, GRASS isn't going to be forcing the
use of a non-system Python.
But an
2014-04-25 5:18 GMT+02:00 Glynn Clements gl...@gclements.plus.com:
By all means provide fall-backs, workarounds, alternatives, or
whatever, but anything which tries to make such things mandatory is
going to get reverted. Again.
really nice attitude ;-) Martin
--
Martin Landa *
On Fri, Apr 25, 2014 at 4:18 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 25/04/14 09:36, Markus Metz wrote:
On Fri, Apr 25, 2014 at 5:18 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Martin Landa wrote:
It's easier to check if the file is a python script and if so
Martin Landa wrote:
It's easier to check if the file is a python script and if so than
to force to use bundled version of Python.
So long as I have commit access, GRASS isn't going to be forcing the
use of a non-system Python.
By all means provide fall-backs, workarounds, alternatives, or
On Wed, Apr 23, 2014 at 1:37 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
Therefore it is IMHO not a good idea to rely on a system-wide Python
file association on MS Windows,
Regardless of whether or not it's a good idea, it's not entirely
avoidable.
Sure it is.
Hi,
2014-04-23 21:56 GMT+02:00 Markus Metz markus.metz.gisw...@gmail.com:
Batch files are a better solution, as they don't affect anything else,
and it's a simple matter to either delete them or modify PATH to
ignore them, and use the Python scripts directly.
Sounds good.
I am not sure,
Glynn:
Batch files are a better solution, as they don't affect anything else,
and it's a simple matter to either delete them or modify PATH to
ignore them, and use the Python scripts directly.
MMetz:
Sounds good.
Martin:
I am not sure, what about user scripts?
a new g.batwrap helper
A short comment about GRASS as a monolithic application or not:
On every OS where I tested various GRASS versions (I tested on various
Linux distros, on various FreeBSD versions, on various NetBSD
versions, on 2 Solaris versions and helped give IBM AIX a try) and on
all these OS's I started GRASS
Markus Metz wrote:
There seems to be agreement that changing an existing Python file
association is not a good idea.
The problem is that every possible solution has some aspect which is
not a good idea.
An existing Python file association on MS Windows can change or
disappear any time, and
On 13/04/14 20:32, Jürgen E. Fischer wrote:
And IMHO the broader topics would have been better addressed in (a) separate
thread(s) and not side-track this one. Your original problem got out of focus,
but still isn't solved, is it?
IMHO, the broader topics are the core of this thread !
;-)
On 13/04/14 20:33, Martin Landa wrote:
2014-04-13 17:03 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be:
On 11/04/14 13:05, Martin Landa wrote:
I don't think this a very helpful attitude. This whole debate is not about
one bad guy keeping the rest of the good guys from moving forward.
On 14/04/14 00:21, Helmut Kudrnovsky wrote:
Hi Moritz,
1) Should GRASS be the same (i.e. feature parity) on all platforms ?
for sure, why not?
Not to single out MarkusM, but just since he formulated it so clearly:
On 09/04/14 08:16, Markus Metz wrote:
On Windows, GRASS should behave like
2014-04-14 9:53 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be:
There is quite a large margin between creating a monolithic application with
everything bundled and leaving the user alone...
To answer Martin's call for concrete action: how difficult would it be for
you, Helmut, to
So, there is a vision by some that for the reasons of apparent
incompatibility between the way GRASS works and Windows,
GRASS has to
be different on windows. I.e. that GRASS has to become a monolithic
application on Windows.
I wouldn't call it incompatibility and I think GRASS hasn't to be
Moritz Lennert wrote:
the argument that GRASS4Win should be a different beast
than GRASS4NIX in that it should become a monolithic integrated
application, which, IMHO, fundamentally alters the very nature of what
GRASS is.
There's no fundamental reason why we can't have Lite and Full
Helmut Kudrnovsky wrote:
not including python, have a look here:
http://trac.osgeo.org/grass/browser/grass/trunk/mswindows/GRASS-Packager.bat.tmpl#L113
@echo Copy Python content to PACKAGE_DIR\Python27
and then maybe you have to adapt the starting script and all other ?!
I'm
On 11/04/14 13:05, Martin Landa wrote:
Hi Jurgen,
2014-04-11 12:42 GMT+02:00 Jürgen E. j...@norbit.de:
although the architecture may differ, we may get some inspiration for python
windows handling from other GIS projects like QGIS?
in QGIS python is also in heavy use, e.g. QGIS processing
On 13/04/14 17:03, Moritz Lennert wrote:
[...]
I don't think this a very helpful attitude. This whole debate is not
about one bad guy keeping the rest of the good guys from moving forward.
First of all, Glynn is not alone in his position.
I agree. I tend to take a conservative view,
2014-04-13 17:03 GMT+02:00 Moritz Lennert mlenn...@club.worldonline.be:
On 11/04/14 13:05, Martin Landa wrote:
I don't think this a very helpful attitude. This whole debate is not about
one bad guy keeping the rest of the good guys from moving forward. First of
all, Glynn is not alone in his
Hi Moritz,
On Sun, 13. Apr 2014 at 17:03:17 +0200, Moritz Lennert wrote:
On 11/04/14 13:05, Martin Landa wrote:
2014-04-11 12:42 GMT+02:00 Jürgen E. j...@norbit.de:
That way you could use the stock sources and wouldn't have to use patches
when packaging (which would have been my pragmatic
nobody is saying anything about a bad gay, it's your feeling not mine
well, I meant a guy of course :-) I hope that there is at least a
reason to smile ;-) Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
grass-dev mailing list
Hi Moritz,
1) Should GRASS be the same (i.e. feature parity) on all platforms ?
for sure, why not?
2) How much less effort can we ask of Windows users than we ask of users
of other platforms ?
GRASS was developed in a time when Windows didn't even exist. And it was
developed in a very
On Sun, Apr 13, 2014 at 12:52 PM, Benjamin Ducke bendu...@fastmail.fmwrote:
But please: Let's keep (minor) version-specific Python support
and all of its associated problems out of the core release.
I really believe that this whole conundrum was caused by not
taking that step earlier.
The
Hi Jürgen,
Hi Helmut,
[...]
Not sure if I want to participate in this thread.
thanks for sharing your experience anyway.
I think a system installation of python is uncommon.
yes I'm also thinking so if windows comes in ...
[...]
And
thereby avoid having special treatment for .py scripts
thanks also for the link! that's all about we're discussing here.
Python Launcher
just forgotten, some ugly tests for Python Launcher:
http://trac.osgeo.org/grass/ticket/2015#comment:6
-
best regards
Helmut
--
View this message in context:
Hi Helmut,
On Thu, 10. Apr 2014 at 14:34:04 -0700, Helmut Kudrnovsky wrote:
although the architecture may differ, we may get some inspiration for python
windows handling from other GIS projects like QGIS?
in QGIS python is also in heavy use, e.g. QGIS processing framework, python
addons,
Hi Jurgen,
2014-04-11 12:42 GMT+02:00 Jürgen E. j...@norbit.de:
although the architecture may differ, we may get some inspiration for python
windows handling from other GIS projects like QGIS?
in QGIS python is also in heavy use, e.g. QGIS processing framework, python
addons, integrated
Helmut Kudrnovsky wrote:
although the architecture may differ, we may get some inspiration for python
windows handling from other GIS projects like QGIS?
in QGIS python is also in heavy use, e.g. QGIS processing framework, python
addons, integrated python shell, etc. AFAIK they're
[...]
GRASS 6 creates a .bat file for each shell script.
And this .bat file specifies the script interpreter. Looks like a good
solution to also select the correct Python version.
[...]
Other projects also bypass the standard execution mechanism of python
scripts, and they work just fine in MS
On Tue, Apr 8, 2014 at 11:23 PM, Vaclav Petras wenzesl...@gmail.com wrote:
On Tue, Apr 8, 2014 at 3:22 PM, Markus Metz markus.metz.gisw...@gmail.com
wrote:
IMHO, what you say is that GRASS and MS Windows are incompatible by
principle, and you will not succeed in making MS Windows compatible
On Wed, Apr 9, 2014 at 3:44 AM, Glynn Clements gl...@gclements.plus.com wrote:
Markus Metz wrote:
All of this goes out the window if you want to provide a command-line
environment, whether an interactive shell or the ability to execute
commands via system() or CreateProcess().
It works
On 09/04/14 08:16, Markus Metz wrote:
On Wed, Apr 9, 2014 at 3:44 AM, Glynn Clements gl...@gclements.plus.com wrote:
[...]
In spite of wxGUI, GRASS remains fundamentally a collection of
command-line modules, more like a library than an application.
I make use of this property daily. On MS
On Wed, Apr 9, 2014 at 2:16 AM, Markus Metz
markus.metz.gisw...@gmail.comwrote:
On Wed, Apr 9, 2014 at 3:44 AM, Glynn Clements gl...@gclements.plus.com
wrote:
Markus Metz wrote:
All of this goes out the window if you want to provide a command-line
environment, whether an interactive
Markus Metz wrote:
I basically agree with user expectations you stated. But I would like to
note that recently, I met several users which wanted and expected that GRASS
script will run outside GRASS without any special environment setup in the
script itself.
AFAIK, GRASS scripts
Markus Metz wrote:
In spite of wxGUI, GRASS remains fundamentally a collection of
command-line modules, more like a library than an application.
I make use of this property daily. On MS Windows, GRASS should by
default behave like a stand-alone application. You can make use of the
Vaclav Petras wrote:
And this .bat file specifies the script interpreter. Looks like a good
solution to also select the correct Python version.
I'm afraid how will work for user scripts. Typical case will be that user
has some Python, so he or she will try to run from outside if he or
On Thu, Mar 6, 2014 at 10:08 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
.py is supposed to be associated with a Python interpreter, and
the stock Python installer will do that.
.py is not supposed to be associated with a Python interpreter that is
installed
Markus Metz wrote:
All of this goes out the window if you want to provide a command-line
environment, whether an interactive shell or the ability to execute
commands via system() or CreateProcess().
It works in GRASS 6 with shell scripts. I am sure the same mechanism
will work just as
Vaclav Petras wrote:
I basically agree with user expectations you stated. But I would like to
note that recently, I met several users which wanted and expected that
GRASS script will run outside GRASS without any special environment setup
in the script itself. Perhaps, ArcGIS sets the
Markus Metz wrote:
.py is supposed to be associated with a Python interpreter, and
the stock Python installer will do that.
.py is not supposed to be associated with a Python interpreter that is
installed system-wide
It certainly is, because that's what the stock Python installer will
On Wed, Feb 19, 2014 at 3:56 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
It's fairly trivial to set a valid GRASS environment globally, so that
commands are usable in any shell. That's how I've had it on Linux
since roughly forever; I don't run the grass70
Markus Metz wrote:
It's fairly trivial to set a valid GRASS environment globally, so that
commands are usable in any shell. That's how I've had it on Linux
since roughly forever; I don't run the grass70 script unless I'm
testing it.
At the very least, GRASS needs to clean up
On Tue, Feb 11, 2014 at 5:39 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
This is the fundamental difference and the reason why using a
system-wide Python can only cause trouble on Windows. On Windows, a
software package typically includes everything it needs to run,
On Fri, Feb 14, 2014 at 3:41 AM, Enrico Gallo enrico.ga...@gmail.comwrote:
Dear list,
in my very limited experience, the same Python script for GRASS always
runs without problems inside QGIS-GRASS Processing Plugin but
sometimes fails in GRASS Enviroment, if other Python are installed on
Benjamin Ducke wrote:
How would users choose mapsets or create new ones in this
scenario?
With g.mapset.
Things get marginally more complex if you either need multiple
versions installed concurrently, or multiple concurrent sessions.
The former is seldom supported, particularly for
Markus Metz wrote:
This is the fundamental difference and the reason why using a
system-wide Python can only cause trouble on Windows. On Windows, a
software package typically includes everything it needs to run,
On Windows, a software package is typically a monolithic executable
with no
Glynn Clements wrote:
Markus Metz wrote:
Other projects such as gimp or libreoffice are AFAICT reasonably
bundled with Python, without a Python installer.
They aren't attempting to support Python scripts as stand-alone
programs (i.e. something which can be run from the command prompt,
On 10/02/14 09:57, Markus Metz wrote:
Glynn Clements wrote:
This is my entire point. But that cannot be achieved if you're relying
upon hard-coded special treatment for Python scripts. If Python
scripts cannot simply be executed (via system() or subprocess.Popen()
or whatever) in the same
Therefore we need
hard-coded special treatment for shell and Python scripts in order to
make sure that the correct interpreter is used.
Just for my understanding: When you say hard-coded special treatment for
shell scripts, are you speaking about the .bat files ?
I think yes.
-
best
On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky hel...@web.de wrote:
Therefore we need
hard-coded special treatment for shell and Python scripts in order to
make sure that the correct interpreter is used.
Just for my understanding: When you say hard-coded special treatment for
shell
On 10/02/14 11:46, Markus Metz wrote:
On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky hel...@web.de wrote:
Therefore we need
hard-coded special treatment for shell and Python scripts in order to
make sure that the correct interpreter is used.
Just for my understanding: When you say
On Mon, Feb 10, 2014 at 12:04 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 10/02/14 11:46, Markus Metz wrote:
On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky hel...@web.de wrote:
Therefore we need
hard-coded special treatment for shell and Python scripts in order to
make
On Mon, Feb 10, 2014 at 8:41 AM, Markus Metz
markus.metz.gisw...@gmail.comwrote:
On Mon, Feb 10, 2014 at 12:04 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 10/02/14 11:46, Markus Metz wrote:
On Mon, Feb 10, 2014 at 11:26 AM, Helmut Kudrnovsky hel...@web.de
wrote:
GRASS Python scripts are currently executed using the system-wide
installed Python if it exists. No attempt has been made to explicitly
use GRASS_PYTHON, therefore it is not possible to say if the system's
Python would really be completely ignored.
it is (partly) implemented ( and tested on Win7
wenzeslaus wrote
If I remember correctly, Python scripts were not working from Python
scripts, they were working from command line. And we were not able to
explain why the right Python (or Python DLL) is used at one point but not
the other. If there wouldn't be shell=True [1], I would say that
On Mon, Feb 10, 2014 at 2:17 PM, Markus Metz
markus.metz.gisw...@gmail.comwrote:
On Mon, Feb 10, 2014 at 6:44 PM, Vaclav Petras wenzesl...@gmail.com
wrote:
On Mon, Feb 10, 2014 at 8:41 AM, Markus Metz
markus.metz.gisw...@gmail.com
wrote:
On Mon, Feb 10, 2014 at 12:04 PM, Moritz
On Mon, Feb 10, 2014 at 8:29 PM, Vaclav Petras wenzesl...@gmail.com wrote:
On Mon, Feb 10, 2014 at 2:17 PM, Markus Metz markus.metz.gisw...@gmail.com
wrote:
On Mon, Feb 10, 2014 at 6:44 PM, Vaclav Petras wenzesl...@gmail.com
wrote:
On Mon, Feb 10, 2014 at 8:41 AM, Markus Metz
Markus Neteler wrote:
The difference is that you don't start GRASS. You set the required
environment variables from e.g. ~/.profile so that GRASS commands work
in any shell (or via any other execution mechanism, e.g. M-! from
within Emacs).
This is hardly feasible for the majority of
On 08/02/14 20:41, Glynn Clements wrote:
Markus Neteler wrote:
The difference is that you don't start GRASS. You set the required
environment variables from e.g. ~/.profile so that GRASS commands work
in any shell (or via any other execution mechanism, e.g. M-! from
within Emacs).
This
hi,
But there are also downsides to this: We would need to think about
different mechanisms for each supported OS; we could get tangled up in
all sorts of flawed decisions by the OS designers;
I think we are already there regarding MS windos OS and python ...
Whatever the decision may be:
Markus Neteler wrote:
It's fairly trivial to set a valid GRASS environment globally, so that
commands are usable in any shell. That's how I've had it on Linux
since roughly forever; I don't run the grass70 script unless I'm
testing it.
FWIW, I want to make that the default mode of
On Fri, Feb 7, 2014 at 11:49 AM, Glynn Clements gl...@gclements.plus.comwrote:
Markus Neteler wrote:
It's fairly trivial to set a valid GRASS environment globally, so that
commands are usable in any shell. That's how I've had it on Linux
since roughly forever; I don't run the grass70
On Fri, Feb 7, 2014 at 5:49 PM, Glynn Clements gl...@gclements.plus.com wrote:
Markus Neteler wrote:
It's fairly trivial to set a valid GRASS environment globally, so that
commands are usable in any shell. That's how I've had it on Linux
since roughly forever; I don't run the grass70
Glynn Clements wrote
Markus Metz wrote:
Other projects such as gimp or libreoffice are AFAICT reasonably
bundled with Python, without a Python installer.
They aren't attempting to support Python scripts as stand-alone
programs (i.e. something which can be run from the command prompt,
On Wed, Feb 5, 2014 at 5:19 PM, Glynn Clements gl...@gclements.plus.com wrote:
...
It's fairly trivial to set a valid GRASS environment globally, so that
commands are usable in any shell. That's how I've had it on Linux
since roughly forever; I don't run the grass70 script unless I'm
testing
Vaclav Petras wrote:
But with the
latest Python developments, it will be a real challenge to
integrate GRASS 7 in the same way that we could integrate
GRASS 6 into a host application (i.e. without messing
around with any system settings).
Can you be more specific? It sounds like
Markus Metz wrote:
Other projects such as gimp or libreoffice are AFAICT reasonably
bundled with Python, without a Python installer.
They aren't attempting to support Python scripts as stand-alone
programs (i.e. something which can be run from the command prompt,
batch files, etc).
Markus Metz wrote:
Other projects such as gimp or libreoffice are AFAICT reasonably
bundled with Python, without a Python installer.
They aren't attempting to support Python scripts as stand-alone
programs (i.e. something which can be run from the command prompt,
batch files, etc).
A
On 04/02/14 11:29, Glynn Clements wrote:
Markus Metz wrote:
I agree. It seems that the wxGUI always uses the bundled GRASS_PYTHON,
the reason why the wxGUI works fine without a system-wide Python.
That was done so that the system Python doesn't need to have wxPython
installed. Note that
Hi there,
On 04/02/14 13:24, Moritz Lennert wrote:
On 04/02/14 11:29, Glynn Clements wrote:
Markus Metz wrote:
I agree. It seems that the wxGUI always uses the bundled GRASS_PYTHON,
the reason why the wxGUI works fine without a system-wide Python.
That was done so that the system Python
On Tue, Feb 4, 2014 at 8:25 AM, Benjamin Ducke bendu...@fastmail.fm wrote:
But with the
latest Python developments, it will be a real challenge to
integrate GRASS 7 in the same way that we could integrate
GRASS 6 into a host application (i.e. without messing
around with any system settings).
On 04/02/14 15:09, Vaclav Petras wrote:
On Tue, Feb 4, 2014 at 8:25 AM, Benjamin Ducke bendu...@fastmail.fm
mailto:bendu...@fastmail.fm wrote:
But with the
latest Python developments, it will be a real challenge to
integrate GRASS 7 in the same way that we could integrate
On Tue, Feb 4, 2014 at 10:14 AM, Benjamin Ducke bendu...@fastmail.fmwrote:
Years ago, when the development of the wxGUI started to get more
integrated with that of GRASS itself, it was suggested by some
to completely separate the GUI development.I still think that
would be a good idea.
If
On 04/02/14 16:42, Vaclav Petras wrote:
On Tue, Feb 4, 2014 at 10:14 AM, Benjamin Ducke bendu...@fastmail.fm
mailto:bendu...@fastmail.fm wrote:
On 04/02/14 15:09, Vaclav Petras wrote:
On Tue, Feb 4, 2014 at 8:25 AM, Benjamin Ducke
bendu...@fastmail.fm
On Tue, Feb 4, 2014 at 11:29 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
Other projects such as gimp or libreoffice are AFAICT reasonably
bundled with Python, without a Python installer.
They aren't attempting to support Python scripts as stand-alone
programs
On Tue, Feb 4, 2014 at 10:08 PM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
...
We should use the embedded Python explicitly to avoid this problem. We
were here already. From a user's perspective, the easiest would be if
GRASS ignores any system-wide Python installation.
This view is
Glynn Clements wrote:
Markus Metz wrote:
Executing a script uses the registry associations for the script's
extension.
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
Markus Metz wrote:
No, there are different versions of Python 2.7, and not all work with
GRASS, see e.g. ticket 2015
Any version of Python 2.7 should be suitable for GRASS.
Not all versions of Python 2.7 are suitable for WinGRASS, see ticket #2150.
To the extent that I can make any
1 - 100 of 148 matches
Mail list logo
