Re: [GRASS-dev] [GRASS-user] experimental Python 3 support in trunk

[Vaclav Petras]

On Wed, Sep 5, 2018 at 3:57 PM Markus Metz 
wrote:

>
>
> On Wed, Sep 5, 2018 at 9:41 PM Martin Landa 
> wrote:
> >
> > Hi,
> >
> > st 5. 9. 2018 v 21:38 odesílatel Markus Metz
> >  napsal:
> > > alternatively, the shebang in GRASS *.py files can be changed to
> python3 (should be changed to python3 according to Python developer's Guide
> PEP394)
> >
> > we are going to support both Python2 and 3, at least for 7.6/7.8, right?
> Ma
>
> the symbolic link python is deprecated and will disappear soon from
> current distros: GRASS does not work if python does not exist, while
> python2 and/or python3 might exist. Current distros are already replacing
> the shebang in GRASS *.py files with python2. IMHO, if we want to support
> python3 we need to change the shebang accordingly: no more support for
> python2 in trunk.
>
> - python as a link to python2 is no longer available on modern distros
> - python3 is older than GRASS7
> - all currently supported distros provide a full python3 environment
>

Hi Markus and Martin,

That being said, GRASS GIS does not fully support Python 3 yet and, with
exception of few contributions, there was no major work done on the Python
3 support up until recently, i.e. we are not ready to switch to 3 for 7.6.
I think we can have something like "technical preview" in 7.8 (e.g. with
warning "use 3 only if you have to"). 8.0 should fully support 3.

Another thing is that Python 3 means using wxPython 4 to get the GUI (other
wxPythons don't support Python 3). That was hard to do for quite some time
(4.0.0 released in January), but now it is included, e.g., in Ubuntu 18.04
(released April).

As for the shebang, PEP394 says: "for the time being, all distributions
*should* ensure that python, if installed, refers to the same target as
python2, unless the user deliberately overrides this or a virtual
environment is active" and that "python should be used in the shebang line
only for scripts that are source compatible with both Python 2 and 3" which
is what we aim for. So that tells me we should keep there `python` and if a
distro decides to patch it to 2 (because their `python` does not point to
`python2` as PEP394 suggests) or perhaps later to 3 (because they want to
ensure `python3`), they are free to do that. We are not planning to drop
support for 2, so keeping `python` in shebang is appropriate in the long
term according to PEP394.

Best,
Vaclav


Links:
https://wxpython.org/news/wxpython-4.0.0-release/index.html
https://wxpython.org/news/wxpython-4.0.0a1-release/index.html
https://launchpad.net/ubuntu/+source/wxpython4.0
https://www.python.org/dev/peps/pep-0394/


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

Re: [GRASS-dev] [GRASS-user] experimental Python 3 support in trunk

[Markus Metz]

On Wed, Sep 5, 2018 at 9:41 PM Martin Landa  wrote:
>
> Hi,
>
> st 5. 9. 2018 v 21:38 odesílatel Markus Metz
>  napsal:
> > alternatively, the shebang in GRASS *.py files can be changed to
python3 (should be changed to python3 according to Python developer's Guide
PEP394)
>
> we are going to support both Python2 and 3, at least for 7.6/7.8, right?
Ma

the symbolic link python is deprecated and will disappear soon from current
distros: GRASS does not work if python does not exist, while python2 and/or
python3 might exist. Current distros are already replacing the shebang in
GRASS *.py files with python2. IMHO, if we want to support python3 we need
to change the shebang accordingly: no more support for python2 in trunk.

- python as a link to python2 is no longer available on modern distros
- python3 is older than GRASS7
- all currently supported distros provide a full python3 environment

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

Re: [GRASS-dev] [GRASS-user] experimental Python 3 support in trunk

[Martin Landa]

Hi,

st 5. 9. 2018 v 21:38 odesílatel Markus Metz
 napsal:
> alternatively, the shebang in GRASS *.py files can be changed to python3 
> (should be changed to python3 according to Python developer's Guide PEP394)

we are going to support both Python2 and 3, at least for 7.6/7.8, right? Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] experimental Python 3 support in trunk

[Markus Metz]

On Mon, Sep 3, 2018 at 8:28 AM Markus Neteler  wrote:
[...]
>
> Could you please post a few lines how to properly do the testing with
> virtualenv?

If python3 with all required packages is already installed on the system,
there is a simpler solution than virtualenv:

mkdir ~/bin_p3
ln -s /usr/bin/python3 ~/bin_p3/python

# make python3 the default python interpreter
export PATH="~/bin_p3:$PATH"

compile GRASS and run GRASS with these PATH settings

alternatively, the shebang in GRASS *.py files can be changed to python3
(should be changed to python3 according to Python developer's Guide PEP394)

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

Re: [GRASS-dev] [GRASS GIS] #3640: Remove winGRASS 6 from OSGeo4W

[GRASS GIS]

#3640: Remove winGRASS 6 from OSGeo4W
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Default  |Version:  unspecified
Resolution:   |   Keywords:  OSGeo4W
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by hellik):

 * keywords:   => OSGeo4W
 * type:  defect => task


-- 
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] #3640: Remove winGRASS 6 from OSGeo4W

[GRASS GIS]

#3640: Remove winGRASS 6 from OSGeo4W
-+-
 Reporter:  hellik   |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  Default  |Version:  unspecified
 Keywords:   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Following the discussion in

 https://lists.osgeo.org/pipermail/grass-dev/2018-September/089629.html

 There is now an effort to bring GRASS to Python 3.

 GRASS 6 is nowadays outdated and not maintained anymore, and is ready to
 be archived.

 To reduce too many and different winGRASS related packages (and
 dependencies) in OSGeo4W, GRASS 6 should be removed from OSGeo4W.

 This would also ease the maintainance and helps cleaning during transition
 to Python 3

-- 
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] #3639: Write table like output directly to database

[GRASS GIS]

#3639: Write table like output directly to database
--+--
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  8.0.0
 Component:  Database |Version:  svn-trunk
Resolution:   |   Keywords:  table,database,write
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by mlennert):

 In v.distance this is already available. I don't know if the solution is
 sufficiently general, and the outputs generated by the modules
 sufficiently similar to consider v.distance's code as boiler plate that
 can be integrated elsewhere. One issue is column types that need to be
 correctly defined. For the raster modules those will have to be determined
 from the input raster maps.

 Moritz

-- 
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] #3638: v.distance linear matrix remove duplicate cat column & table associated without having map of distance lines

[GRASS GIS]

#3638: v.distance linear matrix remove duplicate cat column & table associated
without having map of distance lines
--+-
  Reporter:  Maellevd |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:
 Component:  Vector   |Version:  7.4.0
Resolution:   |   Keywords:  v.distance
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by mlennert):

 Replying to [comment:3 mlennert]:
 >
 > See r73272 for the fix. I'll backport to the other branches ASAP.

 Done in r73273 and r73275.

 > I'll attach a patch with these enhancement (plus some attempt at
 cleaning up parser dependency instructions. This will partly change the
 module API, though, so we'll have to decide how to apply.

 Also done. This patch creates a new (-s) flag which allows to output a
 square matrix if desired. By default the module will output a linear
 matrix, whatever the number of upload variables.

 The patch also allows creating a table without creating a map and allows
 to determine column names in output, even when using -p or table=.

 Please test.

-- 
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] #3638: v.distance linear matrix remove duplicate cat column & table associated without having map of distance lines

[GRASS GIS]

#3638: v.distance linear matrix remove duplicate cat column & table associated
without having map of distance lines
--+-
  Reporter:  Maellevd |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:
 Component:  Vector   |Version:  7.4.0
Resolution:   |   Keywords:  v.distance
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by mlennert):

 * Attachment "vdistance_matrix_table.diff" added.

 patch for several issues identified in this ticket

-- 
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] #3638: v.distance linear matrix remove duplicate cat column & table associated without having map of distance lines

[GRASS GIS]

#3638: v.distance linear matrix remove duplicate cat column & table associated
without having map of distance lines
--+-
  Reporter:  Maellevd |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:
 Component:  Vector   |Version:  7.4.0
Resolution:   |   Keywords:  v.distance
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by sbl):

 For a more general request of writing table-like results directly to
 database see: #3639

-- 
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] #3639: Write table like output directly to database

[GRASS GIS]

#3639: Write table like output directly to database
--+-
 Reporter:  sbl   |  Owner:  grass-dev@…
 Type:  enhancement   | Status:  new
 Priority:  normal|  Milestone:  8.0.0
Component:  Database  |Version:  svn-trunk
 Keywords:  table,database,write  |CPU:  Unspecified
 Platform:  Unspecified   |
--+-
 It would be useful to be able to write table-like output from modules like
 v.distance, r.stats, r.category, r.what, directly into a table in the
 database...

 (see also: #3638)

-- 
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] #3638: v.distance linear matrix remove duplicate cat column & table associated without having map of distance lines

[GRASS GIS]

#3638: v.distance linear matrix remove duplicate cat column & table associated
without having map of distance lines
--+-
  Reporter:  Maellevd |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:
 Component:  Vector   |Version:  7.4.0
Resolution:   |   Keywords:  v.distance
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by mlennert):

 Thanks for reopening the ticket as there are several elements that are
 real requests for enhancements or even bugs. However, I agree with sbl
 that the original bug post could be less in the form of questions and more
 in the form of a bug report / enhancement request. If you are not sure
 about how to use a module than ask a question on the list. If you are
 (pretty) sure that there is a problem with a module, post a ticket here
 with the description of the problem.

 The duplicate cat values come from the fact that when you use -a a to_cat
 is automatically uploaded (otherwise how would one be able to use the
 resulting matrix ?), so upload=cat is redundant. But if a linear output is
 wanted, a second variable is needed. Try to run with upload=dist,to_x,to_y
 and you will see that there is no duplication.

 === Bug ===

 * The fact that the creation of a table is only possible when the input
 maps are in the current mapset is a bug IMHO. It is due to the fact that
 in the code updating the table and creating a new table is treated as
 equal by calling Vect_set_db_updated(). Moving this to only the part
 where the existing table is updated solves this issue.

 See r73272 for the fix. I'll backport to the other branches ASAP.

 === Enhancements ===

 * Currently, when using the -ap flag combination with one single upload
 variable, the module automatically prints out a square matrix. However, in
 certain situations it might be very useful to be able to print out a
 linear matrix. This could handled by a flag, e.g. -s for square matrix,
 instead of automatically

 * I do not understand why an output map should be necessary to create an
 output table. It can be useful to have such a table without a map.

 * To add to this: when printing or creating a new table, one should be
 able to determine column names, not only for updating an existing table

 I'll attach a patch with these enhancement (plus some attempt at cleaning
 up parser dependency instructions. This will partly change the module API,
 though, so we'll have to decide how to apply.

-- 
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] #3638: v.distance linear matrix remove duplicate cat column & table associated without having map of distance lines

[GRASS GIS]

#3638: v.distance linear matrix remove duplicate cat column & table associated
without having map of distance lines
--+-
  Reporter:  Maellevd |  Owner:  grass-dev@…
  Type:  defect   | Status:  reopened
  Priority:  normal   |  Milestone:
 Component:  Vector   |Version:  7.4.0
Resolution:   |   Keywords:  v.distance
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by sbl):

 * status:  closed => reopened
 * resolution:  worksforme =>
 * type:  enhancement => defect


Comment:

 Sorry, I was a bit quick and see that
 {{{
 v.distance -p -a from=hospitals to= hospitals upload=cat,dist
 }}}
 indeed produce duplicate columns


 Also,
 {{{
 ERROR: Bug: attempt to update map which is not in current mapset
 }}}

 should not happen.
 In addition, the resulting map also lacks an attribute table (which it
 should have). In more detail, the attribute table is produced, but not
 connected to the vector map...

 Writing table-formated output from GRASS directy to the database is a
 different issue, and might be useful in more modules...

-- 
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] #3638: v.distance linear matrix remove duplicate cat column & table associated without having map of distance lines

[GRASS GIS]

#3638: v.distance linear matrix remove duplicate cat column & table associated
without having map of distance lines
--+-
  Reporter:  Maellevd |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:
 Component:  Vector   |Version:  7.4.0
Resolution:  worksforme   |   Keywords:  v.distance
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by sbl):

 * status:  new => closed
 * resolution:   => worksforme


Comment:

 Please try the p-flag for generating only the table.
 https://grass.osgeo.org/grass74/manuals/v.distance.html

 As for the "duplicate" columns: Did you have a scroll down to from_cat 2?
 From there cat and to cat should no longer be duplicates...

 In principle, such questions are better asked at the user-mailing list
 where you get more attention for the question. Closing this ticket as
 worksforme, as I think what you want to achieve is already possible.
 Please feel free to reopen if mailing list confirms lacking features or
 unintended behavior…

-- 
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] #3638: v.distance linear matrix remove duplicate cat column & table associated without having map of distance lines

[GRASS GIS]

#3638: v.distance linear matrix remove duplicate cat column & table associated
without having map of distance lines
-+-
 Reporter:  Maellevd |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:
Component:  Vector   |Version:  7.4.0
 Keywords:  v.distance   |CPU:  Unspecified
 Platform:  Linux|
-+-
 Hello,
 I would like to receive some details related to the v.distance module with
 the graphical interface in GRASS 7.4.1.

 1) When I try to generate a linear matrix of distances using v.distance, I
 observe that the output contains a duplicate column (denoted “to_cat” and
 "cat" in the example below).
 Is there a reason for that ?
 Is there a way to generate a linear matrix of distances without that
 duplicated column ?

 ==
 Here's an example command I ran:
 {{{
 v.distance -p -a from=hospitals@x to= hospitals@x upload=cat,dist
 }}}
 with the following output:
 from_cat | to_cat | cat | dist
 1 | 1 | 1 | 0
 1 | 2 | 2 | 7489.1043632983983
 1 | 3 | 3 | 339112.17046729225
 ...
 ==


 2) When creating a table associated with the distance matrix:

 a) why do my vector layers need to belong to the current mapsets while the
 goal is not to update the vector layers ?

 Example:
 ==
 Command:
 {{{
 v.distance -a from=hospitals@PERMANENT to= hospitals@PERMANENT
 output=map_connect_hospital_PERM upload=cat,dist column=to_cat,dist_min
 table=tabl_dist_PERM
 }}}

 Output: ERROR: Bug: tentative de mise à jour d'une couche qui n'est pas
 dans le jeu de cartes courant
 ==

 b) why do you have to create a map of distance lines?
 Indeed, it seems to me that it would be interesting to generate the table
 without having this map.

 Example:
 ==
 Command:
 {{{
 v.distance -a from=hospitals@x to=hospitals@x output=map_connect_hospital
 upload=cat,dist column=to_cat,dist_min table=tabl_dist
 }}}

 ==

 How to get rid of this "output = map_connect_hospital" option and just get
 the table?


 Thank you in advance for your feedback on these two concerns

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Python and delayed or missing stderr output

[Nikos Alexandris]

* Markus Neteler  [2018-09-05 10:43:23 +0200]:


Hi,

AFAIK Python buffers (i.e. effectively delays)  stderr output which is
unhelpful in the GRASS GIS context.

Searching for a solution, I found this reference: sys.stdout.flush()
e.g.
https://stackoverflow.com/questions/10019456/usage-of-sys-stdout-flush-method

Would it be possible to add that to the GRASS GIS Python API?


And would this then make Python scripts, by default, to issue any print
statements (for debugging purposes or else) immediately?

I am unsure, but I think I see exactly this "problem" sometimes, when
scripting.  The order of what is requested to print out is sometimes mixed.

Thanks Markus.


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

[GRASS-dev] Python and delayed or missing stderr output

[Markus Neteler]

Hi,

AFAIK Python buffers (i.e. effectively delays)  stderr output which is
unhelpful in the GRASS GIS context.

Searching for a solution, I found this reference: sys.stdout.flush()
e.g.
https://stackoverflow.com/questions/10019456/usage-of-sys-stdout-flush-method

Would it be possible to add that to the GRASS GIS Python API?

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

Re: [GRASS-dev] [GRASS GIS] #1665: Grass SVN (51807) doesn’t launch: Path '…//' doesn't exist

[GRASS GIS]

#1665: Grass SVN (51807) doesn’t launch: Path '…//' doesn't
exist
+-
  Reporter:  vince  |  Owner:  grass-dev@…
  Type:  defect | Status:  closed
  Priority:  normal |  Milestone:  7.0.7
 Component:  Startup|Version:  svn-trunk
Resolution:  fixed  |   Keywords:
   CPU:  OSX/Intel  |   Platform:  MacOSX
+-

Comment (by neteler):

 Replying to [comment:11 wenzeslaus]:
 > r73262 and r73264 change `-gui` and `-text` in the messages to `--gui`
 and `--text` according to wiki:Grass8Planning. The preference of `--gui`
 over `-gui` is fairly new (since r73100, after 7.4), so we still have
 `-gui` etc. on couple more places.

 I have searched across the source code tree of trunk and relbranch76 and
 updated all occurrences of -text, -gtext, -gui to --text, --gtext, --gui
 in messages and manuals accordingly (r73265 and r73266).

-- 
Ticket URL: 
GRASS GIS 

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