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

2021-03-22 Thread Veronica Andreo
Hi everybody,

Ok, so we can now vote the C/C++ RFC, and then open a new thread + RFC
regarding support for python versions.

I'll send the voting motion later today or tomorrow.

Cheers,
Vero

El lun, 22 mar 2021 a las 11:18, Nicklas Larsson ()
escribió:

> Forgot to add: Python support changes with GRASS minor versions adds a bit
> of complication with add-ons, which are bound to major version. I don't
> know what would be the better solution for this.
>
> N.
>
>
>
>
>
>
>
> On Monday, 22 March 2021, 10:24:06 CET, Nicklas Larsson via grass-psc <
> grass-...@lists.osgeo.org> wrote:
>
>
>
>
>
> Hi,
>
> Although I didn't see the need to remove Python from RFC 7 (as it was
> originally formulated), there is also some logic to treat Python as a whole
> in a separate RFC. I don't have strong opinion on either way, therefore I
> lifted out Python from the draft, which now only deals with C and C++.
> Hopefully it may now be ready for vote :).
>
> Regarding Python: I believe version support should be linked to Python
> end-of-life circle and GRASS minor version.
>
> Best,
> Nicklas
>
>
>
>
> On Sunday, 21 March 2021, 09:04:24 CET, Markus Neteler 
> wrote:
>
>
>
>
>
> Hi,
>
> On Tue, Mar 16, 2021 at 8:30 PM Veronica Andreo 
> wrote:
> >
> > Hi everyone
> >
> > Thanks for all the feedback.
> >
> > In practical terms then, shall we:
> > - remove all python references from the Language Standards draft RFC [0]
> and vote only for C/C++, while creating a separate RFC for the minimum
> python version?
> > - add a formula that sets on which pace the minimum supported python
> version will change to the Language Standards draft RFC [0] and vote for
> everything altogether?
>
> For Python support, it is worth looking at the GDAL RFC 77 which
> includes useful tables and links:
> - https://gdal.org/development/rfc/rfc77_drop_python2_support.html
>
> esp.:
> -
> https://endoflife.date/python#:~:text=The%20support%20for%20Python%202.7,dropping%20support%20for%20Python%202.7
>
> Useful is also
> - https://repology.org/project/python/versions
>
> With respect to the pace of periodic review and updating of the
> language standards support I believe that we need that at the pace of
> sub-major releases (e.g., 7.8 -> 7.9). Just look back at the major
> releases (https://grass.osgeo.org/about/history/releases/) we observe
> quite some time span:
>
> - (2021) GRASS GIS 8.0.0
> - 2015 GRASS GIS 7.0.0
> - 2005 GRASS GIS 6.0.0
> - 2002 GRASS GIS 5.0.0
> - 1991 GRASS 4.0
> - 1988 GRASS 3.0
> - 1987 GRASS 2.0
> - 1984 GRASS 1.0
>
> Hence sub-major releases might be the way to go.
>
> Markus
>
>
> > [0] https://trac.osgeo.org/grass/wiki/RFC/7_LanguageStandardsSupport
>
>
> ___
> grass-psc mailing list
> grass-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-psc
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


[GRASS-dev] Failing addon releasebranch_7_8 (Python 3.6) pipeline

2021-03-22 Thread Markus Neteler
Hi devs,

I regularly receive

releasebranch_7_8 (Python 3.6)
Process completed with exit code 1.

(e.g., https://github.com/OSGeo/grass-addons/actions/runs/675694073)

which is a bit confusing for me since we (I believe) already fixed the issues:

Executing 
...
generate_manpage_images from ./vector/v.stream.order failed
test_stream_order from ./vector/v.stream.order failed (2 tests failed)
test_pygbif_import from ./vector/v.in.pygbif failed (3 tests failed)
test_v_db_pyupdate from ./vector/v.db.pyupdate failed (2 tests failed)
r3_forestfrag_trivial from ./raster3d/r3.forestfrag failed (1 test failed)
test_whatcsv from ./temporal/t.rast.whatcsv failed (1 test failed)
test_whataggr from ./temporal/t.rast.what.aggr failed (6 tests failed)
test_gpot from ./raster/r.green/r.green.gshp/libgshp failed
test_numbers from ./raster/r.sample.category failed
r_extract_test from ./raster/r.extract failed (2 tests failed)
r_object_geometry_test from ./raster/r.object.geometry failed (2 tests failed)
test_base_resolution from ./raster/r.in.pdal failed
r_forestfrag_trivial from ./raster/r.forestfrag failed (1 test failed)
r_forestfrag_xy from ./raster/r.forestfrag failed (1 test failed)
test_append from ./raster/r.learn.ml2 failed

Does anyone know why it fails in the releasebranch_7_8 (Python 3.6)
pipeline but works in releasebranch_7_8 (Python 3.8)?

thanks
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


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

2021-03-22 Thread Nicklas Larsson via grass-dev
Forgot to add: Python support changes with GRASS minor versions adds a bit of 
complication with add-ons, which are bound to major version. I don't know what 
would be the better solution for this.

N.







On Monday, 22 March 2021, 10:24:06 CET, Nicklas Larsson via grass-psc 
 wrote: 





Hi,

Although I didn't see the need to remove Python from RFC 7 (as it was 
originally formulated), there is also some logic to treat Python as a whole in 
a separate RFC. I don't have strong opinion on either way, therefore I lifted 
out Python from the draft, which now only deals with C and C++. Hopefully it 
may now be ready for vote :).

Regarding Python: I believe version support should be linked to Python 
end-of-life circle and GRASS minor version.

Best,
Nicklas




On Sunday, 21 March 2021, 09:04:24 CET, Markus Neteler  
wrote: 





Hi,

On Tue, Mar 16, 2021 at 8:30 PM Veronica Andreo  wrote:
>
> Hi everyone
>
> Thanks for all the feedback.
>
> In practical terms then, shall we:
> - remove all python references from the Language Standards draft RFC [0] and 
> vote only for C/C++, while creating a separate RFC for the minimum python 
> version?
> - add a formula that sets on which pace the minimum supported python version 
> will change to the Language Standards draft RFC [0] and vote for everything 
> altogether?

For Python support, it is worth looking at the GDAL RFC 77 which
includes useful tables and links:
- https://gdal.org/development/rfc/rfc77_drop_python2_support.html

esp.:
- 
https://endoflife.date/python#:~:text=The%20support%20for%20Python%202.7,dropping%20support%20for%20Python%202.7

Useful is also
- https://repology.org/project/python/versions

With respect to the pace of periodic review and updating of the
language standards support I believe that we need that at the pace of
sub-major releases (e.g., 7.8 -> 7.9). Just look back at the major
releases (https://grass.osgeo.org/about/history/releases/) we observe
quite some time span:

- (2021) GRASS GIS 8.0.0
- 2015 GRASS GIS 7.0.0
- 2005 GRASS GIS 6.0.0
- 2002 GRASS GIS 5.0.0
- 1991 GRASS 4.0
- 1988 GRASS 3.0
- 1987 GRASS 2.0
- 1984 GRASS 1.0

Hence sub-major releases might be the way to go.

Markus


> [0] https://trac.osgeo.org/grass/wiki/RFC/7_LanguageStandardsSupport


___
grass-psc mailing list
grass-...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-psc
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


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

2021-03-22 Thread Nicklas Larsson via grass-dev
 Hi,

Although I didn't see the need to remove Python from RFC 7 (as it was 
originally formulated), there is also some logic to treat Python as a whole in 
a separate RFC. I don't have strong opinion on either way, therefore I lifted 
out Python from the draft, which now only deals with C and C++. Hopefully it 
may now be ready for vote :).

Regarding Python: I believe version support should be linked to Python 
end-of-life circle and GRASS minor version.

Best,
Nicklas
 On Sunday, 21 March 2021, 09:04:24 CET, Markus Neteler  
wrote:  
 
 Hi,

On Tue, Mar 16, 2021 at 8:30 PM Veronica Andreo  wrote:
>
> Hi everyone
>
> Thanks for all the feedback.
>
> In practical terms then, shall we:
> - remove all python references from the Language Standards draft RFC [0] and 
> vote only for C/C++, while creating a separate RFC for the minimum python 
> version?
> - add a formula that sets on which pace the minimum supported python version 
> will change to the Language Standards draft RFC [0] and vote for everything 
> altogether?

For Python support, it is worth looking at the GDAL RFC 77 which
includes useful tables and links:
- https://gdal.org/development/rfc/rfc77_drop_python2_support.html

esp.:
- 
https://endoflife.date/python#:~:text=The%20support%20for%20Python%202.7,dropping%20support%20for%20Python%202.7

Useful is also
- https://repology.org/project/python/versions

With respect to the pace of periodic review and updating of the
language standards support I believe that we need that at the pace of
sub-major releases (e.g., 7.8 -> 7.9). Just look back at the major
releases (https://grass.osgeo.org/about/history/releases/) we observe
quite some time span:

- (2021) GRASS GIS 8.0.0
- 2015 GRASS GIS 7.0.0
- 2005 GRASS GIS 6.0.0
- 2002 GRASS GIS 5.0.0
- 1991 GRASS 4.0
- 1988 GRASS 3.0
- 1987 GRASS 2.0
- 1984 GRASS 1.0

Hence sub-major releases might be the way to go.

Markus

> [0] https://trac.osgeo.org/grass/wiki/RFC/7_LanguageStandardsSupport
  ___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev