[GRASS-dev] [release planning] GRASS GIS 7.8.6

[Helmut Kudrnovsky]

>>> I don't want to block the release, but in my experience g.extension not working correctly is something that leads to a very frustrating user
>>> experience on Windows, so would be great if this could be solved before.

>>Problems that are caused by the addons themselves should obviously not
>>be considered blockers of a release, so we should focus on the issues
>>directly caused by g.extension.
>>
>>IIUC, they all are caused because the addon is either a toolset with
>>several modules, or there are library files in the directory or in
>>subdirectories (e.g. i.segment.hierarchical and r.estimap.recreation).
>>The relevant zip file does contain all necessary files for running the
>>addon, so it is g.extension that is looking for info that it shouldn't
>>look for.

>OK, here is a PR to address this issue on Windows:
>https://github.com/OSGeo/grass/pull/1565

I've tested this PR; it works in winGRASS; PR can be merged.

and see https://github.com/OSGeo/grass-addons/issues/525#issuecomment-835489716
for an example of looking for a needle in a haystack ... ;-D

a single character which doesn't match the file encoding is able to crash g.extension in winGRASS, though not in linux.

there is another PR for more lazy imports in some addons; also this PR should be merged.

to sum up with these PRs, g.extension addons experience in winGRASS should be improved now. :-)

then ready for an RC.

best
helli