wxPython (was: [109331] trunk/dports/graphics)

[Michael Dickens]

On Tue, Aug 13, 2013, at 12:52 PM, Mojca Miklavec wrote:
> On Tue, Aug 13, 2013 at 6:08 PM, Michael Dickens wrote:
> > This change is all well and good, but wxWidgets-devel and wxWidgets30 are
> > still broken
> 
> You mean py*-wxpython30 and py*-wxpython-devel?

Yes, and no.  Here's what I originally meant:
{{{
Because wxWidgets was updated to @2.9.5 API, wxPython @2.9.4 will not
build.  wxPython was not been updated to @2.9.5 yet, and, historically,
has been kept @ the same release version as wxWidgets.  There is nothing
wrong with wxPython; it is meant to be used with wxWidgets @2.9.4. 
Hence, IMHO wxWidgets is really what is broken even though it installs
cleanly; also, because we know that reverting wxWidgets back to @2.9.4
will fix this issue.
}}}
But, I also realize that there are other ports beyond wxPython that
depend on wxWidgets; hence, yes, wxPython is really what is broken.

My basic belief is that ports that worked with wxWidgets @2.9.4, which
did not fail after bring rev-bumped when wxWidgets @2.9.5 was committed,
can once again be rev-bumped to work with wxWidgets @2.9.4 if those
ports wxWidgets @2.9.5 were reverted back to @2.9.4. By doing this
reversion, you buy yourself time with respect to the wxPython issue as
well as all of the tickets you're working on.  This would be just a
temporary fix, nothing permanent; it should be straight forward to both
implement on the trunk and merge into your branch.

I have not found time to test your branch; I hopefully will in the next
few days if it is still relevant.

There are a number of ports which rely on wxWidgets-devel (including one
I maintain), so I've been waiting for your branch's commit before I move
this port over to using wx*30 (or, whatever its name ends up being).

I fully sympathize that there are a -lot- of WX tickets that you are
working on addressing, and it is impossible to please everyone all of
the time.  I think it's great that someone has stepped forward to assume
this (undesirable) challenge, and I applaud you for your efforts.  I did
something similar with Qt4 a few years back, and it was quite a large
effort!

That said, I think doing the quick, temporary reversion to wxWidgets
@2.9.4 is "the right thing to do" in this specific circumstance; but, if
you feel otherwise then by all means continue as is.  I've said my say,
and I think we both understand each other in this regard. - MLD

> But if I got any feedback from experienced developers, this would be a
> matter that could be solved *today* if there is sufficient interest.
> 
> Anyway, there is one single port that depends on wxWidgets-devel's
> wxPython and one single port that depends on wxWidgets30's wxPython
> (and that one with problems).
> 
> I'm all for solving it quickly and there are currently 24 open tickets
> related to wxPython (and another 10 related to wxWidgets + many others
> in wxWidgets' dependencies). But I would really like to start using
> the pieces from the new ports where they could be applied without pain
> (like replacing the base wxWidgets port which needs an update in
> another 28 ports) and I don't dare doing this without some feedback
> and opinion from other more experienced developers. My changes
> probably don't address all of those 24+10 tickets, but I believe they
> will address the majority (7/10 for wxWidgets and most wxpython's).
> 
> I can roll back the changes and then the current
> "all-broken-status-quo" of wxwidgets can stay like that forever.
> 
> I really need someone else's testing and an "OK".