wxPython versus wxWidgets

[Michael Dickens]

I see in your branch that there is (1) graphics/wxPython-3.0, (2)
graphics/wxWidgets-3.0, and (3) python/py-wxpython-3.0.  I see that
you've set the gnuradio port to try to use (1); I know this will not
work, but I'll correct the issue before it is merged; I appreciate your
efforts; really.

I have a few questions; please do not take these as critiques; I'm just
trying to understand & facilitate discussion:

+ I see that (3) depends on (1), which is confusing (to me) because (1)
is actually installing a version of wxWidgets (that provided with
wxPython, such that the versions always match up if the ports' versions
are aligned).  wxPython is the Python interface to wx, and that's even
what the current Portfile for (1) says -- so, if nothing else a
correction to the description needs to be made for (1).

+ Why is the wxPython-included-wxWidgets port named wxPython instead of
some variant on wxWidgets?  It does not provided wxPython; it provides
wxWidgets no matter that the source is from wxPython.  That is also what
the port "wxWidgets-python" tries to do, with its awkward naming.  I'm
not saying I have a better naming scheme, but I do not like it being
called wxPython if is provides wxWidgets.  Which takes me to just having
a wxWidgets port (as in the next item) for installing wxWidgets.

+ Is the version of wxWidgets provided inside the wxPython tarball the
same as that found from wxWidgets directly (for the same version)?  If
so, then why bother with the special port since wxWidgets is already
provided elsewhere?  Yes, it can result in the current predicament where
wxPython has not yet caught up to the wxWidgets API.  But, it avoids
adding another conflicting or selectable port to those already there. 
Fewer ports is generally less confusing.

That's it for now; keep up the great work! - MLD