Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#47448 - [wxpython] package should be renamed

Attached to Project: Community Packages
Opened by Florijan Hamzic (cin) - Saturday, 19 December 2015, 19:43 GMT
Last edited by Balló György (City-busz) - Saturday, 07 April 2018, 14:45 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Eric Belanger (Snowman)
Balló György (City-busz)
Bruno Pagani (ArchangeGabriel)
Architecture x86_64
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


It's installed in the wrong directoryy -.-

Additional info:
extra/wxpython [installed]
A wxWidgets GUI toolkit for Python

Steps to reproduce:
install wxpython and check files with pacman -Qql wxpython
This task depends upon

Closed by  Balló György (City-busz)
Saturday, 07 April 2018, 14:45 GMT
Reason for closing:  Implemented
Additional comments about closing:  python-wxpython 4.0.1-1 and python2-wxpython3
Comment by Doug Newgard (Scimmia) - Saturday, 19 December 2015, 21:51 GMT
And where should it be installed?
Comment by Florijan Hamzic (cin) - Sunday, 20 December 2015, 05:20 GMT
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: that a python2 module is labeled just as wxpython, why is it not named like all the other python libraries?


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.
Comment by Bruno Pagani (ArchangeGabriel) - Friday, 26 January 2018, 16:30 GMT
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.
Comment by Bruno Pagani (ArchangeGabriel) - Tuesday, 06 March 2018, 22:23 GMT
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.
Comment by Florijan Hamzic (cin) - Tuesday, 06 March 2018, 23:16 GMT
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
Comment by Eric Anderson (ejona86) - Wednesday, 21 March 2018, 14:23 GMT
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.

Comment by Balló György (City-busz) - Sunday, 25 March 2018, 16:35 GMT
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.
Comment by Eli Schwartz (eschwartz) - Sunday, 25 March 2018, 18:15 GMT
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.
Comment by Bruno Pagani (ArchangeGabriel) - Tuesday, 27 March 2018, 07:34 GMT
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
Comment by Bruno Pagani (ArchangeGabriel) - Tuesday, 27 March 2018, 07:35 GMT
Also, Eli, there would be a conflict between wxpython4 for py2 and wxpython3 for py2.
Comment by Balló György (City-busz) - Tuesday, 27 March 2018, 07:44 GMT
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:
Comment by Florijan Hamzic (cin) - Tuesday, 27 March 2018, 08:15 GMT