[Feat] Create grassdata automatically on the first GUI startup

[wenzeslaus]

When GRASS GIS first starts, many or even most users, especially beginners want to just create a grassdata directory in the default path for their platform. GRASS should just do that automatically.

Details

After starting GRASS GIS with GUI, the GUI now searches for existing grassdata (e.g., dac6d4a and #644 with #664). If nothing is found, GRASS GIS (GUI) should automatically create directory named grassdata as a subdirectory of a platfrom-dependent directory. This platfrom-dependent directory would be:

• $HOME (os.path.expanduser('~')) on Linux and the like,
• User's Documents on Windows (see dac6d4a for code trying to identify that dir),
• One of the above on macOS - macOS users, please share your ideas.

Fallback

The directory should be created and tested whether it is writable (well, that's probably the same thing).

If that fails, it should use a temporary directory (/tmp/... etc.) as a fallback. This is actually the case for a free account on rollApp which we want to have in the Try GRASS GIS online section on the new website.

As for the temporary directory fallback, given the processes of GUI and/or startup and grass.py, using tempfile.gettempdir()/grassdata_{user_name} (e.g., /tmp/grassdata_smith) - similarly to what create_tmp() in lib/init/grass.py does - seems like the best shot. The fact that it would not be deleted (because the GUI process won't delete it and the grass.py does not know about it) combined with the fixed name is actually (possibly?) a nice feature (although irrelevant to rollApp): the user has a chance to go back to the data before (before the machine is turned off).

If even that fails, GRASS should not fail, but simply let the user make that choice which is the current behavior.

Context

The creation of the grassdata directory on Windows in Documents is already happening during installation. This should bring this behavior to all platforms and it should make it independent on the installer.

This is also a necessary step if we decide to provide user with some basic data to start with (the provided location will need to be placed somewhere).

[nilason]

One of the above on macOS - macOS users, please share your ideas.

I'd prefer os.path.expanduser('~') ($HOME) for mac. As the grassdata directory is not meant to poke around in manually, ~/Documents/ should be avoided.

[cmbarton]

Another option would be in ~/Library/GRASS. This is where extensions now go by default. It is accessible but not a place where people might 'poke around' by accident. The more 'normal' Apple path would be ~/Library/Application Support/GRASS. But that folder does not seem to be recognized by GRASS anymore.

[nilason]

Another option would be in ~/Library/GRASS. This is where extensions now go by default. It is accessible but not a place where people might 'poke around' by accident. The more 'normal' Apple path would be ~/Library/Application Support/GRASS. But that folder does not seem to be recognized by GRASS anymore.

Installing as GRASS.app bundle will put stuff in ~/Library/GRASS (I guess), but as CLI it goes to ~/.grass7. I'm hesitant hiding it too well as it may grow in size (in particual a potential problem on SSD start-up drives).

[wenzeslaus]

The more 'normal' Apple path would be ~/Library/Application Support/GRASS. But that folder does not seem to be recognized by GRASS anymore.

@cmbarton What do you mean by not recognized anymore? Recognized as what? When?

[cmbarton]

It’s doesn’t seem to be in the path so I can’t launch modules in it from the command line. Michael Barton ...Sent from my iPad

…

On Jun 9, 2020, at 2:58 PM, Vaclav Petras ***@***.***> wrote:  The more 'normal' Apple path would be ~/Library/Application Support/GRASS. But that folder does not seem to be recognized by GRASS anymore. @cmbarton What do you mean by not recognized anymore? Recognized as what? When? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[wenzeslaus]

It’s doesn’t seem to be in the path so I can’t launch modules in it from the command line.

If you think that's something which should work, please open an new issue for it.

[nilason]

Re: ~/Library/Application Support/GRASS
I haven't looked into this at any depth, but there is a note in macosx/app/build_gui_user_menu.sh regarding problem with spaces in path for addons. I don't know if this is still the case or if there could be a workaround/solution. That would ideally be the place for addons etc., but not for grassdata.

[cmbarton]

It’s doesn’t seem to be in the path so I can’t launch modules in it from the command line.

If you think that's something which should work, please open an new issue for it.

I'm not sure if it should work or not. Apparently, there have been shifts of where these support files live. Something in GRASS is/was creating these folders (there are also ones in System/Library/GRASS and System/Library/Application Support/GRASS). Currently, it seems that ~/Library/GRASS is what is being created and pathed.

That said, it would probably be a good idea to standardize and stick with it for the future.