Re: [GRASS-dev] GSoC 2021 Project - Sunveer Singh
On Wed, Feb 3, 2021 at 8:15 AM Sunveer Singh wrote: > > I am Sunveer Singh, I graduated from high school in 2021 and will start my > undergraduate studies in Fall 2021 and have been accepted into a university > so it makes me eligible to participate in GSoC this year. > Congratulations and welcome back! > I found this following project and I would be happy to work on it this > year: > https://trac.osgeo.org/grass/wiki/GSoC/2017#Toolsforgeneratingunittestsfromexamplesinthemanual > > This is indeed related to what you did before, so it is a hopeful choice. However, there is an additional challenge now and that is a poor integration of the testing framework with current technologies namely pytest and GitHub Actions. The choices I made when designing and implementing the framework are not as advantageous as they seemed in 2014 (there was no 6 hours of runtime from GitHub for free on every commit, NumPy and GDAL switched to pytest in 2018, ...). You can see the idea for this year here: https://trac.osgeo.org/grass/wiki/GSoC/2021#IntegratetestingframeworkwithGitHubActions This is not to say that you can't propose/do the documentation-to-test idea, but you will need to take into account the current state and needs as well. > I see that this project was skipped after 2017 and no one had worked on > it, so I would like to work on this as it is totally of my interest and my > skills. Will the mentors written on the page will be the same i.e Vaclav > Petras and Soeren Gebbert? > I'm making this a call for mentors. I can comment on the integration into the current code and the updates needed, but I would like some else to bring ideas on how this would be useful from a power user perspective and/or, from a development perspective, if documentation-to-test idea is where our priorities are. For your proposal, it would be good to have a clear idea on what it is you are going to implement and how. You don't have to resolve that yourself. You can discuss the ideas on the mailing list which would be also a way to get more people interested in this idea. As you probably know, besides preparing your proposal, you will need to do some tasks to show you current coding skills. There are a couple of things you can work on and obviously there is no upper limit. 1) Fixing broken tests would be really good because it will take you through the current interface of tests which can inform your proposal. 2) You can always add new tests. Testing Python functions in addition to modules would be relevant to the task at hand. 3) Taking code from abandoned PR #704, fixing it and submitting a new PR is low hanging fruit, but interesting enough. https://github.com/OSGeo/grass/pull/704 Best, Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8
On Fri, Feb 5, 2021 at 3:09 PM Markus Metz wrote: > > I suggest removing the github test for Centos 7 and using Centos 8 > instead, if possible. > I have no problem with that. The tests are at this point whatever is practical to test. For Ubuntu, we so far followed whatever are the VMs on GitHub Actions and, I think, we removed 16.04 where there was an issue with some packages or something (the commit message mentions just 16 being outdated [1]). The policy for the tests is, so far, whatever we want to test for, not what we happen to support in one way or the other. From a contributor perspective, this translates to whatever compatibility I want to be checked, I add that to the GitHub Actions. [1] https://github.com/OSGeo/grass/commit/e12718e7bf4f2597a59e31514d7c87aec982911b ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8
On Fri, Feb 5, 2021 at 9:09 PM Markus Metz wrote: > On Fri, Feb 5, 2021 at 8:29 PM Markus Metz > wrote: > > On Thu, Feb 4, 2021 at 5:35 AM Vaclav Petras wrote: > > > > > Similarly to the GDAL and PROJ issue where I don't think it is necessary > > > to have GRASS C89/C++98 compliant when you need C++11 for GDAL anyway. > > > > The C code of GRASS master is currently compatible with a lot of GDAL and > > PROJ versions, also GDAL 1.xand PROJ 4.8.x which most likely do not require > > C++11 or C99. If we want to keep this compatibility, we need to stick with > > the lower C and C++ standards. Related to the question which currently > > supported production environments we want to support. > > My PR 1283 [0] is related to this discussion, it does not work with stock > Centos 7, and the github test with Centos 7 is thus failing. Of course it is > still possible to use GRASS master on Centos 7 as long as there is a more > recent PROJ version (as in my setup). Amusingly I am also the EPEL/Centos maintainer of PROJ (https://src.fedoraproject.org/rpms/proj) but I believe that per policy I cannot push a major version bump to the Centos repo. But I don't really know and didn't study that too much. However, there is "Fedora ELN" which provides PROJ 7 but I am not sure what ELN is for. > I suggest removing the github test for Centos 7 and using Centos 8 instead, > if possible. Makes sense to me. > This does not mean that GRASS master is no longer running on Centos 7, or > similar old, but still supported OS's. This means that people who want to use > GRASS master with those OS's need to update certain GRASS dependencies > themselves. As long as those OS's support the minimum C and C++ standards > required by GRASS. +1 > Markus M > > [0] https://github.com/OSGeo/grass/pull/1283 markusN ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8
On Fri, Feb 5, 2021 at 8:29 PM Markus Metz wrote: > > > On Thu, Feb 4, 2021 at 5:35 AM Vaclav Petras wrote: > > > Similarly to the GDAL and PROJ issue where I don't think it is necessary to have GRASS C89/C++98 compliant when you need C++11 for GDAL anyway. > > The C code of GRASS master is currently compatible with a lot of GDAL and PROJ versions, also GDAL 1.xand PROJ 4.8.x which most likely do not require C++11 or C99. If we want to keep this compatibility, we need to stick with the lower C and C++ standards. Related to the question which currently supported production environments we want to support. My PR 1283 [0] is related to this discussion, it does not work with stock Centos 7, and the github test with Centos 7 is thus failing. Of course it is still possible to use GRASS master on Centos 7 as long as there is a more recent PROJ version (as in my setup). I suggest removing the github test for Centos 7 and using Centos 8 instead, if possible. This does not mean that GRASS master is no longer running on Centos 7, or similar old, but still supported OS's. This means that people who want to use GRASS master with those OS's need to update certain GRASS dependencies themselves. As long as those OS's support the minimum C and C++ standards required by GRASS. Markus M [0] https://github.com/OSGeo/grass/pull/1283 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Use # %, not #% in Python scripts
On Fri, Feb 5, 2021 at 5:14 AM Vaclav Petras wrote: > > Dear all, > > I prepared a change to g.parser and related code which changes the option definitions in scripts (aka script header) from: > > #%option > #% key > #%end > > to: > > # %option > # % key > # %end > > The reason is PEP8 compliance where "each line of a block comment starts with a # and a single space" [2]. > > The PR is removing all use of #% from the code, but it is still allowed, so addons and existing user code should continue to work. However, I don't see a need to depreciate support of #% at this point. > > This change moves us a little closer to PEP8 or Flake8 compliance. We can now enable the check in CI once the normal comments are fixed. (The file header comment is ignored, so no need to change that, but we can consider that anyway.) > > The vision is that users and contributors can write scripts which just work with more or less default Flake8 settings. This is a big step towards that because it removes tens of warnings for a standard module. These warnings for #% are a real annoyance, distracting from meaningful warnings. The suggested changes will make code quality checking and code improvement much easier. +1 Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8
On Thu, Feb 4, 2021 at 5:35 AM Vaclav Petras wrote: > Similarly to the GDAL and PROJ issue where I don't think it is necessary to have GRASS C89/C++98 compliant when you need C++11 for GDAL anyway. The C code of GRASS master is currently compatible with a lot of GDAL and PROJ versions, also GDAL 1.xand PROJ 4.8.x which most likely do not require C++11 or C99. If we want to keep this compatibility, we need to stick with the lower C and C++ standards. Related to the question which currently supported production environments we want to support. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Support GRASS GIS financially !
Dear all, We just received our very first sponsorship contribution of 2021 (thank you !) and we want to take this occasion to thank all those who sponsored us last year and remind you that the GRASS GIS project needs financial support in order to: - organize very valuable face-to-face meetings and sprints gathering developers and the wider community for a few days to concentrate on improving GRASS GIS - fund specific fixes or enhancements (this year the use of micro-budgets for such fixes is planned) - maintain our website - produce marketing material to spread the word You can see the list of past individual and corporate sponsors here: https://grasswiki.osgeo.org/wiki/Sponsors As you can see, no amount is too small: if all GRASS GIS users give just a small amount regularly, we will already have a sizeable budget to work with ! And I challenge you to find software that does all that GRASS GIS does for 5€/$ or 10 €/$ a year ;-) So, just go to https://grass.osgeo.org/contribute/sponsoring/ and help us make GRASS GIS better. If you want to see more details about how we use the money, note that the project budgets are public. For 2021 see https://grasswiki.osgeo.org/wiki/GRASS_GIS_Budget_2021. The GRASS GIS Project Steering Committee ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
