Arch Linux

And where should it be installed?

i was a little bit to fast with my assumption. it looks like there is no wxpython for python3 right now.

But it is very confusing to me (and also others see: https://bbs.archlinux.org/viewtopic.php?id=191890) that a python2 module is labeled just as wxpython, why is it not named like all the other python libraries?

e.g.:

extra/python-numpy 1.10.2-1
Scientific tools for Python

extra/python2-numpy 1.10.2-1 [installed]
Scientific tools for Python

i would suggest to rename the package to python2-wxpython so people will not start to wonder why it is not available under python3/site-packages.

It is not much work to rename it, it has only a few dependencies.

Well I’ll rather wait for wxpython 4.0 to be released (b2 was out in September), which supports python3 and hopefully will be supported by all depending apps.

wxpython 4.0 is out for one month now, but it is not fully backward compatible with wxpython 3.0. I’m not sure what the best way to handle this is… Maybe we can change wxpython to python2-wxgtk and publish wxpython 4.0 as python3-wxgtk aside.

However I’m not sure whether they are any wxpython app compatible with 4.0 at the moment.

people will start using it when it's available and when they have to change the dependency they maybe will think about migrating it to 4.0 too

Upstream for Printrun (currently on AUR[1]) has released a RC[2] which uses wxpython 4+python3. It previously was python2. I was going to try to get the package updated for the RC so things would be ready for the final release, but that does require wxpython 4 to be available, it seems.

1. https://aur.archlinux.org/packages/printrun/
2. https://github.com/kliment/Printrun/releases/tag/printrun-2.0.0rc3

I think we should provide two packages:

- python2-wxpython3: it provides the classic wxPython 3 for a long time for the existing applications.

- python-wxpython: it provides the new wxPython 4 for applications which want to port to Python 3.

We should not provide wxPython 4 for Python 2, because it would conflict with wxPython 3. Old applications should port to wxPython 4 and Python 3 at the same time.

We could still provide wxpython4 for py2, but that would depend on us having repo packages that use it.

Aside for that this seems a reasonable solution.

What do we do about binaries in `/usr/bin`:
– Current:
```
wxpython /usr/bin/editra
wxpython /usr/bin/helpviewer
wxpython /usr/bin/img2png
wxpython /usr/bin/img2py
wxpython /usr/bin/img2xpm
wxpython /usr/bin/pyalacarte
wxpython /usr/bin/pyalamode
wxpython /usr/bin/pycrust
wxpython /usr/bin/pyshell
wxpython /usr/bin/pywrap
wxpython /usr/bin/pywxrc
wxpython /usr/bin/xrced
```
–My 4.0 build:

```
wxpython /usr/bin/helpviewer
wxpython /usr/bin/img2png
wxpython /usr/bin/img2py
wxpython /usr/bin/img2xpm
wxpython /usr/bin/pycrust
wxpython /usr/bin/pyshell
wxpython /usr/bin/pyslices
wxpython /usr/bin/pyslicesshell
wxpython /usr/bin/pywxrc
wxpython /usr/bin/wxdemo
wxpython /usr/bin/wxdocs
wxpython /usr/bin/wxget
```

Also, Eli, there would be a conflict between wxpython4 for py2 and wxpython3 for py2.

We can add a '2' suffix for binaries in the python 2 package. Many python packages do this, hopefully it won't break anything. So the binaries in the python2-wxpython3 package will be:
/usr/bin/editra2
/usr/bin/helpviewer2
/usr/bin/img2png2
/usr/bin/img2py2
/usr/bin/img2xpm2
/usr/bin/pyalacarte2
/usr/bin/pyalamode2
/usr/bin/pycrust2
/usr/bin/pyshell2
/usr/bin/pywrap2
/usr/bin/pywxrc2
/usr/bin/xrced2

Yes this seems to be common to append '2' for python 2 package:

compare:
https://www.archlinux.org/packages/community/any/python-cherrypy/
https://www.archlinux.org/packages/community/any/python2-cherrypy/

or

https://www.archlinux.org/packages/extra/any/python2-django/