[GRASS-dev] [GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Markus Metz]

On Wed, Apr 9, 2014 at 9:21 AM, Moritz Lennert
<mlennert at club.worldonline.be> wrote:
> On 09/04/14 03:17, Vaclav Petras wrote:
>>
>>
>> On Tue, Apr 8, 2014 at 9:09 PM, Glynn Clements <glynn at gclements.plus.com
>> <mailto:glynn at gclements.plus.com>> wrote:
>>
>>     If there's no Python installed, the installer can install it. If
>>     Python is installed and the version is compatible, the installer can
>>     install any required packages. Otherwise, it can at least inform the
>>     user of the situation and enumerate the options.
>>
>>
>> This is a good point, the documentation must be in the installer, not a
>> separate file. For example Git installer for MS Windows list three
>> options how to install git and other command line tools with an
>> explanation. The problem is that only part of the users will read it and
>> only part of them will understand all the consequences (I mean, I was
>> not sure when I saw installing Git installation for the first time).
>
>
> I think part of this discussion boils down to the very old debate about how
> far we should go in taking the user's hand. Do we really want to compete
> with programs that "just do the work for you", thus having to think of every
> possible problem they might face, or do we decide that even though we can
> lower the entrance hurdle a bit, GRASS does demand some more involvement
> from the user than other software.

IMHO, that should be restricted to the actual usage of GRASS, not the
installation. IMHO, "just do the work for you" is fine during
installation, like e.g. apt-get install grass or yum install grass. On
Linux, these commands just do the work for you and take care of any
dependencies. One Windows problem is that there is no package manager
who takes the user's hand which is the reason for these large
standalone applications on MS Windows.

I do not suggest to change the behaviour of modules. All I suggest is
that both in the GUI and on the command line, be it msys or cmd.exe,
all GRASS commands work, even if the system-wide Python installation
is incompatible or missing.

>
> Personally, I am a bit afraid that by going down the first route we
> concentrate much developer time that could be spent on other (IMHO more
> useful) things and we also risk to make GRASS less efficient for those that
> have taken the time to pass the hurdle.

Changing the installer to take care of a system-wide Python
installation that also resolves conflicts is probably far more work
than to use the existing mechanism of GRASS6.

>
> In other words, there are some types of users (those that don't read
> anything provided by the developers) for whom I am sometimes tempted to just
> say "RTFM" instead of trying to find ways to make it possible for them to
> still use GRASS.

I think this is about installing GRASS, not using GRASS.

Markus M