>>> 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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev