[GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

Wed Feb 10 04:16:11 PST 2021

 First of all, thank you all for your feedback and contribution to this topic. I think it is really important to clearly state the "rules of the game" for going forward.

Let me try summarise the need for this:

- There is no official, clear statement on C standard support for the project
- The implicit understanding of adherence to C89/C90 is no longer correct, as the code base contains C99 additions.
- Newer C standards (C99 and later) may provide better cross platform support and safer code.
- G7 has seen the transition from Python 2 to 3 [1]. Going forward, a final (official and unambiguous) dot for Python 2 need to be put with a statement of minimum support of a Python 3 version.
- Only a small part of the code base is consists of C++ [2]. To the best of my knowledge there in not even an implicit understanding/agreement on standard support.
- Platform and compiler support of the standards has improved notably in recent years.

What are the consequences/benefits:
- Contributors will know what is allowed or not.
- It is possible to "guard" against using too new language features (esp. for C and C++) or using too old features (esp. Python). In this respect we're setting a max support for C/C++, and min support for Python.
- Existing C and C++ code compiles also with C17 and C++17, and will **not** have to be changed as a consequence of standard support policy.
- Old Python code may be discarded.

I think Anna's suggestion to look at how GDAL is handling the question on Python with a long term strategy is a good way to go, but we need to consider GRASS has a different release schedule.
(I personally believe 3.6 is too conservative for G8. When the moment comes for G8 release, I suspect 3.6 is close to if not past end-of-life.)

It would be most favourable for all contributors and the project if the community could come to an agreement on this topic. I see no reason to postpone a decision on this much longer.

The final word on this need to be that of the PSC's. Whether through simple vote or a RFC. However, a sounding of the opinion of the dev-community on this matter is of equal importance and can be of help for the PSC.

May I propose setting the programming language standard support for the GRASS GIS 8:

PROPOSAL:
=========

- Python 3.6

- C11 with core (mandatory) features
 (optional features may be used if availability is tested with macro,
 and if not supported, alternative fallback code must be provided [3])

- C++11

Best,
Nicklas

[1] That must have been a h*** of a job! Respect!
[2] 4 core and 3 add-on modules.
[3] See <https://en.wikipedia.org/wiki/C11_(C_standard_revision)>
 for short summary of C11 and list of its optional features.

     On Tuesday, 9 February 2021, 22:29:49 CET, Markus Metz <markus.metz.giswork at gmail.com> wrote:  

 Just for clarification,
C code written for an older C standard works fine with newer C standards.

This is different with Python: code written for a previous Python version might no longer work with a newer Python version. 
Increasing the C standard for existing GRASS C code is safe, it will still compile and work.

Increasing the Python version is not safe because existing GRASS Python code might not be compatible with newer Python versions, thus the need for a minimum required Python version.
Markus M

On Sun, Feb 7, 2021 at 10:36 PM Markus Metz <markus.metz.giswork at gmail.com> wrote:
>
>
>
> On Sun, Feb 7, 2021 at 4:07 PM Moritz Lennert <mlennert at club.worldonline.be> wrote:
> >
> >
> >
> > Am 7. Februar 2021 05:01:38 MEZ schrieb "Anna Petrášová" <kratochanna at gmail.com>:
> > >On Wed, Feb 3, 2021 at 2:47 PM Anna Petrášová <kratochanna at gmail.com> wrote:
> > >
> > >>
> > >>
> > >> On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson <n_larsson at yahoo.com>
> > >> wrote:
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová <
> > >>> kratochanna at gmail.com> wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Thu, Jan 28, 2021 at 4:28 AM Nicklas Larsson via grass-dev <
> > >>> grass-dev at lists.osgeo.org> wrote:
> > >>> > Dear Devs!
> > >>> >
> > >>> > As a relatively new member of the GRASS GIS dev community, I have had
> > >>> to search for information on mailing lists, old trac comments etc.
> > >>> regarding coding practice and in particular minimum programming language
> > >>> standard support. Ending up in not entirely conclusive understanding. Up
> > >>> until now, I have been mostly involved in Python development and I’m still
> > >>> not absolutely certain, although I assume 3.5 is minimum version. And I’m
> > >>> not alone, see e.g. [1].
> > >>> >
> > >>> > Now, I’ve encountered a similar dilemma with C standard support,
> > >>> attempting to address compiler warnings [2], in particular with the PR
> > >>> #1256 [3].
> > >>> >
> > >>> > I would be great if there were a (one) place where the min support of
> > >>> Python version, C (C89, C99, C11, C17…) and C++ (C++03, C++11, C++14 …)
> > >>> standard is stated -- loud and clear. Obviously, there has to be a
> > >>> consensus in the community on these matters for that to happen. Such a
> > >>> statement will also have to be revised now and then. (A related question is
> > >>> also whether or not to support 32 bit, which I know have been raised
> > >>> recently).
> > >>> >
> > >>> > I’d appreciate your opinion is on this issue!
> > >>> > Let me put up a a suggestion for min. req. for coming GRASS GIS 8 as a
> > >>> starting point of discussion:
> > >>> > - Python 3.7
> > >>> > - C11
> > >>> > - C++11
> > >>> >
> > >>> >
> > >>> > Best regards,
> > >>> > Nicklas
> > >>> >
> > >>>
> > >>> Regarding Python, not sure if we shouldn't set 3.6 as minimum for G8, it
> > >>> is still used e.g. in Ubuntu 18. Any reason to set 3.7 as minimum, some
> > >>> specific features we would want to use?
> > >>>
> > >>> Anna
> > >>>
> > >>> >
> > >>> >
> > >>> > [1] https://github.com/OSGeo/grass/issues/1241
> > >>> > [2] https://github.com/OSGeo/grass/issues/1247
> > >>> > [3] https://github.com/OSGeo/grass/pull/1256
> > >>> >
> > >>> > _______________________________________________
> > >>> > grass-dev mailing list
> > >>> > grass-dev at lists.osgeo.org
> > >>> > https://lists.osgeo.org/mailman/listinfo/grass-dev
> > >>> >
> > >>> >
> > >>>
> > >>>
> > >>>
> > >>> Well, I don’t have a very strong opinion regarding 3.7, but personally
> > >>> I’d say 3.6 is an absolute minimum. I presume, for example, most of us
> > >>> would prefer to use f-strings for string formatting.
> > >>>
> > >>
> > >> yes, f-strings are nice although they have limitations for using with
> > >> translatable strings (Vashek can expand on that)
> > >>
> > >>>
> > >>>
> > >>> On the other hand, 3.6 will reach end-of-support at the end of this year
> > >>> right after its 5th birthday party and the support for data classes in 3.7
> > >>> may potentially offer intriguing applications in G8.
> > >>>
> > >>
> > >> I noticed the data classes as well. Given 3.6 is reaching end-of-support
> > >> soon, I agree with 3.7 for G8. I assume grass would be compatible with 3.6
> > >> for a while anyway.
> > >>
> > >>
> > >>> Ubuntu 18 has Python 3.6 and Debian 9 has Python 3.5! What will make the
> > >>> lowest common denominator? Debian 10 and Ubuntu 20 actually supports Python
> > >>> 3.7 and 3.8 respectively. Forgive me if I’m ignorant, but isn’t it possible
> > >>> to upgrade Python version on Ubuntu? Or is it just a pain with package
> > >>> dependencies? Relying on default Python has never/rarely been a luxury for
> > >>> other platforms.
> > >>>
> > >>> That being said, I think the most important part of this is that the
> > >>> community make a clear decision on min. supported Python version.
> > >>>
> > >>
> > >This GDAL's RFC [1] is helpful in summarizing the issue with Python.
> > >Looking more into this, I suggest to go have a longer term strategy for
> > >dropping support for Python versions, which would be relatively simple.
> > >Basically we would keep the lowest Python version that wouldn't reach end
> > >of life at the time of a major release of GRASS. E.g. when we release G8
> > >this year, 3.6 will be minimum maintained version. Since 3.6 ends Dec 2021,
> > >we could drop 3.6 support next year. I am not saying we need to be strict
> > >about that, but might be helpful as a guidance, and it is independent on
> > >distributions (which is probably both advantage and disadvantage). I am
> > >unsure how this decision impacts packaging of grass, i.e. once we set 3.7
> > >as minimum, would maintainers need to make that Python a dependency of
> > >GRASS? Anyway, to summarize, I am for Python 3.6 at this point, but we need
> > >to reevaluate that with each new major GRASS version. I think this is
> > >conservative enough and perhaps more in line with the C standards
> > >discussion.
> > >
> >
> > +1
> >
> > Moritz
>
> +1
>
> Markus M
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20210210/80d8e7a4/attachment-0001.html>