[GRASS-dev] Re: Upcoming 7.2.0: review which addons to move to core

GRASS GRASS developer
21

Le 7 octobre 2016 10:41:50 GMT+02:00, "Blumentrath, Stefan" <Stefan.Blumentrath@nina.no> a écrit :

Hi again,

Interesting discussion!

With my user and amateur addon-developer perspective I would conclude
that:

[...]

And finally, Martins request regarding an RFC for "promoting modules to
core" should not drown in the discussion about unittests (even if the
latter probably is a precondition to the former)...

And what is your take on the actual need to move modules to core ? Why is it an advantage ? And as a corollary to that: what limits/issues do you see with g.extension ?

Moritz

22

Ahhh, yes, there was that branch of the discussion too...

g.extension is great and I do not see any limit with that, esp. not for single user environments.

However, on our server I download, compile and install centrally all addons from source using a script.
Thus, the main perceivable difference between core modules and addons would be visibility in the GUI...

For me personally, that is no issue. But people who start with GRASS likely often explore GRASS "graphically", thus a toolbox-approach would be very nice I think. Having an "Addons" entry in the menu (if there is space for that) where all installed addons register, would be a demonstration of existing addional functionality...
However, as you can imagine manually editing xml files for the numerous addons is no option for me. If it would be possible to implement your suggestion to add modules automatically to the GUI at install by means of Makefile (instead of g.extension) that would be splendid. But maybe I could change my script to use g.extension -s...

Advantages I see for moving addons to core:
- GRASS offers more "popular" functionality out of the box (new users probably do not check addons immediately when starting with GRASS)
- usually functionality is maintained to new major version (even if probably some exceptions exist, e.g. orthorectification GUI which has not been ported to G7 yet)
- moving an addon to core can be a kind of "award" or "reward" for an addon developer, thus it might be an incentive to e.g. add tests, documentation ...
- it might also help to motivate / involve more devs to contribute to core development?

Cheers
Stefan

-----Original Message-----
From: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Sent: 7. oktober 2016 11:00
To: Blumentrath, Stefan <Stefan.Blumentrath@nina.no>; Vaclav Petras <wenzeslaus@gmail.com>; Anna Petrášová <kratochanna@gmail.com>
Cc: GRASS developers list <grass-dev@lists.osgeo.org>; Markus Metz <markus.metz.giswork@gmail.com>
Subject: RE: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

Le 7 octobre 2016 10:41:50 GMT+02:00, "Blumentrath, Stefan" <Stefan.Blumentrath@nina.no> a écrit :

Hi again,

Interesting discussion!

With my user and amateur addon-developer perspective I would conclude
that:

[...]

And finally, Martins request regarding an RFC for "promoting modules to
core" should not drown in the discussion about unittests (even if the
latter probably is a precondition to the former)...

And what is your take on the actual need to move modules to core ? Why is it an advantage ? And as a corollary to that: what limits/issues do you see with g.extension ?

Moritz

23

[... two emails with lots of pointer to tests ...]

Please someone may create a (trac) wiki page since this will get lost
in the emails in no time.

thanks
Markus

24

On 07/10/16 11:35, Blumentrath, Stefan wrote:

Ahhh, yes, there was that branch of the discussion too...

g.extension is great and I do not see any limit with that, esp. not
for single user environments.

However, on our server I download, compile and install centrally all
addons from source using a script. Thus, the main perceivable
difference between core modules and addons would be visibility in the
GUI...

For me personally, that is no issue. But people who start with GRASS
likely often explore GRASS "graphically", thus a toolbox-approach
would be very nice I think. Having an "Addons" entry in the menu (if
there is space for that) where all installed addons register, would
be a demonstration of existing addional functionality...

[...]

On 05/10/16 23:10, Anna Petrášová wrote:
> Hmm, this is already implemented (several years I would say). Look
> into the tab Modules in layer manager. At least we now know, that
> nobody here is using it...

Yes, I have to admit that I rarely use the other tabs in the GUI, to my own disadvantage most probably...

But maybe we can think more radically. Just as several OS have moved away from the classical menu paradigm to search-based access to functionalities (e.g. gnome-shell, etc), why not completely get rid of the menus and only leave the modules tab as entry point ?

Again, just brainstorming...

Moritz

25

On 7 October 2016 1:26:09 pm Moritz Lennert mlennert@club.worldonline.be wrote:

On 07/10/16 11:35, Blumentrath, Stefan wrote:

Ahhh, yes, there was that branch of the discussion too…

g.extension is great and I do not see any limit with that, esp. not
for single user environments.

However, on our server I download, compile and install centrally all
addons from source using a script. Thus, the main perceivable
difference between core modules and addons would be visibility in the
GUI…

For me personally, that is no issue. But people who start with GRASS
likely often explore GRASS “graphically”, thus a toolbox-approach
would be very nice I think. Having an “Addons” entry in the menu (if
there is space for that) where all installed addons register, would
be a demonstration of existing addional functionality…

[…]

On 05/10/16 23:10, Anna Petrášová wrote:

Hmm, this is already implemented (several years I would say). Look
into the tab Modules in layer manager. At least we now know, that
nobody here is using it…

Yes, I have to admit that I rarely use the other tabs in the GUI, to my
own disadvantage most probably…

But maybe we can think more radically. Just as several OS have moved
away from the classical menu paradigm to search-based access to
functionalities (e.g. gnome-shell, etc), why not completely get rid of
the menus and only leave the modules tab as entry point ?

That works for some but surely not all users.

Again, just brainstorming…

Moritz

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

26

Agreed with Paulo.

My impression is that new users rely on the menu to explore the software and its modules…

···

From: Paulo van Breugel [mailto:p.vanbreugel@gmail.com]
Sent: 7. oktober 2016 13:35
To: Moritz Lennert mlennert@club.worldonline.be; Blumentrath, Stefan Stefan.Blumentrath@nina.no; Vaclav Petras wenzeslaus@gmail.com; Anna Petrášová kratochanna@gmail.com
Cc: GRASS developers list grass-dev@lists.osgeo.org; Markus Metz markus.metz.giswork@gmail.com
Subject: Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

On 7 October 2016 1:26:09 pm Moritz Lennert <mlennert@club.worldonline.be> wrote:

On 07/10/16 11:35, Blumentrath, Stefan wrote:

Ahhh, yes, there was that branch of the discussion too…

g.extension is great and I do not see any limit with that, esp. not
for single user environments.

However, on our server I download, compile and install centrally all
addons from source using a script. Thus, the main perceivable
difference between core modules and addons would be visibility in the
GUI…

For me personally, that is no issue. But people who start with GRASS
likely often explore GRASS “graphically”, thus a toolbox-approach
would be very nice I think. Having an “Addons” entry in the menu (if
there is space for that) where all installed addons register, would
be a demonstration of existing addional functionality…

[…]

On 05/10/16 23:10, Anna Petrášová wrote:

Hmm, this is already implemented (several years I would say). Look
into the tab Modules in layer manager. At least we now know, that
nobody here is using it…

Yes, I have to admit that I rarely use the other tabs in the GUI, to my
own disadvantage most probably…

But maybe we can think more radically. Just as several OS have moved
away from the classical menu paradigm to search-based access to
functionalities (e.g. gnome-shell, etc), why not completely get rid of
the menus and only leave the modules tab as entry point ?

That works for some but surely not all users.

Again, just brainstorming…

Moritz

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

27

On 7 October 2016 3:14:14 pm “Blumentrath, Stefan” Stefan.Blumentrath@nina.no wrote:

Hi again,

Interesting discussion!

With my user and amateur addon-developer perspective I would conclude that:

  • we all agree that tests/unittests are very useful even if not “the silver bullet”
  • things one does in “unittests” might also partly be done in the code of the module (e.g. check for a specific state of input or environment variables …), so a requirement for unittest might have to go hand in hand with a requirement for “maturity” of the module?
  • “unittests” can also differ a lot in complexity so it is probably not too easy to say which level of unit tests should be required for a new core module, and the presence of a test alone does not necessarily mean that a module is “well tested”…
  • it might be a good starting point to “require” only “simple” unittests for new core modules in that sense that a unit test makes sure that at least examples from the manual work without throwing an error? That would at the same time test code and manual/documentation… There was the idea to use examples from the manual to auto-generate tests, was`nt it?
  • with more tests on “higher level” modules, also “lower level functions” (e.g. library) might be covered. This could on the one hand help to trace (side) effect of changes on lower level functions, but on the other hand might require to also update all output-tests which were written based on that bogus library function, would not it?
  • like some others here I never wrote a test for my addons, but I would be willing to learn!

Same here

Here the simple examples Vaclav provided were very helpful, as for me as a rookie the more involved examples and the full documentation of the unittests are hard to understand.

Again, same here

Maybe you can add a very minimalistic example to the test documentation that only checks (e.g. based on NC data set) that e.g. “r.example -g input=mymap” works without throwing an error?

+1

And finally, Martins request regarding an RFC for “promoting modules to core” should not drown in the discussion about unittests (even if the latter probably is a precondition to the former)…

Cheers
Stefan

P.S.: For automatized tests of addons there might be a dependency issue, as a test-server would have to be equipped with all possible dependencies in order to be able to run the addons?

-----Original Message-----
From: grass-dev [mailto:grass-dev-bounces@lists.osgeo.org] On Behalf Of Moritz Lennert
Sent: 7. oktober 2016 08:32
To: Vaclav Petras wenzeslaus@gmail.com; Anna Petrášová kratochanna@gmail.com
Cc: GRASS developers list grass-dev@lists.osgeo.org; Markus Metz markus.metz.giswork@gmail.com
Subject: Re: [GRASS-dev] Fwd: Re: Upcoming 7.2.0: review which addons to move to core

On 06/10/16 23:34, Vaclav Petras wrote:

On Tue, Oct 4, 2016 at 4:55 PM, Anna Petrášová <kratochanna@gmail.com
mailto:kratochanna@gmail.com> wrote:

[…]

c) test correctness of results.
It just depends how you write them, and yes, for some modules c) is
more difficult to implement than for others.

On Thu, Oct 6, 2016 at 5:00 PM, Anna Petrášová <kratochanna@gmail.com
mailto:kratochanna@gmail.com> wrote:

There is correct result in the sense “as author intended”. So you can
use pen and paper and solve very small example. That doesn’t mean it
will cover all options, but better than nothing. […]

For r.forestfrag, I wrote a test which was based on an example in the
original paper which was computing value of one cell in 3x3 window. It
is a really trivial example which tests 1 number and two other numbers
which are intermediate results. However, by writing it, I actually
discovered that although the results for a large area look good, this
small example, which I was able compute by hand, is failing. After
investigation, it turned out that the error is actually in r.mapcalc.
Computing the result outside of GRASS was crucial in this case. It was
an index and I was able to compute it by hand (and check it with the
example in the paper). For some other modules it could be more
difficult and I don’t want to compute it without GRASS for more than
one cell even in this case, but it was certainly possible to write a
test of correctness for this module. Note that the test doesn’t show
if the (forest fragmentation) index makes sense or if it is useful,
but it shows that the module gives the result it promised.

This is the original test:

https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.fore
stfrag/testsuite/r_forestfrag_trivial.py

Nice example, thanks !

This is the r.mapcalc bug:

https://trac.osgeo.org/grass/ticket/3067

And this is test which specifically shows the bug (would show if it
would be reintroduced):

https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.mapcalc/test
suite/test_row_above_below_bug.py

Here we have an example of a test with 70 lines of code which was comitted almost at the same time as the issue was fixed (ok 3 days before), with a one-line fix. Now, it’s good to safeguard against this bug reappearing, but I would argue that this example shows that we often only think of relevant tests after a bug appears, and I’m not sure that it is very efficient to write a test at that point, given the low probability of that bug reappearing :wink:

But hey, bear with me, I’m learning…

Moritz

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev