fun with wxPython

[Mojca Miklavec]

Hi,

I have been playing with wxWidgets ports recently. (I did a few stupid
mistakes, but I hope these can be forgotten ;)

I upgraded wxWidgets-devel to 2.9.5 (wxWidgets30 has been upgraded
short before that) which broke py-wxpython-devel (and py-wxpython30)
because wxPython is still at version 2.9.4.

The ports currently are a mess and there are several reasons for that,
but here's a short summary of what's going on with wxPython ports.

wxPython contains more or less original wxWidgets + some python
support. Forgetting wxmsw, the following "base" ports are present in
MacPorts, all conflictling with each other:

- x11/wxgtk                 {nomaintainer}
- graphics/wxWidgets        {jwa}
- graphics/wxWidgets-devel  {jwa}
- graphics/wxWidgets30      {jwa}
- graphics/wxWidgets-python {nomaintainer}

wxWidgets-devel and wxWidgets30 are the same (wxWidgets-devel should
be removed), wxgtk is very similar to wxWidgets, except that it uses
gtk instead of carbon (I've seen claims that wxgtk should be removed
and gtk option should be added to wxWidgets). wxWidgets-python is
almost the same as wxWidgets, except for two differences: (1) it
offers gtk option (and can probably be compiled on systems > 10.6
since it doesn't depend on Carbon) and (2) it's compiled from wxPython
sources.

Then there are bunch of wxpython ports:

- py-wxpython {nomaintainer}
  > py-wxpython at 2.8.12.1
  > py24-wxpython at 2.8.12.1  [python24, wxWidgets]
  > py25-wxpython at 2.8.12.1  [python25, wxWidgets]
  > py27-wxpython at 2.8.12.1  [python27, wxWidgets]
- py26-wxpython {jameskyle}
  > py26-wxpython at 2.8.10.1  [python26, wxWidgets-python]
- py-wxpython30 {jwa}
  > py-wxpython30  @2.9.4.9 [py27-wxpython30]
  > py27-wxpython30 at 2.9.4.0 [python27, wxWidgets30]
- py27-wxpython-devel {jwa}
  > py27-wxpython-devel at 2.9.4.9 [wxWidgets30]

The first is the port name, in subsequent lines are the subport names
and dependencies are in square brackets.

All ports depend on wxWidgets/wxWidgets30/wxWidgets-devel, except for
py26-wxpython which depends on wxWidgets-python instead (conflicting
with wxWidgets).

The ports py*-wxpython* fetch wxPython sources (the same as
wxWidgets-python port), but only install the contents of wxPython
subdir. (wxWidgets-python installs everything except for wxPython
subdir from the same source files.)

There is hardly any difference in py-wxpython30 and
py27-wxpython-devel (the latter should be removed).

I don't believe there is any substantial difference in py26-wxpython
and py27-wxpython tied to the version of python. What I believe has
happened is that at the time when Python 2.6 was "current",
py26-wxpython has been created to solve a number of problems (see
ticket https://trac.macports.org/ticket/24350), but then this idea
wasn't pursued further and py27-wxpython used the old strategy again.

There is only a small number of ports that depends on pyXY-wxpython. I
have found the following:

- py-dsv                 [pyXY-wxpython]       {nomaintainer}
- py-pyface              [pyXY-wxpython]       {gmail.com:jjstickel
openmaintainer}
- py-robotframework-ride [pyXY-wxpython(30)]   {jwa}
- py-winpdb              [pyXY-wxpython-devel] {eborisch}
- py26-pyphant           [py26-wxpython & ...]
{fmf.uni-freiburg.de:klaus.zimmermann, rowue}


My initial idea was to allow side-by-side installation of wxWidgets
2.8 and 2.9 which could solve a number of problems, but all the ports
depending on wxWidgets need to be adapted first, so there's some way
to go to make this a reality. After discussing with other developers,
many seem to agree that the name wxWidgets-3.0 sounds better than
wxWidgets30, like it's already the case for clang-X.Y or llvm-X.Y. (I
don't know what the policy about uppercase names is, that is: whether
it makes more sense to have "wxwidgets-3.0" or "wxWidgets-3.0" and
"wxPython" or "wxpython", since there is already py-wxpython.)

I committed some draft portfiles for wxWidgets-2.8 and wxWidgets3.0 to
    http://trac.macports.org/browser/users/mojca/wxports
(keeping all attachments to a ticket up to date would be too confusing).

Yesterday I started looking into the wxPython mess. That one should
actually be a lot easier to solve because only py*-wxpython* needs to
be adapted and all ports depending on py*-wxpython* should work
out-of-the-box (if properly implemented).

My main thought about wxPython is the following: because wxPython
often lags behind, it makes no sense that wxWidgets upgrade needs to
wait forever for a new wxPython release, so why wouldn't one also
instal wxPython in a way that doesn't conflict with wxWidgets. Then
py*-wxpython* ports become independent of wxWidgets core and there is
no need for downgrades of wxWidgets while waiting for wxPython
release.

In my user repository mentioned above I have committed two ports
wxPython-3.0 and py-wxpython-3.0 (the idea would be to add
wxPython-2.8 and py-wxpython-2.8, but I don't have Mac OS X 10.6 at
hand at the moment for testing). wxPython-3.0 now installs files to
    ${frameworks_dir}/wxWidgets.framework/Versions/wxPython/2.9
It's not a framework in the proper sense (even though it could
probably be made into a proper framework with some work), but I needed
to pick a place where files could be installed side-by-side.

And py-wxpython-3.0 picks the files from there.

There are a few problems left:
(1) wxrc-2.9 links against libraries in the build dir (probably a bug
in makefiles, fixed in Portfile, but it needs a cleaner fix)
- if wxWidgets is already installed, files would link against, say,
    /opt/local/lib/libwx_baseu-2.9.5.0.0.dylib
instead of
    /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxPython/2.9/lib/libwx_baseu-2.9.4.0.0.dylib
I'm not yet sure how to solve that problem other than making sure that
all wxWidgets ports are deactivated while building wxPython.

I tested py-winpdb and a random hello-world wxPython script and they
seem to work fine. Another port had some minor problem.

I would be grateful for feedback and comments.

Mojca