Re: [GRASS-dev] [GRASS GIS] #3771: Run tests on Travis

[GRASS GIS]

#3771: Run tests on Travis
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Tests|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by wenzeslaus):

 Replying to [comment:7 sbl]:
 > Another relevant issue are test datasets, it seems.

 As for (older) full and (newer) basic version of NC SPM, I think
 nc_spm_full_v2alpha solves it //for now// (not ideal, but works). Making
 nc_spm_full_v2alpha work is a good goal for the Travis runs now.

 However, please also note the idea of different sample datasets, i.e.
 other than NC SPM (old/full or new/basic or full v2). Please see: GRASS-
 dev: Testsuite: script for easier use of test framework
 https://lists.osgeo.org/pipermail/grass-dev/2019-January/091011.html

 There are different approaches how to handle the different datasets in
 tests and by the runner, but idea is 1) to make easy to write very
 specific tests, 2) to test in different conditions like latlon GRASS
 Location, and 3) to have tests which run in any GRASS Location and/or
 without any data (so you can e.g. do `make test` without getting 100 MB of
 sample data).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3771: Run tests on Travis

[GRASS GIS]

#3771: Run tests on Travis
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Tests|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by wenzeslaus):

 Replying to [comment:6 sbl]:
 >   * **Crack down on the other 10%** of failing test (fix or deactivate
 temporarily if necessary as you suggest)

 You don't need 100% passing to run it on CI reasonably. That's the ideal
 state, but we can start with setting a threshold to what you consider OK.
 The idea is already there. Notice the colors of the percentages. What you
 need to add is mechanism for the main script to fail and not fail with a
 given success percentage value. This would catch serious problems, but
 that will be still quite a progress. So far it was mostly me checking the
 fatra server website and reporting it to mailing list (or, I think,
 directly to the committer in one recent case).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3771: Run tests on Travis

[GRASS GIS]

#3771: Run tests on Travis
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Tests|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by wenzeslaus):

 Replying to [comment:16 neteler]:
 > At time the "fatra" server no longer runs, it is frozen at date
 >
 > {{{
 > 2019-03-26 03:01:54   74304   nc_spm_full_v2alpha 93% 98%
 > }}}
 >
 > @vaclav: could you please check? thanks
 >
 > http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html

 Seems like a minor issue so far. Tests should still run locally (if you
 try). I should know more tomorrow (debug message added).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3771: Run tests on Travis

[GRASS GIS]

#3771: Run tests on Travis
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Tests|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by pmav99):

 Replying to [comment:18 sbl]:
 > Now multirunner also works with Python 3 and tests for P2 and P3 are
 more or less even...
 >
 > However, a new issue pops up:
 >
 > {{{
 > NameError: global name '_' is not defined
 > }}}

 That's related to #3772. Do you remember which tests are the problematic
 ones?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3804: Naming conventions for imports in GRASS codebase

[GRASS GIS]

#3804: Naming conventions for imports in GRASS codebase
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by pmav99):

 TBH, apart from:
 {{{
 import grass.script as grass
 import grass.script.core as grass
 }}}
 which I seriously dislike, I don't have any strong opinions on the matter.
 I agree though that @sbl's suggestion is probably the most reasonable
 approach.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-

Comment (by cmbarton):

 I tested i.pansharpen with these files. I was not able to reproduce the
 reported problem (no negative values in sharpened channels and all methods
 produce similar (though not identical) results. I did find an unrelated
 bug that can happen in rare cases and fixed it, and did a few other
 updates. Updated in trunk and merged to RB 7.6.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3772: Make the grass library importable outside of a GRASS session

[GRASS GIS]

#3772: Make the grass library importable outside of a GRASS session
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by pmav99):

 According to the docs, {{{lib/python/script/setup.py}}} contains functions
 that
 > can be used in Python scripts to setup a GRASS environment and session
 without using grassXY

 Not having the ability to import the {{{grass}}} library from a normal
 session means that you need to already be in a GRASS session in order to
 use the functions that can create a session (chicken-egg problem).

 After making the grass library importable, the whole problem of
 bootstrapping the GRASS session will finally be much easier to be
 resolved.

 Or course, we will need to review and if necessary improve the
 setup/cleanup functions in {{{lib/python/script/setup.py}}} and, most
 importantly, write tests for them. But after that is done, it will finally
 be possible to refactor/simplify the bootstrapping code in
 {{{lib/python/init/grass.py}}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3804: Naming conventions for imports in GRASS codebase

[GRASS GIS]

#3804: Naming conventions for imports in GRASS codebase
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by sbl):

 Sounds very reasonable to me and should also apply to addons.
 That might make it a bit easier for new addon-devs.

 A way to import, that can be applied at all levels while avoiding
 potential conflicts with other libraries would be to add a g before the
 names of the imported components, as it has been practice in many cases:

 import grass.script as gscript\\
 import grass.script.core as gcore\\
 import grass.pygrass.utils as gutils

 A respective guideline should be added to:
 https://trac.osgeo.org/grass/wiki/Submitting/Python

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3772: Make the grass library importable outside of a GRASS session

[GRASS GIS]

#3772: Make the grass library importable outside of a GRASS session
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by pmav99):

 Added a patch that makes it possible to import the GRASS library even from
 a normal shell session.

 After applying the patch and compiling, the code can be tested with:
 {{{
 LD_LIBRARY_PATH=dist.x86_64-pc-linux-gnu/lib PYTHONPATH=dist.x86_64-pc-
 linux-gnu/etc/python python -c 'import grass.script' && echo 'OK!'
 }}}

 The patch itself does 2 things:
 1. It does not resolve the path to {{{GISBASE}}} by using the ENV variable
 but by using the relative path from {{{dist.x86_64-pc-linux-
 gnu/etc/python/grass/__init__.py}}}
 2. It moves the caching of the GRASS commands from the
 {{{lib/python/pygrass/modules/shortcuts}}} module to the {{{MetaModule}}}
 class itself.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3772: Make the grass library importable outside of a GRASS session

[GRASS GIS]

#3772: Make the grass library importable outside of a GRASS session
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by pmav99):

 * Attachment "importable.patch" added.


-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3804: Naming conventions for imports in GRASS codebase

[GRASS GIS]

#3804: Naming conventions for imports in GRASS codebase
-+-
 Reporter:  pmav99   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  Python   |Version:  svn-trunk
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 There is a great deal of variation in the way that grass code does
 imports. Just a few examples:
 {{{
 import grass.script as core
 import grass.script as gcore
 import grass.script as grass
 import grass.script as gs
 import grass.script as gscript
 import grass.script as sgrass

 import grass.script.core as core
 import grass.script.core as gcore
 import grass.script.core as grass
 import grass.script.core as gscore

 import grass.script.raster as grast
 import grass.script.raster as raster

 import grass.pygrass.utils as gutils
 import grass.pygrass.utils as utils

 import grass.lib.gis as gislib
 import grass.lib.gis as libgis
 }}}
 I think it would be a good idea if a certain style was picked and
 consistently used throughout the codebase.

-- 
Ticket URL: 
GRASS GIS 

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