[GRASS-dev] New attempt to update GRASS for Mac

GRASS GRASS developer
1

Yesterday, I sent this message off-list to Anna and Vaclav. Anna asked if I could repost to the dev list. So I’m doing so here.

I have some time (I hope) on an upcoming research trip to NCAR, along with some promised help of software engineers at the CSDMS NSF facility. So I’m going to try again to come up with a new GRASS compiling and binary creation protocol.

I think this will involve the following components:

  1. Switch from the outdated PackageMaker.app to the current way of making Mac packages. This requires changes to the current binary bundling scripts.

  2. Bundle all dependencies (including the current, separate frameworks) into the new package distribution so that everything needed is in the grass7.app Can this be done with binary “framework” installations of dependencies or is it necessary to compile all from scratch to do this?

  3. As part of 2, make sure that all dependencies are compiled outside of the /usr folders on the Mac to avoid SIP conflicts

  4. To accomplish #2 and #3 for wxPython, we probably need to switch to wxPython 3 (or the new wxPython Phoenix if it is working correctly). This would also permit compiling ALL GRASS 64 bit, alleviating additional issues.

  5. Because of recent change to GRASS GUI and a bug in Mac system Python 2.7.10, it may be necessary to also bundle an updated Python (2.7.11 or higher) with the new grass7.app. This (and #2) would make the installation package significantly larger, but would avoid mismatched versions of Python and wxPython. It would also avoid potential conflicts between Mac system Python and other versions a user might have installed (e.g., with Anaconda).

Last fall, I was stuck on gettext. I will try again with bundline it, but this may not be solvable by me because it involves a hard-coded path in the build files that point to gettext files in /usr/local and no way to send an alternate path (e.g., a configure argument like ‘–with_gettext_libs=’. This will need to be fixed by whoever manages the build system. Otherwise, I’ll have to drop internationalization support for the Mac, which would be a shame.

An additional thing to note. While it may be possible for some to get GRASS compiled on the Mac using Homebrew, Macports, etc., the goal here is to create a normal DMG binary that any Mac user can download and install, without having to compile GRASS–or to install Linux like package managers first.

If anyone has experience in creating Mac DMGs, with bundled dependencies, I’d love to hear from you. Any other suggestions are welcome too.

Cheers
Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

2

Thanks Rainer,

If we can make GRASS install as much like a normal app as possible, it will be accessible to more users. So that has been my goal. I will probably drop back from the added things I was packaging previously (e.g., LAS support) to just get a new system working if it can be done.

My group (CoMSES Net) is looking into Docker as a means of more reproducible research in modeling science. Initial tests have gone OK, but show that doing software with a GUI is considerably more complicated than doing code that just runs from the command line. It might ultimately be worthwhile to package GRASS as a Docker image. But then people would have to install and deal with Docker to run it.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jul 19, 2017, at 12:28 AM, Rainer Krug <rainer_krug@icloud.com> wrote:

Dear Michael,

On 18 Jul 2017, at 22:26, Michael Barton <Michael.Barton@asu.edu> wrote:

Yesterday, I sent this message off-list to Anna and Vaclav. Anna asked if I could repost to the dev list. So I’m doing so here.

I have some time (I hope) on an upcoming research trip to NCAR, along with some promised help of software engineers at the CSDMS NSF facility. So I’m going to try again to come up with a new GRASS compiling and binary creation protocol.

I think this will involve the following components:

  1. Switch from the outdated PackageMaker.app to the current way of making Mac packages. This requires changes to the current binary bundling scripts.

  2. Bundle all dependencies (including the current, separate frameworks) into the new package distribution so that everything needed is in the grass7.app Can this be done with binary “framework” installations of dependencies or is it necessary to compile all from scratch to do this?

  3. As part of 2, make sure that all dependencies are compiled outside of the /usr folders on the Mac to avoid SIP conflicts

  4. To accomplish #2 and #3 for wxPython, we probably need to switch to wxPython 3 (or the new wxPython Phoenix if it is working correctly). This would also permit compiling ALL GRASS 64 bit, alleviating additional issues.

  5. Because of recent change to GRASS GUI and a bug in Mac system Python 2.7.10, it may be necessary to also bundle an updated Python (2.7.11 or higher) with the new grass7.app. This (and #2) would make the installation package significantly larger, but would avoid mismatched versions of Python and wxPython. It would also avoid potential conflicts between Mac system Python and other versions a user might have installed (e.g., with Anaconda).

Last fall, I was stuck on gettext. I will try again with bundline it, but this may not be solvable by me because it involves a hard-coded path in the build files that point to gettext files in /usr/local and no way to send an alternate path (e.g., a configure argument like ‘–with_gettext_libs=’. This will need to be fixed by whoever manages the build system. Otherwise, I’ll have to drop internationalization support for the Mac, which would be a shame.

An additional thing to note. While it may be possible for some to get GRASS compiled on the Mac using Homebrew, Macports, etc., the goal here is to create a normal DMG binary that any Mac user can download and install, without having to compile GRASS–or to install Linux like package managers first.

This sounds like a good plan and would be a valuable addition to the home-brew / Macports way of installing grass.

Just to clarify one point concerning homebrew: homebrew aims at providing pre-compiled binaries (so called “bottles”) which are used normally, and the normal installation of grass on home-brew on sierra does not require grass to be compiled locally.

I see all three ways (actually four - docker should be included as well!) of installing and using grass as equivalent and geared for different users / usage scenarios / workflows. So each of them has it’s merits and should be provided.

If anyone has experience in creating Mac DMGs, with bundled dependencies, I’d love to hear from you. Any other suggestions are welcome too.

Unfortunately no experiences, but I assume you know, you can Parallels Light is available for free, and allows you to run linux and Mac virtual machines on a mac - perfect for testing?

Cheers,

Rainer

Cheers
Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

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

3

On Wed, Jul 19, 2017 at 12:42 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:

My group (CoMSES Net) is looking into Docker as a means of more
reproducible research in modeling science. Initial tests have gone OK, but
show that doing software with a GUI is considerably more complicated than
doing code that just runs from the command line. It might ultimately be
worthwhile to package GRASS as a Docker image.

We don't have an official GRASS Docker image. Maybe it wouldn't be even
that advantageous for open science purposes. Anyway, we have already many
Dockerfiles. See for example one from me which I created for
reproducibility of my recent paper:

https://github.com/wenzeslaus/forestfrag3d/blob/master/Dockerfile

In the case of that repository, the idea is that user can (but does not
have to) run GRASS GIS or QGIS (with GRASS GIS) natively on the data
created in the Docker image, but the main outputs are PNG images, so no
special software is necessary.

In past, I had success in using Docker with SSH (all local). However, for
future it seems that things like Jupyter Notebook (with its widgets) or a
general web interface to GRASS GIS are a way how to get a GUI while using a
Docker image.

Vaclav

4

On Thu, Jul 20, 2017 at 3:34 AM, Rainer Krug <rainer_krug@icloud.com> wrote:

On 19 Jul 2017, at 21:54, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Wed, Jul 19, 2017 at 12:42 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:

My group (CoMSES Net) is looking into Docker as a means of more
reproducible research in modeling science. Initial tests have gone OK, but
show that doing software with a GUI is considerably more complicated than
doing code that just runs from the command line. It might ultimately be
worthwhile to package GRASS as a Docker image.

We don't have an official GRASS Docker image. Maybe it wouldn't be even
that advantageous for open science purposes.

I disagree here - it would be quite an advantage. See for example the
suite of rocker R images which are available and also used quite a bit (I
assume). There is even a spatial one (https://hub.docker.com/r/rock
er/geospatial/) which was added recentlyI, and I am still planning to
build on that bundle an image which includes GRASS so that you have one
Docker image for all your basic spatial GIS needs.

Anyway - I think a Docker image which is “officially” supported (which
does not contain the GUI, only the command line) would be a very good
starting point for further very useful Docker container. At least, there is
another readable recipe for building GRASS from source (in addition to the
TravisCI test).

I agree. There are two or three different cases. 1) Scientific images like
the R one you mentioned which won't be dedicated GRASS GIS images but
rather bundles where GRASS GIS is only one of the components. 2) Testing
image for build and running tests. The Dockerfile for some basic case can
be directly in the GRASS repository. 3) Dedicated Dockerfile/images for
specific projects, e.g. in the forestfrag3d repository there is a certain
development version with a custom patch (because of a bug). In this case
official image would not work because an that would be a stable release and
binary.

You can look at it also from a perspective of the GRASS code source. 1)
Dockerfile in the GRASS repository should use the code it lives in. 2) Some
software bundle may prefer to use some binary distribution (e.g. Ubuntu
PPAs). 3) Specific projects may need to use specific version of the code
and will download it from the repository.

Anyway, we have already many Dockerfiles. See for example one from me
which I created for reproducibility of my recent paper:

https://github.com/wenzeslaus/forestfrag3d/blob/master/Dockerfile

In the case of that repository, the idea is that user can (but does not
have to) run GRASS GIS or QGIS (with GRASS GIS) natively on the data
created in the Docker image, but the main outputs are PNG images, so no
special software is necessary.

So you have a GRASS Docker image, data is stored in /data in the native
system, you run the Docker GRASS to generate data, and you than can use a
native GRASS to do further work with the data - is this correct?

Yes. I provide people with Dockerfile through ZIP from paper or Git/GitHub
(as opposed to image from DockerHub). When running the container (`docker
run`) you specify what local/native directory should be linked to the
/data. All the intermediate and final outputs are stored there and
accessible when the `docker run` is done.

Creating and publishing a Docker image would probably add more stability to
the published work as it is a frozen state with all things included. (And
the repository with Dockerfile providing just the code for cases when
somebody wants to modify it.)

In past, I had success in using Docker with SSH (all local). However, for
future it seems that things like Jupyter Notebook (with its widgets) or a
general web interface to GRASS GIS are a way how to get a GUI while using a
Docker image.

Yes - a web GUI would be perfect - either as a standalone app which
connects to a GRASS session via e.g. ssh (which could be a local GRASS
Docker image) our local GRASS, or via a server which is in the Docker
image installed (as is with the RStudio images at
https://hub.docker.com/r/rocker/rstudio/.

What is the web GUI, i.e. how to get it to the web browser seems to be the
critical part here. But SSH may be a sufficient solution for now (e.g.
MobaXterm seem to work well for MS Win users - although I didn't see it
with Docker).

A Jupyter Notebook (never used it, but using RStudio Notebooks - I assume
very similar?) would be like literal programming - correct? And the results
(e.g. results) would be embedded in the resulting document?

Yes, they are similar. Code, text, results - all in one document. Jupyter
Notebook can also do widgets, i.e. you can have sliders or input boxes, so
the user doesn't have to change the code, it is enough to fiddle to a
dedicated minimalistic GUI. (Connecting this with GRASS parser and modules
may make it quite general and extremely interesting.)

That should not be a problem at all with a Docker image?

Right. You run a Docker container in the background. The container runs
Jupyter as server and when the right ports are open from Docker, you can
access the Jupyer Notebook from your web browser, but running all software
in Docker.

This sounds all very exciting!

Sure!

5

Here is a report on this effort, including identifying several items that will need to be changed by others for this to be successful.

I’ve successfully compiled GRASS 7 64bit, with wxPython 3.0.2.0 under the current OS (Sierra = OS X 10.12.x). I’m using the most current Kyngesburye frameworks for GDAL, Numpy, and MatPlotLib.

No binaries or bundled dependencies yet.

Issues that need to be resolved.

  1. the ‘python_wrapper’ bash script in …/macosx/app needs to be updated to allow for full 64bit compiling with wxPython. It currently tries to force 32bit Python if wxPython is present. I’ve done a hack but it is probably not the right thing for the long term.

  2. wxGUI needs a several fixes to run correctly with wxPython 3.

2.1 When switching from 3D to 2D, the ‘rotate 3D’ and ‘airplane’ buttons are not destroyed. They overprint the zoom to map extents button of 2D mode and will crash the GUI if pressed.

2.2 A custom control needs to be updated or replaced because it does not recognize mouse clicks. It is used in a number of different places, including in the bivariate histogram tool where it is used to select pairs of maps for histogramming. You can navigate this control (a pulldown) with arrow keys but not a mouse.

2.3 selecting g.gui.iclass will crash the GUI. I cannot get any error to come up on the console before the crash, and there is nothing in the terminal.

That’s all I’ve hit so far. I hope to start working on bundling for a binary next week.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jul 18, 2017, at 2:26 PM, Michael Barton <michael.barton@asu.edu> wrote:

Yesterday, I sent this message off-list to Anna and Vaclav. Anna asked if I could repost to the dev list. So I’m doing so here.

I have some time (I hope) on an upcoming research trip to NCAR, along with some promised help of software engineers at the CSDMS NSF facility. So I’m going to try again to come up with a new GRASS compiling and binary creation protocol.

I think this will involve the following components:

  1. Switch from the outdated PackageMaker.app to the current way of making Mac packages. This requires changes to the current binary bundling scripts.

  2. Bundle all dependencies (including the current, separate frameworks) into the new package distribution so that everything needed is in the grass7.app Can this be done with binary “framework” installations of dependencies or is it necessary to compile all from scratch to do this?

  3. As part of 2, make sure that all dependencies are compiled outside of the /usr folders on the Mac to avoid SIP conflicts

  4. To accomplish #2 and #3 for wxPython, we probably need to switch to wxPython 3 (or the new wxPython Phoenix if it is working correctly). This would also permit compiling ALL GRASS 64 bit, alleviating additional issues.

  5. Because of recent change to GRASS GUI and a bug in Mac system Python 2.7.10, it may be necessary to also bundle an updated Python (2.7.11 or higher) with the new grass7.app. This (and #2) would make the installation package significantly larger, but would avoid mismatched versions of Python and wxPython. It would also avoid potential conflicts between Mac system Python and other versions a user might have installed (e.g., with Anaconda).

Last fall, I was stuck on gettext. I will try again with bundline it, but this may not be solvable by me because it involves a hard-coded path in the build files that point to gettext files in /usr/local and no way to send an alternate path (e.g., a configure argument like ‘–with_gettext_libs=’. This will need to be fixed by whoever manages the build system. Otherwise, I’ll have to drop internationalization support for the Mac, which would be a shame.

An additional thing to note. While it may be possible for some to get GRASS compiled on the Mac using Homebrew, Macports, etc., the goal here is to create a normal DMG binary that any Mac user can download and install, without having to compile GRASS–or to install Linux like package managers first.

If anyone has experience in creating Mac DMGs, with bundled dependencies, I’d love to hear from you. Any other suggestions are welcome too.

Cheers
Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

6

On Thu, Jul 27, 2017 at 1:54 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

Here is a report on this effort, including identifying several items that
will need to be changed by others for this to be successful.

I've successfully compiled GRASS 7 64bit, with wxPython 3.0.2.0 under the
current OS (Sierra = OS X 10.12.x). I'm using the most current Kyngesburye
frameworks for GDAL, Numpy, and MatPlotLib.

No binaries or bundled dependencies yet.

Issues that need to be resolved.

1. the 'python_wrapper' bash script in ../macosx/app needs to be updated to
allow for full 64bit compiling with wxPython. It currently tries to force
32bit Python if wxPython is present. I've done a hack but it is probably not
the right thing for the long term.

2. wxGUI needs a several fixes to run correctly with wxPython 3.

2.1 When switching from 3D to 2D, the 'rotate 3D' and 'airplane' buttons are
not destroyed. They overprint the zoom to map extents button of 2D mode and
will crash the GUI if pressed.

I know about this one.

2.2 A custom control needs to be updated or replaced because it does not
recognize mouse clicks. It is used in a number of different places,
including in the bivariate histogram tool where it is used to select pairs
of maps for histogramming. You can navigate this control (a pulldown) with
arrow keys but not a mouse.

This is hard to solve, I don't think there is a good widget to replace this one.

2.3 selecting g.gui.iclass will crash the GUI. I cannot get any error to
come up on the console before the crash, and there is nothing in the
terminal.

I don't know about this one, maybe some ctypes thing, but at least
it's not a major component.

Another one I know about is the raster digitizer, where I need to
tweak the toolbar code to not crash, but I didn't get to it yet.

Could you possibly try wxPython 4 (Phoenix) with trunk? I am wondering
how that looks like...

Thanks,

Anna

That's all I've hit so far. I hope to start working on bundling for a binary
next week.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jul 18, 2017, at 2:26 PM, Michael Barton <michael.barton@asu.edu> wrote:

Yesterday, I sent this message off-list to Anna and Vaclav. Anna asked if I
could repost to the dev list. So I'm doing so here.

I have some time (I hope) on an upcoming research trip to NCAR, along with
some promised help of software engineers at the CSDMS NSF facility. So I'm
going to try again to come up with a new GRASS compiling and binary creation
protocol.

I think this will involve the following components:

1. Switch from the outdated PackageMaker.app to the current way of making
Mac packages. This requires changes to the current binary bundling scripts.

2. Bundle all dependencies (including the current, separate frameworks) into
the new package distribution so that everything needed is in the grass7.app
Can this be done with binary "framework" installations of dependencies or is
it necessary to compile all from scratch to do this?

3. As part of 2, make sure that all dependencies are compiled outside of the
/usr folders on the Mac to avoid SIP conflicts

4. To accomplish #2 and #3 for wxPython, we probably need to switch to
wxPython 3 (or the new wxPython Phoenix if it is working correctly). This
would also permit compiling ALL GRASS 64 bit, alleviating additional issues.

5. Because of recent change to GRASS GUI and a bug in Mac system Python
2.7.10, it may be necessary to also bundle an updated Python (2.7.11 or
higher) with the new grass7.app. This (and #2) would make the installation
package significantly larger, but would avoid mismatched versions of Python
and wxPython. It would also avoid potential conflicts between Mac system
Python and other versions a user might have installed (e.g., with Anaconda).

Last fall, I was stuck on gettext. I will try again with bundline it, but
this may not be solvable by me because it involves a hard-coded path in the
build files that point to gettext files in /usr/local and no way to send an
alternate path (e.g., a configure argument like '--with_gettext_libs='. This
will need to be fixed by whoever manages the build system. Otherwise, I'll
have to drop internationalization support for the Mac, which would be a
shame.

An additional thing to note. While it may be possible for some to get GRASS
compiled on the Mac using Homebrew, Macports, etc., the goal here is to
create a normal DMG binary that any Mac user can download and install,
without having to compile GRASS--or to install Linux like package managers
first.

If anyone has experience in creating Mac DMGs, with bundled dependencies,
I'd love to hear from you. Any other suggestions are welcome too.

Cheers
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

7

Anna,

Thanks for the quick response. See below.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jul 27, 2017, at 12:07 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Thu, Jul 27, 2017 at 1:54 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

Here is a report on this effort, including identifying several items that
will need to be changed by others for this to be successful.

I’ve successfully compiled GRASS 7 64bit, with wxPython 3.0.2.0 under the
current OS (Sierra = OS X 10.12.x). I’m using the most current Kyngesburye
frameworks for GDAL, Numpy, and MatPlotLib.

No binaries or bundled dependencies yet.

Issues that need to be resolved.

  1. the ‘python_wrapper’ bash script in …/macosx/app needs to be updated to
    allow for full 64bit compiling with wxPython. It currently tries to force
    32bit Python if wxPython is present. I’ve done a hack but it is probably not
    the right thing for the long term.

  2. wxGUI needs a several fixes to run correctly with wxPython 3.

2.1 When switching from 3D to 2D, the ‘rotate 3D’ and ‘airplane’ buttons are
not destroyed. They overprint the zoom to map extents button of 2D mode and
will crash the GUI if pressed.

I know about this one.

OK. Probably not too hard I hope.

2.2 A custom control needs to be updated or replaced because it does not
recognize mouse clicks. It is used in a number of different places,
including in the bivariate histogram tool where it is used to select pairs
of maps for histogramming. You can navigate this control (a pulldown) with
arrow keys but not a mouse.

This is hard to solve, I don’t think there is a good widget to replace this one.

I don’t see any noticeable difference between this control and the one used for r.patch (which works).

2.3 selecting g.gui.iclass will crash the GUI. I cannot get any error to
come up on the console before the crash, and there is nothing in the
terminal.

I don’t know about this one, maybe some ctypes thing, but at least
it’s not a major component.

Right. But hopefully someone can figure it out.

Another one I know about is the raster digitizer, where I need to
tweak the toolbar code to not crash, but I didn’t get to it yet.

Haven’t tested that.

Could you possibly try wxPython 4 (Phoenix) with trunk? I am wondering
how that looks like…

Sure. Is the configure script similar? My worry with wxPython 4 currently, is that it seems like it must be installed into a system folder where it might cause SIP problems.

Michael

Thanks,

Anna

That’s all I’ve hit so far. I hope to start working on bundling for a binary
next week.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=DwIBaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=47Q9MXJZRCcL5i9M9PgT2F3tdAlQVBzW92JuJlbxyu8&s=2nHCPVvo7tAxX8GU1RH1_aM-1_Bgdb9GDAtSEebe1Rc&e= , https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=DwIBaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=47Q9MXJZRCcL5i9M9PgT2F3tdAlQVBzW92JuJlbxyu8&s=-yI7_BSCJLWbfaDFGLVJN7xdKGL4heYGzAbjoFboEus&e=

On Jul 18, 2017, at 2:26 PM, Michael Barton <michael.barton@asu.edu> wrote:

Yesterday, I sent this message off-list to Anna and Vaclav. Anna asked if I
could repost to the dev list. So I’m doing so here.

I have some time (I hope) on an upcoming research trip to NCAR, along with
some promised help of software engineers at the CSDMS NSF facility. So I’m
going to try again to come up with a new GRASS compiling and binary creation
protocol.

I think this will involve the following components:

  1. Switch from the outdated PackageMaker.app to the current way of making
    Mac packages. This requires changes to the current binary bundling scripts.

  2. Bundle all dependencies (including the current, separate frameworks) into
    the new package distribution so that everything needed is in the grass7.app
    Can this be done with binary “framework” installations of dependencies or is
    it necessary to compile all from scratch to do this?

  3. As part of 2, make sure that all dependencies are compiled outside of the
    /usr folders on the Mac to avoid SIP conflicts

  4. To accomplish #2 and #3 for wxPython, we probably need to switch to
    wxPython 3 (or the new wxPython Phoenix if it is working correctly). This
    would also permit compiling ALL GRASS 64 bit, alleviating additional issues.

  5. Because of recent change to GRASS GUI and a bug in Mac system Python
    2.7.10, it may be necessary to also bundle an updated Python (2.7.11 or
    higher) with the new grass7.app. This (and #2) would make the installation
    package significantly larger, but would avoid mismatched versions of Python
    and wxPython. It would also avoid potential conflicts between Mac system
    Python and other versions a user might have installed (e.g., with Anaconda).

Last fall, I was stuck on gettext. I will try again with bundline it, but
this may not be solvable by me because it involves a hard-coded path in the
build files that point to gettext files in /usr/local and no way to send an
alternate path (e.g., a configure argument like ‘–with_gettext_libs=’. This
will need to be fixed by whoever manages the build system. Otherwise, I’ll
have to drop internationalization support for the Mac, which would be a
shame.

An additional thing to note. While it may be possible for some to get GRASS
compiled on the Mac using Homebrew, Macports, etc., the goal here is to
create a normal DMG binary that any Mac user can download and install,
without having to compile GRASS–or to install Linux like package managers
first.

If anyone has experience in creating Mac DMGs, with bundled dependencies,
I’d love to hear from you. Any other suggestions are welcome too.

Cheers
Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=DwIBaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=47Q9MXJZRCcL5i9M9PgT2F3tdAlQVBzW92JuJlbxyu8&s=2nHCPVvo7tAxX8GU1RH1_aM-1_Bgdb9GDAtSEebe1Rc&e= , https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=DwIBaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=47Q9MXJZRCcL5i9M9PgT2F3tdAlQVBzW92JuJlbxyu8&s=-yI7_BSCJLWbfaDFGLVJN7xdKGL4heYGzAbjoFboEus&e=

8

On Thu, Jul 27, 2017 at 2:32 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

Anna,

Thanks for the quick response. See below.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jul 27, 2017, at 12:07 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Thu, Jul 27, 2017 at 1:54 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:

Here is a report on this effort, including identifying several items that
will need to be changed by others for this to be successful.

I've successfully compiled GRASS 7 64bit, with wxPython 3.0.2.0 under the
current OS (Sierra = OS X 10.12.x). I'm using the most current Kyngesburye
frameworks for GDAL, Numpy, and MatPlotLib.

No binaries or bundled dependencies yet.

Issues that need to be resolved.

1. the 'python_wrapper' bash script in ../macosx/app needs to be updated to
allow for full 64bit compiling with wxPython. It currently tries to force
32bit Python if wxPython is present. I've done a hack but it is probably not
the right thing for the long term.

2. wxGUI needs a several fixes to run correctly with wxPython 3.

2.1 When switching from 3D to 2D, the 'rotate 3D' and 'airplane' buttons are
not destroyed. They overprint the zoom to map extents button of 2D mode and
will crash the GUI if pressed.

I know about this one.

OK. Probably not too hard I hope.

2.2 A custom control needs to be updated or replaced because it does not
recognize mouse clicks. It is used in a number of different places,
including in the bivariate histogram tool where it is used to select pairs
of maps for histogramming. You can navigate this control (a pulldown) with
arrow keys but not a mouse.

This is hard to solve, I don't think there is a good widget to replace this
one.

I don't see any noticeable difference between this control and the one used
for r.patch (which works).

Maybe I got confused about this one, I need to look at it then.

2.3 selecting g.gui.iclass will crash the GUI. I cannot get any error to
come up on the console before the crash, and there is nothing in the
terminal.

I don't know about this one, maybe some ctypes thing, but at least
it's not a major component.

Right. But hopefully someone can figure it out.

Another one I know about is the raster digitizer, where I need to
tweak the toolbar code to not crash, but I didn't get to it yet.

Haven't tested that.

Could you possibly try wxPython 4 (Phoenix) with trunk? I am wondering
how that looks like...

Sure. Is the configure script similar? My worry with wxPython 4 currently,
is that it seems like it must be installed into a system folder where it
might cause SIP problems.

I think you can use pip to install it with whatever Python you use, at
least that's what works on Linux.

Anna

Michael

Thanks,

Anna

That's all I've hit so far. I hope to start working on bundling for a binary
next week.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=DwIBaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=47Q9MXJZRCcL5i9M9PgT2F3tdAlQVBzW92JuJlbxyu8&s=2nHCPVvo7tAxX8GU1RH1_aM-1_Bgdb9GDAtSEebe1Rc&e=
,
https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=DwIBaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=47Q9MXJZRCcL5i9M9PgT2F3tdAlQVBzW92JuJlbxyu8&s=-yI7_BSCJLWbfaDFGLVJN7xdKGL4heYGzAbjoFboEus&e=

On Jul 18, 2017, at 2:26 PM, Michael Barton <michael.barton@asu.edu> wrote:

Yesterday, I sent this message off-list to Anna and Vaclav. Anna asked if I
could repost to the dev list. So I'm doing so here.

I have some time (I hope) on an upcoming research trip to NCAR, along with
some promised help of software engineers at the CSDMS NSF facility. So I'm
going to try again to come up with a new GRASS compiling and binary creation
protocol.

I think this will involve the following components:

1. Switch from the outdated PackageMaker.app to the current way of making
Mac packages. This requires changes to the current binary bundling scripts.

2. Bundle all dependencies (including the current, separate frameworks) into
the new package distribution so that everything needed is in the grass7.app
Can this be done with binary "framework" installations of dependencies or is
it necessary to compile all from scratch to do this?

3. As part of 2, make sure that all dependencies are compiled outside of the
/usr folders on the Mac to avoid SIP conflicts

4. To accomplish #2 and #3 for wxPython, we probably need to switch to
wxPython 3 (or the new wxPython Phoenix if it is working correctly). This
would also permit compiling ALL GRASS 64 bit, alleviating additional issues.

5. Because of recent change to GRASS GUI and a bug in Mac system Python
2.7.10, it may be necessary to also bundle an updated Python (2.7.11 or
higher) with the new grass7.app. This (and #2) would make the installation
package significantly larger, but would avoid mismatched versions of Python
and wxPython. It would also avoid potential conflicts between Mac system
Python and other versions a user might have installed (e.g., with Anaconda).

Last fall, I was stuck on gettext. I will try again with bundline it, but
this may not be solvable by me because it involves a hard-coded path in the
build files that point to gettext files in /usr/local and no way to send an
alternate path (e.g., a configure argument like '--with_gettext_libs='. This
will need to be fixed by whoever manages the build system. Otherwise, I'll
have to drop internationalization support for the Mac, which would be a
shame.

An additional thing to note. While it may be possible for some to get GRASS
compiled on the Mac using Homebrew, Macports, etc., the goal here is to
create a normal DMG binary that any Mac user can download and install,
without having to compile GRASS--or to install Linux like package managers
first.

If anyone has experience in creating Mac DMGs, with bundled dependencies,
I'd love to hear from you. Any other suggestions are welcome too.

Cheers
Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=DwIBaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=47Q9MXJZRCcL5i9M9PgT2F3tdAlQVBzW92JuJlbxyu8&s=2nHCPVvo7tAxX8GU1RH1_aM-1_Bgdb9GDAtSEebe1Rc&e=
,
https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=DwIBaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=47Q9MXJZRCcL5i9M9PgT2F3tdAlQVBzW92JuJlbxyu8&s=-yI7_BSCJLWbfaDFGLVJN7xdKGL4heYGzAbjoFboEus&e=

9

On Jul 27, 2017, at 12:46 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

I think you can use pip to install it with whatever Python you use, at
least that’s what works on Linux.

How do you specify which Python in pip?

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

10

On Thu, Jul 27, 2017 at 3:03 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

On Jul 27, 2017, at 12:46 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

I think you can use pip to install it with whatever Python you use, at
least that's what works on Linux.

How do you specify which Python in pip?

It uses whichever Python is first on the path, you can find out with

which python

probably you can use also something like this:

https://stackoverflow.com/a/4910393/1058453

Michael

____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

11

It seems that GRASS (at least GRASS for Mac) will only use the system Python. If I set up an environment in which Anaconda python is default, GRASS will not start and gives an error message that it will only run with the system Python. I don’t know where this is coming from. It doesn’t seem to be from the python_wrapper script. This will need to be changed if I am to package Python with GRASS.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jul 27, 2017, at 1:33 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Thu, Jul 27, 2017 at 3:03 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

On Jul 27, 2017, at 12:46 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

I think you can use pip to install it with whatever Python you use, at
least that’s what works on Linux.

How do you specify which Python in pip?

It uses whichever Python is first on the path, you can find out with

which python

probably you can use also something like this:

https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_a_4910393_1058453&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0&s=_vBpVdLmTTjrHrftXdNANYEvTAotd9_enwM-I1H_YFQ&e=

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0&s=9rsZ1tUV9snbiCH4rN8yrhhd4hDrfvamcPxF7y3cvRE&e= , https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0&s=8dy6hAPGI8vce9HOn68hYqtyg7hzPG5nT_Nt0fQIGCk&e=

12

On Thu, Jul 27, 2017 at 8:13 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

It seems that GRASS (at least GRASS for Mac) will only use the system
Python. If I set up an environment in which Anaconda python is default,
GRASS will not start and gives an error message that it will only run with
the system Python. I don't know where this is coming from. It doesn't seem
to be from the python_wrapper script. This will need to be changed if I am
to package Python with GRASS.

What exactly is the error? I know I was able to use GRASS_PYTHON
variable previously to set the python I needed.

Anna

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jul 27, 2017, at 1:33 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Thu, Jul 27, 2017 at 3:03 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:

On Jul 27, 2017, at 12:46 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

I think you can use pip to install it with whatever Python you use, at
least that's what works on Linux.

How do you specify which Python in pip?

It uses whichever Python is first on the path, you can find out with

which python

probably you can use also something like this:

https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_a_4910393_1058453&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0&s=_vBpVdLmTTjrHrftXdNANYEvTAotd9_enwM-I1H_YFQ&e=

Michael

____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0&s=9rsZ1tUV9snbiCH4rN8yrhhd4hDrfvamcPxF7y3cvRE&e=
,
https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0&s=8dy6hAPGI8vce9HOn68hYqtyg7hzPG5nT_Nt0fQIGCk&e=

13

I don’t remember the exact wording. I had set up a conda virtual environment to force GRASS to compile and run with Anaconda Python and wxPython 4. When I launched GRASS (trunk), I got an error message that it would only run with a system Python. I thought that is weird.

Anyway, I tried setting GRASS_PYTHON to no avail. See below:

g.gisenv get=GRASS_PYTHON
"/Applications/anaconda/bin/python"GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.

GRASS_PYTHON, is set, but it is still using system Python 2.7.10 instead of Anaconda Python 2.7.13

I went ahead and installed wxPython 4 to my system Python and recompiled. GRASS launches and runs fine, looking exactly like it does in wxPython 3, including the same bugs. But I’m not sure that it is actually running wxPython 4. When I try to test, I get odd errors (see below).

GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.

import wxversion
import wx
Traceback (most recent call last):
File “”, line 1, in
File “/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/init.py”, line 45, in
from wx._core import *
File “/Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/_core.py”, line 4, in
import core
ImportError: /Applications/GRASS-7.3.app/Contents/MacOS/etc/python/wx/core.so: no appropriate 64-bit architecture (see “man python” for running in 32-bit mode)

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jul 27, 2017, at 6:34 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Thu, Jul 27, 2017 at 8:13 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

It seems that GRASS (at least GRASS for Mac) will only use the system
Python. If I set up an environment in which Anaconda python is default,
GRASS will not start and gives an error message that it will only run with
the system Python. I don’t know where this is coming from. It doesn’t seem
to be from the python_wrapper script. This will need to be changed if I am
to package Python with GRASS.

What exactly is the error? I know I was able to use GRASS_PYTHON
variable previously to set the python I needed.

Anna

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ejnQRWolrucufjW07P5RKvDkaAo__J6-niGuF5D7eNg&s=97LlCjf7C4a6iG9wGSVOYu1lQuVXSps_-yEnDAGKWIE&e= , https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ejnQRWolrucufjW07P5RKvDkaAo__J6-niGuF5D7eNg&s=-IglMTXE4z0Ek6alARnfLbHdyXb7iyo7bg3-Gf0Uyb8&e=

On Jul 27, 2017, at 1:33 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Thu, Jul 27, 2017 at 3:03 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:

On Jul 27, 2017, at 12:46 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

I think you can use pip to install it with whatever Python you use, at
least that’s what works on Linux.

How do you specify which Python in pip?

It uses whichever Python is first on the path, you can find out with

which python

probably you can use also something like this:

https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_a_4910393_1058453&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0&s=_vBpVdLmTTjrHrftXdNANYEvTAotd9_enwM-I1H_YFQ&e=

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0&s=9rsZ1tUV9snbiCH4rN8yrhhd4hDrfvamcPxF7y3cvRE&e=
,
Center for Social Dynamics and Complexity

14

I just discovered something that has probably been giving increasing problems lately. Because I’ve been building binaries, I have not looked at the grass.app that is built from just running ‘make install’ in a long time.

It turns out that whatever creates the *.app automatically bundles some version of wxPython. I’ve been trying to bundle versions made outside of system folders to avoid the SIP issue, but there is code that is grabbing wxPython from somewhere and putting it into *.app/MacOS/etc/python folder inside the app. Hopefully someone reading this can figure out where this is happening and how to control it.

It explains why I have not been able to really test wxPython 4, and maybe even not wxPython 3. Certainly, it is NOT packaging wxPython 4 files into the app, even though I’ve compiled with explicit paths to the relevant wxPython 4 files.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jul 27, 2017, at 6:34 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Thu, Jul 27, 2017 at 8:13 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

It seems that GRASS (at least GRASS for Mac) will only use the system
Python. If I set up an environment in which Anaconda python is default,
GRASS will not start and gives an error message that it will only run with
the system Python. I don’t know where this is coming from. It doesn’t seem
to be from the python_wrapper script. This will need to be changed if I am
to package Python with GRASS.

What exactly is the error? I know I was able to use GRASS_PYTHON
variable previously to set the python I needed.

Anna

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ejnQRWolrucufjW07P5RKvDkaAo__J6-niGuF5D7eNg&s=97LlCjf7C4a6iG9wGSVOYu1lQuVXSps_-yEnDAGKWIE&e= , https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=ejnQRWolrucufjW07P5RKvDkaAo__J6-niGuF5D7eNg&s=-IglMTXE4z0Ek6alARnfLbHdyXb7iyo7bg3-Gf0Uyb8&e=

On Jul 27, 2017, at 1:33 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Thu, Jul 27, 2017 at 3:03 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:

On Jul 27, 2017, at 12:46 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

I think you can use pip to install it with whatever Python you use, at
least that’s what works on Linux.

How do you specify which Python in pip?

It uses whichever Python is first on the path, you can find out with

which python

probably you can use also something like this:

https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_a_4910393_1058453&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0&s=_vBpVdLmTTjrHrftXdNANYEvTAotd9_enwM-I1H_YFQ&e=

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton&d=DwIFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=MCkZA0y-uOGAo8gOeYPoP_uqc1lzXM6XCXuCQayAyS0&s=9rsZ1tUV9snbiCH4rN8yrhhd4hDrfvamcPxF7y3cvRE&e=
,
Center for Social Dynamics and Complexity

15

On Thu, Jul 27, 2017 at 11:13 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:

I don't remember the exact wording. I had set up a conda virtual
environment to force GRASS to compile and run with Anaconda Python and
wxPython 4. When I launched GRASS (trunk), I got an error message that it
would only run with a system Python. I thought that is weird.

Anyway, I tried setting GRASS_PYTHON to no avail. See below:

g.gisenv get=GRASS_PYTHON
"/Applications/anaconda/bin/python"GRASS 7.3.svn (nc_spm_08_grass7):~ >
python
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

GRASS_PYTHON, is set, but it is still using system Python 2.7.10 instead
of Anaconda Python 2.7.13

GRASS_PYTHON is actually an environmental variable (system driven, not by
GRASS) , so you need to use:

export GRASS_PYTHON=/.../python # set value
echo $GRASS_PYTHON # get value

g.setenv changes the GRASS (environment) variables (aka "GIS env" or "GRASS
variables").

https://grass.osgeo.org/grass72/manuals/variables.html
https://grass.osgeo.org/grass72/manuals/g.gisenv.html

16

OK. I’ll put it into my .profile and see what happens. Thanks.

The other issue I’m hitting is that the configure argument to enable wxPython, ‘-with-wxwidgets=’ expects a path to a wx_config file. AFAICT, wxPython 4 does not have such a file. And I can’t yet find anything that seems to serve the same function. I can put in a path to the folder/directory where the wxPython 4 files live. While this compiles without error, I don’t think it is using wxPython 4.

Michael

···

On Thu, Jul 27, 2017 at 11:13 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

I don’t remember the exact wording. I had set up a conda virtual environment to force GRASS to compile and run with Anaconda Python and wxPython 4. When I launched GRASS (trunk), I got an error message that it would only run with a system Python. I thought that is weird.

Anyway, I tried setting GRASS_PYTHON to no avail. See below:

g.gisenv get=GRASS_PYTHON
"/Applications/anaconda/bin/python"GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.

GRASS_PYTHON, is set, but it is still using system Python 2.7.10 instead of Anaconda Python 2.7.13

GRASS_PYTHON is actually an environmental variable (system driven, not by GRASS) , so you need to use:

export GRASS_PYTHON=/…/python # set value

echo $GRASS_PYTHON # get value

g.setenv changes the GRASS (environment) variables (aka “GIS env” or “GRASS variables”).

https://grass.osgeo.org/grass72/manuals/variables.html
https://grass.osgeo.org/grass72/manuals/g.gisenv.html

17

Tried that and it seems to be ignored too. Here is the output from a terminal in the shell (outside GRASS):

Last login: Thu Jul 27 22:04:37 on ttys001
CMB-MacBook-Pro:~ cmbarton$ echo $GRASS_PYTHON
/Applications/anaconda/bin/python

This should make anaconda python (2.7.13) the default.

But here is the output from a GRASS terminal:

GRASS 7.3.svn (nc_spm_08_grass7):~ > echo $GRASS_PYTHON
python
GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.

Also:

GRASS 7.3.svn (nc_spm_08_grass7):~ > echo $GRASS_PYTHONWX
/usr/bin/pythonw2.7

This environmental variable is set inside GRASS somewhere. It does not show up in the shell outside GRASS.

It GRASS ignoring the environmental variable setting for some reason. Is there something hardwired in that insists on looking for Python in /usr/bin?

Michael

···

On Thu, Jul 27, 2017 at 11:13 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

I don’t remember the exact wording. I had set up a conda virtual environment to force GRASS to compile and run with Anaconda Python and wxPython 4. When I launched GRASS (trunk), I got an error message that it would only run with a system Python. I thought that is weird.

Anyway, I tried setting GRASS_PYTHON to no avail. See below:

g.gisenv get=GRASS_PYTHON
"/Applications/anaconda/bin/python"GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.

GRASS_PYTHON, is set, but it is still using system Python 2.7.10 instead of Anaconda Python 2.7.13

GRASS_PYTHON is actually an environmental variable (system driven, not by GRASS) , so you need to use:

export GRASS_PYTHON=/…/python # set value

echo $GRASS_PYTHON # get value

g.setenv changes the GRASS (environment) variables (aka “GIS env” or “GRASS variables”).

https://grass.osgeo.org/grass72/manuals/variables.html
https://grass.osgeo.org/grass72/manuals/g.gisenv.html

18

On 28/07/17 06:19, Michael Barton wrote:

Tried that and it seems to be ignored too. Here is the output from a terminal in the shell (outside GRASS):

Last login: Thu Jul 27 22:04:37 on ttys001
CMB-MacBook-Pro:~ cmbarton$ echo $GRASS_PYTHON
/Applications/anaconda/bin/python

This should make anaconda python (2.7.13) the default.

But here is the output from a GRASS terminal:

GRASS 7.3.svn (nc_spm_08_grass7):~ > echo $GRASS_PYTHON
python

How and where did you set GRASS_PYTHON ? I'm not an expert in MacOSX, but in GNU/Linux if I set 'export GRASS_PYTHON=SomeOtherPython' in one terminal, but launch GRASS in the second terminal, GRASS_PYTHON is not set at GRASS startup and is thus set to 'python' by default.

GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

Also:

GRASS 7.3.svn (nc_spm_08_grass7):~ > echo $GRASS_PYTHONWX
/usr/bin/pythonw2.7

This environmental variable is set inside GRASS somewhere. It does not show up in the shell outside GRASS.

It GRASS ignoring the environmental variable setting for some reason. Is there something hardwired in that insists on looking for Python in /usr/bin?

Launching the 'python' binary in the command line does not interact in any way with the GRASS_PYTHON variable. If you launch 'python', it will launch the first python executable found in PATH.

If you want to see if GRASS_PYTHON correctly runs the python you wanted, then run '$GRASS_PYTHON'.

For example:

export GRASS_PYTHON=/usr/bin/python3.6
GRASS 7.3.svn (ETRS89_LAEA):/data/home/mlennert > python
Python 2.7.13 (default, Jan 19 2017, 14:48:08)
[GCC 6.3.0 20170118] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
GRASS 7.3.svn (ETRS89_LAEA):/data/home/mlennert > $GRASS_PYTHON
Python 3.6.2 (default, Jul 17 2017, 13:39:29)
[GCC 6.4.0 20170704] on linux
Type "help", "copyright", "credits" or "license" for more information.

There is a difference between calling 'python' from a command line in a terminal (even if the GRASS environnement variables are set, i.e. GRASS has been "started") and calling python using $GRASS_PYTHON as is done in the GRASS code.

Moritz

19

On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

OK. I’ll put it into my .profile and see what happens. Thanks.

On Fri, Jul 28, 2017 at 12:19 AM, Michael Barton <Michael.Barton@asu.edu> wrote:

Tried that and it seems to be ignored too. Here is the output from a terminal in the shell (outside GRASS):

Last login: Thu Jul 27 22:04:37 on ttys001
CMB-MacBook-Pro:~ cmbarton$ echo $GRASS_PYTHON
/Applications/anaconda/bin/python

This should make anaconda python (2.7.13) the default.

But here is the output from a GRASS terminal:

GRASS 7.3.svn (nc_spm_08_grass7):~ > echo $GRASS_PYTHON
python
GRASS 7.3.svn (nc_spm_08_grass7):~ > python
Python 2.7.10 (default, Feb 7 2017, 00:08:15)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.

Don’t add anything into any .profile or .bash_profile. Do it as Moritz suggests, use export right before you run the commands. (You can of course put these things in some file and then use source command.)

20

On Thu, Jul 27, 2017 at 11:52 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

The other issue I’m hitting is that the configure argument to enable wxPython, ‘-with-wxwidgets=’ expects a path to a wx_config file. AFAICT, wxPython 4 does not have such a file. And I can’t yet find anything that seems to serve the same function. I can put in a path to the folder/directory where the wxPython 4 files live. While this compiles without error, I don’t think it is using wxPython 4.

–with-wxwidgets= is for wxWidgets (C++ library), not wxPython (its Python wrapper), so you don’t need to use at all. wxPython must be part of the Python installation you are using.