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

Anna Petrášová kratochanna at gmail.com
Sat Feb 6 20:01:38 PST 2021


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.

Anna

[1] https://gdal.org/development/rfc/rfc77_drop_python2_support.html


>>
>> Best,
>> Nicklas
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20210206/6b5001d6/attachment.html>


More information about the grass-dev mailing list