Ports depending on wxWidgets* or wxPython should be ported to wxWidgets-3.0 or provide variants

[cooljeanius (Eric Gallager)]

I'm hijacking this ticket to request review of modifications I did in browser:users/mojca/wxports by individual port maintainers. (While I did not change all the ports yet - in particular the dependencies of wxPython 2.8 need some testing to see whether they are compatible with 2.9, the majority is done, I'll reply below with the exact status report.)

Because all ports need to be updated simultaneously, any ports that won't receive any feedback by the maintainers will be considered as "maintainer timeout" and committed (or broken), so please make sure that your ports still work after these changes and feel free to suggest improvements/modifications, in particular regarding option names. Please also check that I properly increased the version and/or revision.

Feel free to commit to my branch directly.

wxWidgets dependencies

port	required (option name)	maintainer(s)
wxWidgets 2.9:
aqua/pgAdmin3	YES	jwa
devel/poedit	YES	raimue openmaintainer
gis/grass	NO wxwidgets	nomaintainer
math/gnuplot	NO wxwidgets	mojca openmaintainer
-> perl/p5-graphics-gnuplotif		nomaintainer
math/wxMaxima	YES	usami-k openmaintainer
multimedia/mkvtoolnix	NO wxwidgets	nomaintainer
perl/p5-alien-wxwidgets	YES	nomaintainer
-> perl/p5-wx		nomaintainer
science/gnuradio	NO wxgui	michaelld openmaintainer
science/plplot	NO wxWidgets	takeshi openmaintainer
portable to wxWidgets 2.9:
cross/usbprog	YES	macports lilalinux.net
graphics/hugin-app	YES	nomaintainer
lang/erlang	NO wxwidgets	bfulgham
-> graphics/esdl		bfulgham
math/fityk	YES	nomaintainer
x11/xcmh	YES aqua/x11	markd
conditionally portable to wxWidgets 2.9:
www/FileZilla	YES	rudloff strasweb.fr, openmaintainer
wxWidgets 2.8 only:
devel/wxd	YES	usami-k, openmaintainer
devel/codeblocks	YES aqua/x11	afb
devel/wxstedit	YES aqua/x11	afb
-> graphics/wxLua		afb
emulators/lisaem	YES	ryandesign
graphics/rt-volume-rendering	YES	bugcutt gmail.com
security/otrproxy	YES	nomaintainer

wxPython dependencies

port	dependency	maintainer(s)
wxPython 2.8:
editors/spe	py26-wxpython	nomaintainer
net/bittorrent	py25-wxpython	nomaintainer
python/py-dsv	py2*-wxpython	nomaintainer
python/py-pyface (optional)	py2*-wxpython	jjstickel gmail.com, openmaintainer
python/py26-pyphant	py26-wxpython	klaus.zimmermann fmf.uni-freiburg.de, rowue
wxPython 2.9:
gis/grass	py27-wxpython30	nomaintainer
python/py-winpdb	py2*-wxpython-devel	eborisch, openmaintainer
python/py-robotframework-ride	py2*-wxpython(30)	jwa
science/gnuradio	py2*-wxpython-devel	michaelld, openmaintainer
science/relax	py27-wxpython-devel	howarth bromo.med.uc.edu
science/stimfit	py27-wxpython30	christsc gmx.de
commented out/disabled:
games/sounddecompress	py26-wxpython	ryandesign

[ryandesign (Ryan Carsten Schmidt)]

The wxWidgets situation in MacPorts is basically a disaster, which is mostly the fault of the developers of wxWidgets for not releasing a 64-bit compatible version, 3.0, which they've needed to do since the release of Snow Leopard 3.5 years ago already, and partly the fault of MacPorts maintainers for introducing so many different wxWidgets ports with conflicting naming styles and unclear differentiation between them.

I've ​suggested before, and ​continue to recommend, in as far as I understand wxWidgets at all, that the existing wxWidgets ports be deprecated in favor of new versioned ports, e.g. wxWidgets28 and wxWidgets30. This hasn't really been accomplished yet. See also #37819.

I would not hold up poedit as an example of how to handle the wxWidgets dependency correctly; on the contrary I find its method convoluted and bizarre.

[afb@…]

It has always been MacPorts problem that it chose to name wxMac as "wxWidgets", but still also provide "wxgtk"...

As for Code::Blocks it requires wxMac, so the only way to build 64-bit is to use wxGTK or to contribute upstream.

[cooljeanius (Eric Gallager)]

Replying to ryandesign@…:

I would not hold up poedit as an example of how to handle the wxWidgets dependency correctly; on the contrary I find its method convoluted and bizarre.

Sure, its method might be convoluted and bizarre, but sometimes that's what's necessary to provide desired functionality (in this case, compatibility with multiple versions of wxWidgets).

[larryv (Lawrence Velázquez)]

Replying to egall@…:

Sure, its method might be convoluted and bizarre, but sometimes that's what's necessary to provide desired functionality (in this case, compatibility with multiple versions of wxWidgets).

The wxWidgets situation should probably be sorted out first.

[mojca (Mojca Miklavec)]

Cc Me!

[cooljeanius (Eric Gallager)]

r105726 added wxWidgets30 compatibility to gnuplot (I'd count that as a step towards working towards fixing this ticket)

[cooljeanius (Eric Gallager)]

Replying to egall@…:

r105726 added wxWidgets30 compatibility to gnuplot (I'd count that as a step towards working towards fixing this ticket)

Same with r105900 which closed #37344

[mojca (Mojca Miklavec)]

Here are some of my thoughts:

1. The majority of this mess is there just because wxWidgets 2.8 and 2.9 are not allowed to coexist. Many ports like gnuplot could simply default to 2.9, but they cannot because the port cannot demand using by default a package (wxWidgets 2.9) that conflicts with dependencies of another package, say codeblocks (which depends on 2.8). If versions 2.8 and 2.9 could coexist, life would be *a lot* easier. See my ticket #39807. My belief is that once a clear separation is done and conflict is removed, it will become a lot easier for port maintainers to add proper variants (and to implement variants properly). Let's solve that issue first.

2. I believe that we need a way to quickly find all ports that depend on any wxWidgets version. This is particularly important when doing major changes on wxWidgets naming scheme, when introducing and testing new versions of wxWidgets (for example when version 3.0 will be out), when doing revbumps, ... What do you think of adding PortGroup wxWidgets 1.0 to every such port, even if the group doesn't do anything useful yet?

3. We need consistent naming scheme for wx variants and consistent behaviour across the ports, taking into account that:
   1. There are ports that require wxWidgets and there are ports where wxWidgets are simply optional (gnuplot).
   2. There are ports that only work with one version, but not the other (only 2.8, only 2.9) and those that work with both. Also some that work with wxgtk (on freebsd).
   3. In most cases it probably isn't relevant which wxWidgets the port depends on, but in some cases it might be desirable to support both, at least for testing purposes.
   4. While we could probably focus on 2.9/3.0 now and only depend on 2.8 for ports that don't work with 2.9, we need to be prepared for the arrival of 3.2 with the naming scheme & naming strategy. Maybe even for 3.0-devel and alike ;)
   5. Version 2.8 doesn't work on 10.8(?) and doesn't allow building 64-bit binaries. Version 2.9/3.0 requires at least 10.5 (but probably 10.4 is not really supported any more?).
   6. Some ports already do some more or less advanced magic to use the "right" version of wxWidgets and special care is needed to "translate" those options properly.

4. We need to write some guidelines for maintainers of ports which depend on wxWidgets. This is not a priority, but I believe that it needs to be done at some point.

5. The path-style dependencies shouldn't be used because wxWidgets 2.8 and 2.9 are incompatible with each other (path-style can be used with released and development version that are closely related).

6. In my opinion this transition needs to happen before the official 3.0 release, to leave enough time for bugfixing and reporting bugs upstream.

7. I wouldn't force changing ports until (1) is done and (3) is clear/well-defined.

I don't know if the following is a good idea, but something non-intrusive like the following could be put into each port that depends on wxWidgets just to mark where the work needs to be done:

PortGroup wxWidgets 1.0

# which versions of wxWidgets are supported
# add comments whether it's known (not) to work or just hasn't been implemented/tested yet
wxwidgets.version  28 30
# or wxwidgets.compatibility

# for ports like gnuplot
wxwidgets.optional  yes

[cooljeanius (Eric Gallager)]

Replying to mojca@…:

1. The majority of this mess is there just because wxWidgets 2.8 and 2.9 are not allowed to coexist. Many ports like gnuplot could simply default to 2.9, but they cannot because the port cannot demand using by default a package (wxWidgets 2.9) that conflicts with dependencies of another package, say codeblocks (which depends on 2.8). If versions 2.8 and 2.9 could coexist, life would be *a lot* easier. See my ticket #39807. My belief is that once a clear separation is done and conflict is removed, it will become a lot easier for port maintainers to add proper variants (and to implement variants properly). Let's solve that issue first.

Agreed, making them not conflict would be a good idea.

2. I believe that we need a way to quickly find all ports that depend on any wxWidgets version. This is particularly important when doing major changes on wxWidgets naming scheme, when introducing and testing new versions of wxWidgets (for example when version 3.0 will be out), when doing revbumps, ... What do you think of adding PortGroup wxWidgets 1.0 to every such port, even if the group doesn't do anything useful yet?

The group would have to actually exist first though, wouldn't it? Regardless of whether it actually does anything useful yet?

3. We need consistent naming scheme for wx variants and consistent behaviour across the ports, taking into account that:
   1. There are ports that require wxWidgets and there are ports where wxWidgets are simply optional (gnuplot).
   2. There are ports that only work with one version, but not the other (only 2.8, only 2.9) and those that work with both. Also some that work with wxgtk (on freebsd).
   3. In most cases it probably isn't relevant which wxWidgets the port depends on, but in some cases it might be desirable to support both, at least for testing purposes.
   4. While we could probably focus on 2.9/3.0 now and only depend on 2.8 for ports that don't work with 2.9, we need to be prepared for the arrival of 3.2 with the naming scheme & naming strategy. Maybe even for 3.0-devel and alike ;)
   5. Version 2.8 doesn't work on 10.8(?) and doesn't allow building 64-bit binaries. Version 2.9/3.0 requires at least 10.5 (but probably 10.4 is not really supported any more?).
   6. Some ports already do some more or less advanced magic to use the "right" version of wxWidgets and special care is needed to "translate" those options properly.

Gah, that's confusing...

4. We need to write some guidelines for maintainers of ports which depend on wxWidgets. This is not a priority, but I believe that it needs to be done at some point.

Implementing the naming scheme mentioned above would require some sort of guidelines to make sure that people follow the naming scheme.

5. The path-style dependencies shouldn't be used because wxWidgets 2.8 and 2.9 are incompatible with each other (path-style can be used with released and development version that are closely related).

OK, I was just throwing ideas out there...

6. In my opinion this transition needs to happen before the official 3.0 release, to leave enough time for bugfixing and reporting bugs upstream.

When is that supposed to be done?

7. I wouldn't force changing ports until (1) is done and (3) is clear/well-defined.

What do you mean by "force" here?

I don't know if the following is a good idea, but something non-intrusive like the following could be put into each port that depends on wxWidgets just to mark where the work needs to be done:

PortGroup wxWidgets 1.0

# which versions of wxWidgets are supported
# add comments whether it's known (not) to work or just hasn't been implemented/tested yet
wxwidgets.version  28 30
# or wxwidgets.compatibility

# for ports like gnuplot
wxwidgets.optional  yes

Go for it. Actually write the PortGroup first though.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca@…:

1. The majority of this mess is there just because wxWidgets 2.8 and 2.9 are not allowed to coexist.

Correct. This should be fixed.

2. I believe that we need a way to quickly find all ports that depend on any wxWidgets version. This is particularly important when doing major changes on wxWidgets naming scheme, when introducing and testing new versions of wxWidgets (for example when version 3.0 will be out), when doing revbumps, ... What do you think of adding PortGroup wxWidgets 1.0 to every such port, even if the group doesn't do anything useful yet?

Why? You can use grep to identify those ports already.

3. We need consistent naming scheme for wx variants and consistent behaviour across the ports, taking into account that:
   1. There are ports that require wxWidgets and there are ports where wxWidgets are simply optional (gnuplot).
   2. There are ports that only work with one version, but not the other (only 2.8, only 2.9) and those that work with both. Also some that work with wxgtk (on freebsd).
   3. In most cases it probably isn't relevant which wxWidgets the port depends on, but in some cases it might be desirable to support both, at least for testing purposes.
   4. While we could probably focus on 2.9/3.0 now and only depend on 2.8 for ports that don't work with 2.9, we need to be prepared for the arrival of 3.2 with the naming scheme & naming strategy. Maybe even for 3.0-devel and alike ;)
   5. Version 2.8 doesn't work on 10.8(?) and doesn't allow building 64-bit binaries. Version 2.9/3.0 requires at least 10.5 (but probably 10.4 is not really supported any more?).
   6. Some ports already do some more or less advanced magic to use the "right" version of wxWidgets and special care is needed to "translate" those options properly.

I've gone through all this before on the list. My opinion is that there should be wxWidgets28, wxWidgets30, wxWidgets32 ports. There should be no -devel ports. The ports should not conflict with one another. There should be no wx* variants; ports that need wx should depend on the latest supported stable version and be done with it. Maintainers who wish to test whether newer versions would work can edit their portfile locally. Currently, ports should depend on wxWidgets30 if compatible, even though it is not yet stable, because as you said 2.8 doesn't work with current OS X.

As for Tiger, it's unfortunate that the wx developers have dropped 10.4 support, but that's their choice to make. 10.4 support in MacPorts is dwindling. Maintainers may support it if desired, but don't have to. I wouldn't have a problem with wx ports not supporting Tiger anymore.

5. The path-style dependencies shouldn't be used because wxWidgets 2.8 and 2.9 are incompatible with each other

And unnecessary because once (1) is fixed there will be only a single wx port providing any given file.

(path-style can be used with released and development version that are closely related).

Should not occur.

[mojca (Mojca Miklavec)]

I just checked FileZilla and otrproxy. Neither of them compiles with wxWidgets 2.9.

With FileZilla it's relatively explicit. 4 years ago a ticket (​http://trac.filezilla-project.org/ticket/4973) has been closed with wontfix and the following comment:

FileZilla requires wxWidgets 2.8

Note that wxWidgets 2.9 is an unstable development version, it shouldn't be used in a production environment.

even though they have a wx3 branch (​http://svn.filezilla-project.org/filezilla/FileZilla3/branches/), but they haven't touched it for three years and I didn't try to compile that one yet.

Someone submitted a bunch of patches in October 2012 (​http://trac.filezilla-project.org/ticket/8272). I'm not sure against which version exactly, but it's somewhere close to version 3.5.3 and I managed to apply the patches. They needed additional fixing (the patches have been tested on Windows & Linux, but some additional Mac code needed changes) and still didn't compile. They do nightly builds on a Leopard PowerPC machine.

Anyway: FileZilla requires some effort that goes beyond the scope of MacPorts. Someone really needs to collaborate with the upstream developers to get it working, otherwise it would be a lot of effort for very little benefit.

The port otrproxy isn't explicit about supporting 2.8 only, but I couldn't make it work in a few quick attempts either.

[cooljeanius (Eric Gallager)]

Replying to mojca@…:

I just checked FileZilla... [it doesn't compile] with wxWidgets 2.9.

With FileZilla it's relatively explicit. 4 years ago a ticket (​http://trac.filezilla-project.org/ticket/4973) has been closed with wontfix and the following comment:

FileZilla requires wxWidgets 2.8

Note that wxWidgets 2.9 is an unstable development version, it shouldn't be used in a production environment.

even though they have a wx3 branch (​http://svn.filezilla-project.org/filezilla/FileZilla3/branches/), but they haven't touched it for three years and I didn't try to compile that one yet.

Someone submitted a bunch of patches in October 2012 (​http://trac.filezilla-project.org/ticket/8272). I'm not sure against which version exactly, but it's somewhere close to version 3.5.3 and I managed to apply the patches. They needed additional fixing (the patches have been tested on Windows & Linux, but some additional Mac code needed changes) and still didn't compile. They do nightly builds on a Leopard PowerPC machine.

Anyway: FileZilla requires some effort that goes beyond the scope of MacPorts. Someone really needs to collaborate with the upstream developers to get it working, otherwise it would be a lot of effort for very little benefit.

I'd been working on a local copy of the FileZilla portfile, but I haven't gotten it working yet: ​https://github.com/cooljeanius/LocalPorts/blob/master/www/FileZilla/Portfile

[jjstickel (Jonathan Stickel)]

Can I post a post a patch to py-pyface here, or should I open a separate ticket? I will just remove the wx variant from py-pyface for now.

py-mayavi has a potential dependency on wxpython through py-pyface, and so it need not be listed on its own.

[mf2k (Frank Schima)]

Replying to jjstickel@…:

Can I post a post a patch to py-pyface here, or should I open a separate ticket? I will just remove the wx variant from py-pyface for now.

Please open a new ticket and attach the patch there and reference the ticket here. We don't want lots of patches attached to this ticket.

[jjstickel (Jonathan Stickel)]

Replying to macsforever2000@…:

Replying to jjstickel@…:

Can I post a post a patch to py-pyface here, or should I open a separate ticket? I will just remove the wx variant from py-pyface for now.

Please open a new ticket and attach the patch there and reference the ticket here. We don't want lots of patches attached to this ticket.

OK. See ticket #40207.

[mojca (Mojca Miklavec)]

Going through wxPython 2.8 dependencies (other than py-pyface):

• bittorrent - completely outdated and abandoned
• spe - latest release or commit in 2008, name explicitly mentions wxWidgets 2.6, so I wouldn't be too optimistic about it being functional with 2.9
• py-dsv - released in 2003 (there was one more release in 2010 with a single download which is not included in MacPorts [yet])
• py26-pyphant - requires some work (website has moved if nothing else)
• grass - a bit broken

I wonder if anyone uses the first three ports at all and it seems like I don't even want to check anything other than modifying the dependency.

[mojca (Mojca Miklavec)]

I'm closing this ticket (commits mostly between r110234 and r110281). I probably introduced some problems during transition, but I leave the individual ports to maintainers / feel free to open a new ticket if a particular port is now broken.

[cooljeanius (Eric Gallager)]

Replying to mojca@…:

I'm closing this ticket (commits mostly between r110234 and r110281). I probably introduced some problems during transition, but I leave the individual ports to maintainers / feel free to open a new ticket if a particular port is now broken.

Thanks for all your work on this, Mojca!