I was just checking, and the latest update of the GRASS GIS addons is from 2024-09-30. Is this the normal frequency at which this is updated, or is something broken? @martinl
Hi Paulo, I don’t think there has been a development version of GRASS for Windows since September 30th either. See https://wingrass.fsv.cvut.cz/grass85/.
On Fri, Nov 15, 2024 at 2:04 PM Paulo van Breugel via OSGeo Discourse <noreply@discourse.osgeo.org> wrote:
ecodiv
November 15I was just checking, and the latest update of the GRASS GIS addons is from 2024-09-30. Is this the normal frequency at which this is updated, or is something broken? @martinl
Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here.
Yes, I saw that too. I wish there was an easier, additional way to share addons for Windows users, if only for Python addons. Anybody experience with that?
Hi Paulo. I’m struggling with the same issue. For Python addons, a Window’s user could just download the addons repository from GitHub and run the addon as a Python script.
On Sat, Nov 16, 2024 at 12:39 AM Paulo van Breugel via OSGeo Discourse <noreply@discourse.osgeo.org> wrote:
ecodiv
November 16Yes, I saw that too. I wish there was an easier, additional way to share addons for Windows users, if only for Python addons. Anybody experience with that?
Visit Topic or reply to this email to respond.
To unsubscribe from these emails, click here.
Hi, the g.extension module does offer the option to provide an alternative ULR to an addon repository. However, this does not work for GRASS GIS on Windows.
I do understand that on Windows, addons cannot be compiled. But, when addons are packaged like on http://wingrass.fsv.cvut.cz/, they can be installed using g.extension, also when available on other locations (URL or local folder).
I tested this by replacing in the g.extension code the http://wingrass.fsv.cvut.cz/ with a URL or path to a local folder with addons packaged in a zip file as on http://wingrass.fsv.cvut.cz/. After doing so, I could install the addon from that URL or folder without problem.
Based on this, wouldn’t it be possible to allow users to provide an alternative URL, with the clear warning in the help file about the need to have the addons packaged appropriately? This would make it easier to share addons with users without having to depend on the official repository (which I have to do right now, being in the middle of a course).
An alternative or temporary solution could be to create an addon which takes the parts from g.extension needed to install zipped addon packages on Windows?
Hello,
Just adding to this, I vaguely remember some earlier comments or discussion on installing Python-based GRASS add-ons as Python packages, i.e., via pip. The itzi add-on is the main (only?) example that I can think of that does this.
In terms of a possible justification, using the GitHub API, I summarized what languages are used in the GRASS add-ons directory based on (a) number of files; (b) total size (in bytes); and most relevant, (c) the number of add-ons that use a particular language.
Almost 70% of add-ons use Python and (not shown in the plots) most of these exclusively use either Python or C. Only a handful of add-ons like r.futures use both.
Not really sure what the implications would be (particularly in terms of testing). Some positives would be that Python dependency management could leveraged, so that add-ons that require pandas, scikit-learn, numba, etc., could be managed without the user needing to manually install the correct versions. I could imagine once GRASS is available via conda, installing add-ons via pip/conda could be a nice mechanism.
I created a feature request [Feat] g.extension: enable installation of (python) addons locally on Windows · Issue #4745 · OSGeo/grass · GitHub
I’ve already imagined something similar. Like abusing the wheel format, like other types of environments use, to make binaries (from other languages) available. I didn’t understand completely yet, but there might be a python way to be able to find and load plugins from a namespace even if installed from a different published package. Maybe it is setuptools-specific, as that’s where I’ve read about it.
Either way, it would need to be thought es about and some work would be needed anyways.
Dear Paulo,
pá 15. 11. 2024 v 20:04 odesílatel Paulo van Breugel via OSGeo Discourse <noreply@discourse.osgeo.org> napsal:
| ecodiv
November 15 |
- | - |
I was just checking, and the latest update of the GRASS GIS addons is from 2024-09-30. Is this the normal frequency at which this is updated, or is something broken? @martinl
you are right. I have fixed that on the server side. Binaries should be updated on a daily basis [1]. WinGRASS server is still maintained by a collection of Bash/Bat scripts which were developed many years ago as a temporary solution [2]. It would be nice to replace this solution by something more reliable and maintainable (eg. produce Addons binaries by GitHub workflow or so). I will be happy to shut down wingrass.fsv.cvut.cz then.
Best regards, Martin
[1] https://wingrass.fsv.cvut.cz/grass84/addons/grass-8.4.0/logs/
[2] https://github.com/landam/wingrass-maintenance-scripts
Fantastic, thanks!
Can the addons be updated/generated separately from GRASS GIS itself (I see one script in the addons folder)? And do this need to be run from Windows?
What do you think of the idea to make it possible for the user to use the url option (or specific url for windows) in g.extension to point at an alternative repository, or addon (see [Feat] g.extension: enable installation of (python) addons locally on Windows · Issue #4745 · OSGeo/grass · GitHub). Technically, it seems simple to do, but I don’t know if there are any disadvantages (I guess, otherwise, the option would be there already)?
Hi Paulo,
Can the addons be updated/generated separately from GRASS GIS itself (I see one script in the addons folder)? And do this need to be run from Windows?
Regarding addons written in C, you have to compile them on Windows. Addons written in Python are another story.
What do you think of the idea to make it possible for the user to use the url option (or specific url for windows) in g.extension to point at an alternative repository, or addon (see [Feat] g.extension: enable installation of (python) addons locally on Windows · Issue #4745 · OSGeo/grass · GitHub). Technically, it seems simple to do, but I don’t know if there are any disadvantages (I guess, otherwise, the option would be there already)?
As I mentioned we could produce binaries for Windows using GitHub CI as downloadable artifacts. This can one of the possible solutions. There is already a PR draft [1]. Unfortunately I don’t have time to work on it right now. I hope someone from the community may continue in this effort.
Martin
Hi @martinl, I see that one of the addons, r.edm.eval, is not updated on addon repository for Windows because of the dependency on Panda’s [1]. Would it be possible to include/install Pandas on the server, so Python addons depending on Pandas are getting built?
[1] (https://wingrass.fsv.cvut.cz/grass84/addons/grass-8.4.0/logs/r.edm.eval.log)
Hi @ecodiv. The issue is that pandas should be imported through lazy import in r.edm.eval. I have created a PR that should fix that: r.edm.eval: fix lazy import of pandas by pesekon2 · Pull Request #1257 · OSGeo/grass-addons · GitHub
HI @pesekon2, super, thanks!
Hi,
so 7. 12. 2024 v 16:07 odesílatel Ondřej Pešek via OSGeo Discourse <noreply@discourse.osgeo.org> napsal:
| pesekon2
December 7 |
- | - |
Hi @ecodiv. The issue is that
pandasshould be imported through lazy import inr.edm.eval. I have created a PR that should fix that: r.edm.eval: fix lazy import of pandas by pesekon2 · Pull Request #1257 · OSGeo/grass-addons · GitHub
right, lazy import is prefered solution. Thanks for creating the PR and solving this issue.
Martin