g.extension: support alternative addon servers for MS-Windows users

[ecodiv]

Motivation

On MS-Windows, g.extension downloads precompiled addon ZIPs from a hardcoded URL (http://wingrass.fsv.cvut.cz). There is no way to point Windows users at a different server. The url= option is documented as not supported on Windows, and the WinGRASS host is baked into install_extension_win(). The listing URL is similarly hardcoded to https://grass.osgeo.org/addons/<branch>/. Consequence:

• Running an mirrow, good if the official one is not available or updated
• Hosting addons that aren't in the official repository (e.g. organisation-specific tools, forks, addons not yet upstreamed).

This PR adds two settings that redirect both listing and install to a custom server, plus a per-call url= for one-off ZIP installs. No new parser options are introduced, and the default behavior is unchanged. For Linux users, there should be no change at all.

Changes

New: get_addons_base_url() helper, which resolves the base URL of the addon server with the following precedence:

• ADDONS_BASE_URL set via g.gisenv set="ADDONS_BASE_URL=..." (persists across sessions, settable from the GUI's variables panel).
• GRASS_ADDONS_BASE_URL shell environment variable (useful for CI / one-off shell sessions).
  Built-in default http://wingrass.fsv.cvut.cz.

Guards against gs.gisenv() failing outside an active GRASS session.

install_extension_win() honors the resolver and url=

• The previously hardcoded "http://wingrass.fsv.cvut.cz/" base is replaced by get_addons_base_url().
• The function now accepts a url parameter for Window users. If url= is given, it must be a full ZIP URL ending in .zip. The zip file must reside on a server with pre-compiled add-ons with the same structure as the default server.
• Non-ZIP values for url= (e.g. GitHub repo URLs, base server URLs) are rejected with a error pointing the user at ADDONS_BASE_URL / GRASS_ADDONS_BASE_URL. This avoids platform-dependent reinterpretation of the same url= value.

What does not change

• No new parser options. The g.extension GUI/CLI surface is unchanged on every platform.
• Non-Windows code paths are untouched. Linux/macOS users see no behaviour change.
• The default still is for Windows installs is to point at wingrass.fsv.cvut.cz and grass.osgeo.org/addons/grass8/ respectively.

Server-side

A custom server is expected to mirror the official WinGRASS layout:

{base}/grass{MM}/addons/grass-{M.M.P}/
    modules.xml
    <addon>.zip
    <addon>.md5sum
    ...

I have an example at https://ecodiv.earth/share. This contains Python scripts only. These were created by pulling the grass-addon repository and using a custom script to create the zipped addon files.

Testing and AI

I used AI to help me write and test the proposed changes. I tested the script on Linux (Ubuntu 24.04) and Windows 11. On Linux, no changes in behavior or options. On Windows, I installed addons setting ADDONS_BASE_URL=https://ecodiv.earth/share and by using the url=.. pointing directly at the zip file.

[ecodiv]

You can test it using https://ecodiv.earth/share for 8.5.0 and 8.6.0dev

[echoix]

If it’s something that essential to have, why would it be limited to Windows? Couldn’t it work for other platforms (to set a base url), even if they are t using pre-compiled addons?

Is tweaking around with env vars how we want this to work? It’s easier to implement, like done here.

[echoix]

Is there a reason the executable flag was lost on this file? See the mode change 100755 -> 100644 on GitHub.

[ecodiv]

No, that is not an intentional change.

[ecodiv]

If it’s something that essential to have, why would it be limited to Windows? Couldn’t it work for other platforms (to set a base url), even if they are t using pre-compiled addons?

For Linux it is already possible to provide an alternative URL, so this adds an option that is already available for Linux (for Mac, I don't know).

Is tweaking around with env vars how we want this to work? It’s easier to implement, like done here.

That is a good question. I don't think it is ideal, it is just the only way I could think of that would not require changes in the current interface, and which I thought would still be easy enough for users.

[echoix]

If it’s something that essential to have, why would it be limited to Windows? Couldn’t it work for other platforms (to set a base url), even if they are t using pre-compiled addons?

For Linux it is already possible to provide an alternative URL, so this adds an option that is already available for Linux (for Mac, I don't know).

Can windows be adapted to do it too if that’s enough?

Is tweaking around with env vars how we want this to work? It’s easier to implement, like done here.

That is a good question. I don't think it is ideal, it is just the only way I could think of that would not require changes in the current interface, and which I thought would still be easy enough for users.
No problem

[ecodiv]

If it’s something that essential to have, why would it be limited to Windows? Couldn’t it work for other platforms (to set a base url), even if they are t using pre-compiled addons?

You're right that this isn't fundamentally Windows-only. The Linux flow also has a default location (grass.osgeo.org/addons/ for the listing, the OSGeo grass-addons GitHub repo for sources) that could be redirected the same way using the ADDONS_BASE_URL. The main reasons this PR focusses on Windows is that the binary-distribution layout makes the implementation trivial there. A Linux equivalent has to deal with multiple source mechanisms (git/zip/svn/local), which makes it (for me at least) more complicated.

Is tweaking around with env vars how we want this to work? It’s easier to implement, like done here.

I am not sure if it is the best way, but it was the best way I could think of that does not mess with the current interface and is still easy enough for users. It is still not as easily discoverable as I would like, so perhaps a dedicated parameter in g.extension itself would be better? It still should, in my opinion, expose the list of addons available on the selected server when using g.extension through the menu.

[ecodiv]

If it’s something that essential to have, why would it be limited to Windows? Couldn’t it work for other platforms (to set a base url), even if they are t using pre-compiled addons?

For Linux it is already possible to provide an alternative URL, so this adds an option that is already available for Linux (for Mac, I don't know).

Can windows be adapted to do it too if that’s enough?

Yes, and this PR already does that, it also extends url= to Windows (for full .zip URLs, matching Linux's existing ZIP-URL handling).

Beyond that, the reason I think the base-URL mechanism matters specifically for Windows is operational: addon provision depends on precompiled binaries built by essentially one maintainer (as far as I understand), and there have historically been extended periods where addons weren't being updated. An alternative-server option gives Windows users a real fallback in those situations, which is less of a concern on Linux, where builds are from source.

Is tweaking around with env vars how we want this to work? It’s easier to implement, like done here.

That is a good question. I don't think it is ideal, it is just the only way I could think of that would not require changes in the current interface, and which I thought would still be easy enough for users.
No problem

[hellik]

If it’s something that essential to have, why would it be limited to Windows? Couldn’t it work for other platforms (to set a base url), even if they are t using pre-compiled addons?

For Linux it is already possible to provide an alternative URL, so this adds an option that is already available for Linux (for Mac, I don't know).

Can windows be adapted to do it too if that’s enough?

Yes, and this PR already does that, it also extends url= to Windows (for full .zip URLs, matching Linux's existing ZIP-URL handling).

Beyond that, the reason I think the base-URL mechanism matters specifically for Windows is operational: addon provision depends on precompiled binaries built by essentially one maintainer (as far as I understand), and there have historically been extended periods where addons weren't being updated. An alternative-server option gives Windows users a real fallback in those situations, which is less of a concern on Linux, where builds are from source.

Is tweaking around with env vars how we want this to work? It’s easier to implement, like done here.

That is a good question. I don't think it is ideal, it is just the only way I could think of that would not require changes in the current interface, and which I thought would still be easy enough for users.
No problem

On Windows, a pre-compilation is needed for C/C++ addons.

For python addons, "only" a related windows batch file (.bat) is needed.

Would it make sense to integrate such a bat-file creation function e.g. e.g. in g.extension? then, at least, python addons would be available from source also for windows; only C addons would need a pre-compilation on a server.

[ecodiv]

@echoix @hellik, what about limiting the scope to making the url parameter work for Windows users for now? This allows Window-users to install individual addons from elsewhere (on the condition that these addons are properly packaged). This brings this functionality on par with what is already available for Linux and seems like a small non-intrusive change.

The idea of hellik would complement this. I still would like the option to set a different base-server (I agree it would be great to have this for Linux as well) but I can move that perhaps to an addon?

[hellik]

@echoix @hellik, what about limiting the scope to making the url parameter work for Windows users for now? This allows Window-users to install individual addons from elsewhere (on the condition that these addons are properly packaged). This brings this functionality on par with what is already available for Linux and seems like a small non-intrusive change.

The idea of hellik would complement this. I still would like the option to set a different base-server (I agree it would be great to have this for Linux as well) but I can move that perhaps to an addon?

Sure, go ahead with your approach!

For the mid term, we should look at additional options.