[GRASS-dev] Handling of Python scripts on MS Windows

[Benjamin Ducke]

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 is hardly feasible for the majority of the users. Perhaps I don't
>> understand the suggestion, at least for Windows OS users (nad most
>> Linux/Mac newcomers).
> 
> It's not something users should need to concern themselves with.
> 
> Many packages require certain environment settings (which is why most
> modern Linux systems have e.g. /etc/profile.d or /etc/env.d, with each
> file belonging to a different package).
> 
> Most packages made up of command-line utilities don't require you to
> "start" the package before you can use the commands which comprise it.
> 
> It would be quite straightforward for a GRASS package to install an
> environment file which sets GISBASE and GISRC so that GRASS commands
> just work anywhere.
> 

I have been trying to wrap my head around this.
Please tell me if I still misunderstand something,
but this is what I think you are suggesting:

Instead of having to log into a GRASS session
explicitely, the GRASS environment gets configured
with the login (shell) and then the user can just run
e.g. "g.list" and it will just work.

How would users choose mapsets or create new ones in this
scenario? Wouldn't that require new user level software?

> Things get marginally more complex if you either need multiple
> versions installed concurrently, or multiple concurrent sessions.
> 
> The former is seldom supported, particularly for packages consisting
> of many distinct utilities (having python2 and python3 executables is
> one thing, versioning dozens or hundreds of distinct commands is
> another).
> 

Well, at this point I have several versions of GRASS 6.4 and
a version of GRASS 7 installed. I need them all, because they
run as testing versions or to provide processing functionality
for another "host" GIS.

How would I switch between them?

The same situation arises with different Java versions on the
same system. It is a very frequent situation and IMHO there
is no really good, convenient solution for this. Every Linux
distribution seems to use its own frontend for switching and
let's not even get started about Windows.

The alternatives here are to either manipulate PATH etc.
directly or to provide some more user-friendly software that
take care of this. I find neither ideal.

> The latter is fairly trivial to implement on Unix (just use $$ in the
> setting of GISRC), and could be implemented on Windows (which doesn't
> have the equivalent of ~/.profile etc) with fairly minor changes to
> lib/gis/env.c.
> 

But that would again require some user-friendly software, unless
people are supposed to start editing configuration files, right?

I understand the benefits of tighter system integration that (I think)
you are aiming for. It would make everything more seamless.
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; we would depend on
3rd party dependencies to work with GRASS. Surely, all of these issues
could be worked around, but are the potential benefits worth it?

Whatever the decision may be: Please make sure that it will always be
possible to bundle a completely independent distribution of GRASS
with 3rd party GIS. Otherwise, this project will no longer be able to
benefit from the growing user base that projects such as QGIS have
recently attracted.

Best,

Ben

-- 
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  benducke at fastmail.fm