[GRASS-dev] python2/3 and GRASS build on Arch

Maciej_Sieczka · January 2, 2013, 10:24am

Hi,

On Arch GNU/Linux the `python' executable by default links to `python3'. To use Python 2.x, one has to call `python2' explicitely. This requires Archers to tweak include/Make/Platform.make.in and each GRASS python executable to build and use GRASS (e.g. like in https://aur.archlinux.org/packages/gr/grass7-svn/PKGBUILD).

Can GRASS make system be changed so that the python executable used during GRASS build and runtime is configurable?

Probably the problem is limited to this one distro now, but this might change in future I guess.

Maciek

--
Maciej Sieczka
http://www.sieczka.org

neteler · January 2, 2013, 8:04pm

On Wed, Jan 2, 2013 at 11:24 AM, Maciej Sieczka <msieczka@sieczka.org> wrote:

Hi,

On Arch GNU/Linux the `python' executable by default links to `python3'. To
use Python 2.x, one has to call `python2' explicitely. This requires Archers
to tweak include/Make/Platform.make.in and each GRASS python executable to
build and use GRASS (e.g. like in
https://aur.archlinux.org/packages/gr/grass7-svn/PKGBUILD).

Can GRASS make system be changed so that the python executable used during
GRASS build and runtime is configurable?

I checked and found this:

[neteler@north grass64]$ sh configure --help 2>&1 | grep python
  --with-python[=path/python-config]
                          (python-config with path, e.g.
                          '--with-python=/usr/bin/python2.5-config',

which sets
AC_SUBST(PYTHONINC)
AC_SUBST(PYTHONCFLAGS)
AC_SUBST(PYTHONLDFLAGS)
AC_SUBST(USE_PYTHON)
AC_SUBST(MACOSX_ARCHS_PYTHON)

This has been removed from GRASS 7:

[neteler@north grass70]$ sh configure --help 2>&1 | grep python
[neteler@north grass70]$

Perhaps this change should be reverted?
http://trac.osgeo.org/grass/changeset/45388

Markus

martinl · January 2, 2013, 9:21pm

Hi,

2013/1/2 Markus Neteler <neteler@osgeo.org>:

[neteler@north grass64]$ sh configure --help 2>&1 | grep python
  --with-python[=path/python-config]
                          (python-config with path, e.g.
                          '--with-python=/usr/bin/python2.5-config',

which sets
AC_SUBST(PYTHONINC)
AC_SUBST(PYTHONCFLAGS)
AC_SUBST(PYTHONLDFLAGS)
AC_SUBST(USE_PYTHON)
AC_SUBST(MACOSX_ARCHS_PYTHON)

This has been removed from GRASS 7:

[neteler@north grass70]$ sh configure --help 2>&1 | grep python
[neteler@north grass70]$

Perhaps this change should be reverted?
http://trac.osgeo.org/grass/changeset/45388

AFAIK no, it was used to build executables against python libs. There
is nothing to be build against python libs in G7.

Specifying PYTHON variable in Platform.make.in (currently hardcoded to
'python') should be enough

include/Make/Platform.make:PYTHON = python

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Glynn_Clements1 · January 3, 2013, 1:45am

Maciej Sieczka wrote:

On Arch GNU/Linux the `python' executable by default links to
`python3'. To use Python 2.x, one has to call `python2' explicitely.
This requires Archers to tweak include/Make/Platform.make.in and each
GRASS python executable to build and use GRASS (e.g. like in
https://aur.archlinux.org/packages/gr/grass7-svn/PKGBUILD).

Can GRASS make system be changed so that the python executable used
during GRASS build and runtime is configurable?

The python interpreter is accessed via the make variable PYTHON, so
you can use e.g.:

make PYTHON=python2

But in 7.0, all of the shell scripts have been replaced by Python
scripts, with the shebang:

#!/usr/bin/env python

The simplest solution for this is probably to add a symlink from
$GISBASE/bin/python to the appropriate interpreter.

--
Glynn Clements <glynn@gclements.plus.com>

Maciej_Sieczka · January 3, 2013, 7:22pm

W dniu 03.01.2013 02:45, Glynn Clements pisze:

Maciej Sieczka wrote:

On Arch GNU/Linux the `python' executable by default links to
`python3'. To use Python 2.x, one has to call `python2'
explicitely. This requires Archers to tweak
include/Make/Platform.make.in and each GRASS python executable to
build and use GRASS (e.g. like in
https://aur.archlinux.org/packages/gr/grass7-svn/PKGBUILD).

Can GRASS make system be changed so that the python executable
used during GRASS build and runtime is configurable?

The python interpreter is accessed via the make variable PYTHON, so
you can use e.g.:

make PYTHON=python2

Still one error crops out - ctypesgen.py has "#!/usr/bin/env python"
shebang, which calls Python 3.x on Arch, therefore:

$ make PYTHON=python2
<snip>
make[4]: Entering directory
`/home/users/pok/src/builds/releasebranch_6_4/lib/python/ctypes'
(...)
Traceback (most recent call last)
   File "./ctypesgen.py", line 36, in <module>
     import ctypesgencore
   File
"/home/users/pok/src/builds/releasebranch_6_4/lib/python/ctypes/ctypesgencore/__init__.py",
line 52, in <module>
     import processor
ImportError: No module named 'processor'
make[5]: *** [date.py] Error 1
make[5]: Leaving directory
`/home/users/pok/src/builds/releasebranch_6_4/lib/python/ctypes'
make[4]: *** [default] Error 2
make[4]: Leaving directory
`/home/users/pok/src/builds/releasebranch_6_4/lib/python/ctypes'
make[3]: Leaving directory
`/home/users/pok/src/builds/releasebranch_6_4/lib/python'
</snip>

Changing that shebang to python2 let the build complete OK. Do you know
if there is a workaround which does not involve modyfying the source though?

But in 7.0,

I haven't mentioned I'm bulding releasebranch_6_4 actualy. Anyway, these
problems apply to 7 and 6.5 as well.

all of the shell scripts have been replaced by Python scripts, with
the shebang:

#!/usr/bin/env python

The simplest solution for this is probably to add a symlink from
$GISBASE/bin/python to the appropriate interpreter.

Thanks. I'll try that.

Maciek

--
Maciej Sieczka
http://www.sieczka.org

Glynn_Clements1 · January 3, 2013, 11:13pm

Maciej Sieczka wrote:

> The python interpreter is accessed via the make variable PYTHON, so
> you can use e.g.:
>
> make PYTHON=python2

Still one error crops out - ctypesgen.py has "#!/usr/bin/env python"
shebang, which calls Python 3.x on Arch, therefore:

Changing that shebang to python2 let the build complete OK. Do you know
if there is a workaround which does not involve modyfying the source though?

Create a directory containing a symlink from "python" to the python2
executable, than add that directory to the front of the PATH.

--
Glynn Clements <glynn@gclements.plus.com>

neteler · October 4, 2013, 8:45pm

On 1/4/13, Glynn Clements <glynn@gclements.plus.com> wrote:

Maciej Sieczka wrote:

> The python interpreter is accessed via the make variable PYTHON, so
> you can use e.g.:
>
> make PYTHON=python2

Still one error crops out - ctypesgen.py has "#!/usr/bin/env python"
shebang, which calls Python 3.x on Arch, therefore:

Changing that shebang to python2 let the build complete OK. Do you know
if there is a workaround which does not involve modyfying the source
though?

Create a directory containing a symlink from "python" to the python2
executable, than add that directory to the front of the PATH.

I am currently trying the opposite on Fedora: enforce to use Python3
in order to check for compiling errors (I was offlist contacted that
GRASS 7 is not Python3 compliant, hence I installed both interpreters
on my machine).

But I get stuck with this:

make -j4 PYTHON=python3
...
python3 -t -3 -m py_compile
/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/etc/python/grass/lib/date.py
Unknown option: -3
usage: python3 [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.

The -t -3 compatibility test checks are coded in include/Make/Python.make
and were added in http://trac.osgeo.org/grass/changeset/56821
"make: -3 parameter added to python to avoid Python 3 incompatibilities"
which is generally fine.

Solution: add a test in
include/Make/Python.make
to check if python2 or python3 are used to only apply the -3 flag in
the former case. Apparently a Python version test could be added
directly in thePython.make file, as suggested here:
http://stackoverflow.com/questions/4933285/how-to-detemine-python-version-in-makefile

Or are there other options?

Markus

Maciej_Sieczka · October 5, 2014, 1:44pm

W dniu 04.01.2013 o 00:13, Glynn Clements pisze:

Maciej Sieczka wrote:

The python interpreter is accessed via the make variable PYTHON, so
you can use e.g.:

make PYTHON=python2

Still one error crops out - ctypesgen.py has "#!/usr/bin/env python"
shebang, which calls Python 3.x on Arch, therefore:

Changing that shebang to python2 let the build complete OK. Do you know
if there is a workaround which does not involve modyfying the source though?

Create a directory containing a symlink from "python" to the python2
executable, than add that directory to the front of the PATH.

I have successfully aplied this approach (symlink `python2' in the root of releasebranch_7_0 working copy as `python', add that dir to the front of the PATH, export PATH, run `make') until recently I started getting the following error during build:

$ pwd
/home/pok/aur/grass70-svn/src/grass70-svn/gui/wxpython/iclass

$ make
make /home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/docs/html/g.gui.iclass.html
make[1]: Entering directory '/home/pok/aur/grass70-svn/src/grass70-svn/gui/wxpython/iclass'
GISRC=/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc70 GISBASE=/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu PATH="/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/bin:/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/bin:/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/scripts:$PATH" PYTHONPATH="/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/etc/python:/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/gui/wxpython:$PYTHONPATH" LD_LIBRARY_PATH="/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/bin:/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/scripts:/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/lib:/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/lib:" LC_ALL=C /home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/scripts/g.gui.iclass --html-description < /dev/null | grep -v '</body>\|</html>' > g.gui.iclass.tmp.html
Traceback (most recent call last):
File "/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/scripts/g.gui.iclass", line 54, in <module>
import wx
ImportError: No module named 'wx'
../../../include/Make/GuiScript.make:36: recipe for target 'g.gui.iclass.tmp.html' failed
make[1]: *** [g.gui.iclass.tmp.html] Error 1
rm g.gui.iclass.tmp.html
make[1]: Leaving directory '/home/pok/aur/grass70-svn/src/grass70-svn/gui/wxpython/iclass'
../../../include/Make/GuiScript.make:22: recipe for target 'guiscript' failed
make: *** [guiscript] Error 2

I can `import wx' without issue on `python2' shell, but not on `python3' shell, so it seems to me the error above is due to Python 3 being used instead of Python 2, in spite of the symlink "hack".

Every other GRASS 7 Python thing builds fine though. Why is iclass build trying to use Python 3? How should deal with this, the least intrusive way?

Maciek

--
Maciej Sieczka
http://www.sieczka.org

Maciej_Sieczka · October 7, 2014, 8:57pm

W dniu 05.10.2014 o 15:44, Maciej Sieczka pisze:

W dniu 04.01.2013 o 00:13, Glynn Clements pisze:

Maciej Sieczka wrote:

The python interpreter is accessed via the make variable PYTHON, so
you can use e.g.:

make PYTHON=python2

Still one error crops out - ctypesgen.py has "#!/usr/bin/env python"
shebang, which calls Python 3.x on Arch, therefore:

Changing that shebang to python2 let the build complete OK. Do you know
if there is a workaround which does not involve modyfying the source
though?

Create a directory containing a symlink from "python" to the python2
executable, than add that directory to the front of the PATH.

I have successfully aplied this approach (symlink `python2' in the root
of releasebranch_7_0 working copy as `python', add that dir to the front
of the PATH, export PATH, run `make') until recently I started getting
the following error during build:

$ pwd
/home/pok/aur/grass70-svn/src/grass70-svn/gui/wxpython/iclass

$ make
make

Please ignore that make log. An excerpt with issues from the proper make log is as follows:

---
make[5]: Entering directory '/home/pok/aur/grass70-svn/src/grass70-svn/gui/wxpython/iclass'
/usr/bin/install -c g.gui.iclass.py /home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/scripts/g.gui.iclass
/usr/bin/install -c -m 644 iclass_frame.jpg /home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/docs/html/iclass_frame.jpg
make /home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/docs/html/g.gui.iclass.html
make[6]: Entering directory '/home/pok/aur/grass70-svn/src/grass70-svn/gui/wxpython/iclass'
GISRC=/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc70 GISBASE=/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu PATH="/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/bin:/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/bin:/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/scripts:$PATH" PYTHONPATH="/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/etc/python:/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/gui/wxpython:$PYTHONPATH" LD_LIBRARY_PATH="/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/bin:/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/scripts:/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/lib:/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/lib:" LC_ALL=C /home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/scripts/g.gui.iclass --html-description < /dev/null | grep -v '</body>\|</html>' > g.gui.iclass.tmp.html
Traceback (most recent call last):
   File "/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/scripts/g.gui.iclass", line 62, in <module>
     from iclass.frame import IClassMapFrame
   File "/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/gui/wxpython/iclass/frame.py", line 61, in <module>
     from iclass.plots import PlotPanel
   File "/home/pok/aur/grass70-svn/src/grass70-svn/dist.x86_64-unknown-linux-gnu/gui/wxpython/iclass/plots.py", line 19, in <module>
     import wx.lib.plot as plot
   File "/usr/lib/python2.7/site-packages/wx-3.0-gtk2/wx/lib/plot.py", line 126, in <module>
     raise ImportError, "NumPy not found.\n" + msg
ImportError: NumPy not found.

     This module requires the NumPy module, which could not be
     imported. It probably is not installed (it's not part of the
     standard Python distribution). See the Numeric Python site
     (http://numpy.scipy.org) for information on downloading source or
     binaries.
../../../include/Make/GuiScript.make:36: recipe for target 'g.gui.iclass.tmp.html' failed
make[6]: *** [g.gui.iclass.tmp.html] Error 1
rm g.gui.iclass.tmp.html
make[6]: Leaving directory '/home/pok/aur/grass70-svn/src/grass70-svn/gui/wxpython/iclass'
../../../include/Make/GuiScript.make:22: recipe for target 'guiscript' failed
make[5]: *** [guiscript] Error 2
make[5]: Leaving directory '/home/pok/aur/grass70-svn/src/grass70-svn/gui/wxpython/iclass'
---

The configure was:

     --with-cxx \
     --with-cairo \
     --with-freetype \
     --with-freetype-includes=/usr/include/freetype2 \
     --with-geos \
     --with-liblas \
     --with-nls \
     --with-netcdf \
     --with-odbc \
     --with-openmp \
     --with-postgres \
     --with-python=/usr/bin/python2-config \
     --with-readline \
     --with-proj-includes=/usr/include \
     --with-proj-libs=/usr/lib \
     --with-proj-share=/usr/share/proj \
     --with-pthread \
     --with-sqlite \
     --with-wxwidgets=/usr/bin/wx-config-2.8

Per 2.8 wxWidgets specified, I don't get it why /usr/lib/python2.7/site-packages/wx-3.0-gtk2/ gets involved in iclass build. I would rather expect it to pick /usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/. Some details:

---
$ /usr/bin/wx-config-2.8 --libs
-pthread -Wl,-O1,--sort-common,--as-needed,-z,relro -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8

$ /usr/bin/wx-config-2.8 --list

Default config is gtk2-unicode-release-2.8

Default config will be used for output

Also available in /usr:
gtk2-unicode-3.0
---

What do you make of this? Like I said, all the other Python bits seem to build fine. Only iclass doesn't. I'm attaching a complete build log if you want to look inside.

This is an Arch box. I do have all the NumPy stuff installed. There is a problem on Arch that wx-3.0-gtk2/wx/lib/plot.py fails to import numpy.oldnumeric [1] leading to those "NumPy not found" errors, but that would not happen if iclass build referred to wx-2.8-gtk2-unicode/wx/lib/plot.py instead - like I guess all the other GRASS 7 Python modules do.

Any helpfull thoughts or questions are most welcome.

[1] https://bugs.archlinux.org/task/42054?string=wxpython&project=1&type[0]=&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=open&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto=

Maciek

--
Maciej Sieczka
http://www.sieczka.org

(attachments)

grass70-svn-62209-1-x86_64-build.log.tar.bz2 (110 KB)

wenzeslaus · October 8, 2014, 12:58am

I don’t know much but I will try to tell what I know.

On Tue, Oct 7, 2014 at 4:57 PM, Maciej Sieczka <msieczka@sieczka.org> wrote:

–with-wxwidgets=/usr/bin/wx-config-2.8

Per 2.8 wxWidgets specified, I don’t get it why
/usr/lib/python2.7/site-packages/wx-3.0-gtk2/ gets
involved in iclass build. I would rather expect it to
pick /usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/.

As far as I know, this does not select the Python packages but C++ library to link to for the C++ things which are using wxWidgets (no Python things which are using wxPython).

What do you make of this? Like I said, all the other Python bits seem to build fine. Only iclass doesn’t.

I think it is only g.gui.iclass because just this module is importing something from wx which fails. The other g.gui.* modules (and a toolbox script) also import wx during compilation but this does not fail.

This is an Arch box. I do have all the NumPy stuff installed. There is a problem on Arch that wx-3.0-gtk2/wx/lib/plot.py fails to import numpy.oldnumeric [1] leading to those “NumPy not found” errors,

I hope that the upstream error gets fixed because the GRASS one is more mysterious.

but that would not happen if iclass build referred to wx-2.8-gtk2-unicode/wx/lib/plot.py instead - like I guess all the other GRASS 7 Python modules do.

Yes, there is this mysterious issue where wrong versions of wxPython or perhaps other things are used during compilation when something runs in fake GRASS session. The things usually run in the real GRASS session, you can try.

Glynn_Clements1 · October 8, 2014, 11:04am

Maciej Sieczka wrote:

--with-wxwidgets=/usr/bin/wx-config-2.8

Per 2.8 wxWidgets specified, I don't get it why
/usr/lib/python2.7/site-packages/wx-3.0-gtk2/ gets involved in iclass
build. I would rather expect it to pick
/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/. Some details:

--with-wxwidgets only affects compiled (C/C++) code which links
against the wxWidges libraries. In 7.0, this means the wximgview
module (visualization/wximgview) and nothing else. It doesn't affect
wxGUI.

In theory, code which uses the wxPython library is supposed to use
something like:

  import wxversion
  wxversion.select('2.8')
  import wx

to ensure that the correct version is used when there are multiple
versions present on the system.

This is an Arch box. I do have all the NumPy stuff installed. There is a
problem on Arch that wx-3.0-gtk2/wx/lib/plot.py fails to import
numpy.oldnumeric [1] leading to those "NumPy not found" errors, but that
would not happen if iclass build referred to
wx-2.8-gtk2-unicode/wx/lib/plot.py instead - like I guess all the other
GRASS 7 Python modules do.

Maybe everything is using wx-3.0, but only iclass is using the broken
plots.py functionality?

If you can run some other g.gui.* module, you can check which
libraries it's actually using with "cat /proc/<pid>/maps", where <pid>
is the PID of the g.gui.* process.

--
Glynn Clements <glynn@gclements.plus.com>

Maciej_Sieczka · October 8, 2014, 7:31pm

W dniu 08.10.2014 o 13:04, Glynn Clements pisze:

Maciej Sieczka wrote:

      --with-wxwidgets=/usr/bin/wx-config-2.8

Per 2.8 wxWidgets specified, I don't get it why
/usr/lib/python2.7/site-packages/wx-3.0-gtk2/ gets involved in iclass
build. I would rather expect it to pick
/usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/. Some details:

--with-wxwidgets only affects compiled (C/C++) code which links
against the wxWidges libraries. In 7.0, this means the wximgview
module (visualization/wximgview) and nothing else. It doesn't affect
wxGUI.

In theory, code which uses the wxPython library is supposed to use
something like:

  import wxversion
  wxversion.select('2.8')
  import wx

to ensure that the correct version is used when there are multiple
versions present on the system.

This is an Arch box. I do have all the NumPy stuff installed. There is a
problem on Arch that wx-3.0-gtk2/wx/lib/plot.py fails to import
numpy.oldnumeric [1] leading to those "NumPy not found" errors, but that
would not happen if iclass build referred to
wx-2.8-gtk2-unicode/wx/lib/plot.py instead - like I guess all the other
GRASS 7 Python modules do.

Maybe everything is using wx-3.0, but only iclass is using the broken
plots.py functionality?

If you can run some other g.gui.* module, you can check which
libraries it's actually using with "cat /proc/<pid>/maps", where <pid>
is the PID of the g.gui.* process.

Indeed!

I patched iclass/g.gui.iclass.py with "wxversion.select('2.8')", just to let a full GRASS 7 build complete without errors, and actually every g.gui.* module except iclass is using wx-3.0-gtk2...

Is using a mix of wxPython 2.8 and 3.0 like this going to pose any usage problems in core GRASS or plugins?

Could GRASS offer a mechanism to enforce a specific wxPython version throughout all of GRASS build and run time? Or how to hack it in a more elegant way than patching those ~140 *.py files which import wx?

I can't just uninstall wxpython (which provides the problematic wx-3.0-gtk2), because wxpython-2.8 (providing an OK wx-2.8-gtk2-unicode) depends on it...

Maciek

--
Maciej Sieczka
http://www.sieczka.org

Glynn_Clements1 · October 9, 2014, 12:56pm

Maciej Sieczka wrote:

Is using a mix of wxPython 2.8 and 3.0 like this going to pose any usage
problems in core GRASS or plugins?

Probably not. Using different versions in different processes won't
matter. And if one module imports another, I believe that the module
which actually loads wx (i.e. the first one to execute "import wx")
will determine the version; subsequent "import wx" statements will use
the already-loaded version.

Could GRASS offer a mechanism to enforce a specific wxPython version
throughout all of GRASS build and run time? Or how to hack it in a more
elegant way than patching those ~140 *.py files which import wx?

One option would be to replace "import wx" with "import grass.wx",
where the grass.wx module is just

wxversion.select('2.8')
from wx import *

The other option is to only add wxversion.select() to top-level
modules, i.e. those which are executed as scripts rather than imported
as modules.

--
Glynn Clements <glynn@gclements.plus.com>

Maciej_Sieczka · October 9, 2014, 6:42pm

W dniu 09.10.2014 o 14:56, Glynn Clements pisze:

Maciej Sieczka wrote:

Is using a mix of wxPython 2.8 and 3.0 like this going to pose any usage
problems in core GRASS or plugins?

Probably not. Using different versions in different processes won't
matter. And if one module imports another, I believe that the module
which actually loads wx (i.e. the first one to execute "import wx")
will determine the version; subsequent "import wx" statements will use
the already-loaded version.

Could GRASS offer a mechanism to enforce a specific wxPython version
throughout all of GRASS build and run time? Or how to hack it in a more
elegant way than patching those ~140 *.py files which import wx?

One option would be to replace "import wx" with "import grass.wx",
where the grass.wx module is just

wxversion.select('2.8')
from wx import *

The other option is to only add wxversion.select() to top-level
modules, i.e. those which are executed as scripts rather than imported
as modules.

Got it. Thank you, Glynn. I will better try to get Arch FS#42054 fixed 1st.

Maciek

--
Maciej Sieczka
http://www.sieczka.org