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 a
>> self-contained GUI application. There were even suggestions to remove
>> the command line interface completely from winGRASS because it
>> confuses users.
keep in mind windows and *nix are working as operating
systems sometimes in the same way and sometimes in a (quite) different way.
IMHO the discussion is not/should not be about feature parity etc.; it is
about how to handle/tackle as
software project these differences how operating systems do their job with
monolithic/non-monolithic applications, file extensions associations, global
system variables etc. etc.
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 also think that some of the debate comes from the question of whether
the wxGUI should have a special status or whether it should just be
treated as one of the hundreds of modules that GRASS offers.
I try to outline some scenarios with software using/depending on python in
the windows side ;-)
of the world which I effectively know in reality:
(a)
software A bundles/embeds python X.x.x
software B bundles/embeds python X.x.x
they can be installed in whatever order
(b)
software A bundles/embeds python X.x.x
software B bundles/embeds python Y.y.y
[snip]
(d)
software A installs system wide python X.x.x
or
software A installs system wide python X.x.y
AND
software B installs system wide python X.x.x
or
software B installs system wide python Y.y.y
...and a lot other variations are already out in the windows world ...
a system wide installation in windows defines the file extension
associations, global system variables, etc.;
additionally the applications need maybe the same site-packages or different
ones (and not always the same versions)
as a system wide installation defines the file extension associations,
global system variables, the installation order A then B or B then A may
break the installation of the other software and so on...
As has been mentioned often enough: there is a big difference between
types of software, between monolithic GUI applications and others.
And AFAIK, no one has suggested that the GRASS installer should just
install Python system-wide, but rather that a correct Python
installation would be left to the user, with possible help in the
installer (e.g. suggesting installation if it detects no installation at
all, clear documentation on different cases, etc).
I'm pretty sure, if we - the GRASS project - let potential users in the
windows world alone to tackle/handle all these challenges of different
/installations versions etc., we will lose these people ... and this would
be a really pity!!!
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 create a GRASS installer without Python, so that we
can test that scenario ? I don't have the Windows build toolchain set up
at the moment, but if it's more work for you than a few lines of code to
change and command to create a new package, then I'll try to find the
time to do that.
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
