On 29/07/13 21:15, Moritz Lennert wrote:
On 29/07/13 18:44, Moritz Lennert wrote:
- It thus seems to me that the safest path is the one checking during
installation whether a Python 2.7 installation is know in the registry,
and if that is not the case, to create a registry entry that points to
On 29/07/13 18:44, Moritz Lennert wrote:
- It thus seems to me that the safest path is the one checking during
installation whether a Python 2.7 installation is know in the registry,
and if that is not the case, to create a registry entry that points to the
GRASS installation
Just for the reco
On Mon, July 29, 2013 16:13, Moritz Lennert wrote:
> On 26/07/13 20:18, Glynn Clements wrote:
>> Moritz Lennert wrote:
>>> Would it be a possible option to implement only a) and document the
fact
>>> that the user has to take care of creating a working Python
>>> installation
>>> herself if they wa
On 27/07/13 20:08, Glynn Clements wrote:
Helmut Kudrnovsky wrote:
Python Launcher for Windows is a interesting concept for switching between
python versions or for pointing to a specific python interpreter.
shebang + py.ini seems to work (see tests in the ticket).
IIUC, by this concept a Win
On 26/07/13 20:18, Glynn Clements wrote:
Moritz Lennert wrote:
Would it be a possible option to implement only a) and document the fact
that the user has to take care of creating a working Python installation
herself if they want b) ?
In order to be able to "execute" scripts via the command
Helmut Kudrnovsky wrote:
> Python Launcher for Windows is a interesting concept for switching between
> python versions or for pointing to a specific python interpreter.
>
> shebang + py.ini seems to work (see tests in the ticket).
>
> IIUC, by this concept a WinGrass-python script would have t
>
>Note that Python 3 includes a launcher utility for Windows:
>
> http://docs.python.org/3/using/windows.html#launcher
>
>The idea is that the .py extension can be associated with the
>launcher, which can be configured to use a specific version of Python
>in a specific context.
>
>I don't kn
>
>
>Note that Python 3 includes a launcher utility for Windows:
>
> http://docs.python.org/3/using/windows.html#launcher
>
>The idea is that the .py extension can be associated with the
>launcher, which can be configured to use a specific version of Python
>in a specific context.
>
>I don't
Moritz Lennert wrote:
> Would it be a possible option to implement only a) and document the fact
> that the user has to take care of creating a working Python installation
> herself if they want b) ?
In order to be able to "execute" scripts via the command prompt,
batch files, system(), subpro
Moritz Lennert wrote:
> - Another issue is how to make it possible in windows to launch modules
> that are Python scripts by simply calling their module name, without .py
> extension. At this stage, in a fresh installation of GRASS7 on WinXP, I
> can launch (and successfully execute) python sc
On 26/07/13 17:10, Helmut Kudrnovsky wrote:
IMHO the question is/will be: is there a robust mechanism for calling a
script from a script and making>addons easily callable by the embedded
python interpreter working on WinXp, WinVista, Win7 and Win8?
if this is working robustely, I think we are
>IMHO the question is/will be: is there a robust mechanism for calling a
script from a script and making >addons easily callable by the embedded
python interpreter working on WinXp, WinVista, Win7 and Win8?
>
>if this is working robustely, I think we are on a good way for a nice
(python) usable Win
[...]
>Yes, so this should be reformulated as "keep the current option of
>bundling an embedded python".
yes
>However, again within the limits of my understanding, aren't the issues of
>
>- calling a script from a script
>
>and
>
>- making addons easily callable
>
>linked to the question of sy
On 26/07/13 11:40, Helmut Kudrnovsky wrote:
hi,
On 26/07/13 00:04, Helmut Kudrnovsky wrote:
[...]
Would it be a possible option to implement only a)
there is already a bundled/embedded python in standalone WinGRASS6/7 and
OSGeo4w-WinGRASS6/7.
Yes, so this should be reformulated as "keep th
hi,
On 26/07/13 00:04, Helmut Kudrnovsky wrote:
[...]
> Would it be a possible option to implement only a)
there is already a bundled/embedded python in standalone WinGRASS6/7 and
OSGeo4w-WinGRASS6/7.
some more issues related to WinGRASS and python are mentioned also in
http://trac.osgeo.org
On 26/07/13 00:04, Helmut Kudrnovsky wrote:
- One of the issues is whether and how to install Python. As Python is
needed both for the wxgui and for scripting, and scripting is something
for which you cannot assume an embedded Python interpreter, the
preferred solution would be to install Python
>e.g. here in my Win7-box ArcGIS10.1 does a system wide registry entry for
python 2.7 (see above) and >therefore the standalone-WinGRASS 7-installer
with an embedded python 2.7 doesn't start because of a >mismatch of some
lib/etc.
small correction: standalone-WinGRASS 7-installer -> standalone-Wi
hi Moritz,
>Is this a correct summary of the issues ? Anything I'm missing ?
thanks for the summary, some additions below.
>
>On 12/07/13 23:50, Helmut Kudrnovsky wrote:
>>> - the python issues in wingrass (notably how to correctly install python
>>> to be able to launch scripts and addons)
>>
>
On 12/07/13 23:50, Helmut Kudrnovsky wrote:
- the python issues in wingrass (notably how to correctly install python
to be able to launch scripts and addons)
IMHO it's one of the showstoppers in winGRASS7
not only correctly installing python, but also what is the
structure/approach in C:\Users
19 matches
Mail list logo
