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

[Moritz Lennert]

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