[Freewx-maint] Bug#895083: Bug#895083: python-wxgtk4.0: module wx is not usable

[Norbert Lange]

2018-04-07 23:28 GMT+02:00 Olly Betts <olly at survex.com>:
> Control: severity -1 normal
>
> On Sat, Apr 07, 2018 at 05:30:19PM +0300, Adrian Bunk wrote:
>> On Fri, Apr 06, 2018 at 11:53:39PM -0400, Scott Talbert wrote:
>> > On Sat, 7 Apr 2018, Norbert Lange wrote:
>> >
>> > > it appears that the files are installed in a subdirectory,
>> > > potentially to avoid confligs with previous versions?
>> > > result is that
>> > >
>> > > import wx fails with
>> > >
>> > > ImportError: No module named wx
>> > >
>> > > I havent found a way to configure the installation
>> >
>> > The purpose of the python-wxgtk4.0 package is primarily for application
>> > developers to use in porting their applications to wxPython 4.0 (Phoenix).
>> > There isn't much of a reason otherwise to use the Python 2 version of
>> > wxPython 4.0.  Instead, you should use python3-wxgtk4.0 with which you can
>> > 'import wx'.
>> >
>> > If you really would like to use the Python 2 version, you can do:
>> >
>> > PYTHONPATH=/usr/lib/python2.7/dist-packages/wxPython-4.0.1-py2.7-linux-amd64.egg python
>> > import wx
>
> This doesn't appear to be documented in the package, which it really
> should be (probably a brief explanation in the package description, and
> more detail in README.Debian).

The package name alone would imply it serves the same purpose as
python3-wxgtk4.0, python-wxgtk3.0. which is providing the wx module

>
> Maybe it's also worth including a trival wrapper script to set
> PYTHONPATH suitably and then exec python.
>
>> Is there a good reason why you are making it harder than necessary to
>> use python-wxgtk4.0 ?
>
> Because wxPython 3.0 already exists for Python 2 as module "wx".  But
> wxPython 3.0 doesn't support Python 3 and never will, so there's no
> other claimant for module "wx" for Python 3.
>
> wxPython 4.0 is pretty much a from-the-ground-up rebuild and isn't
> completely compatible with wxPython 3.0, so switching "import wx" to use
> that for Python 2 would not work out well.

its not entirely incompatible either, as right now I only get deprecation
warnings on code that was written for wxPython 3.0.

>
> And a lot of packages use wxPython 3.0, so wxPython 4.0 for Python 2
> really needs to be co-installable with wxPython 3.0.

And a few packages like scapy still don't work with Python 3.
Its forcing Python3 vs. forcing wxPython 4.0.

>
> Installing the module as "wx4" or something isn't helpful as that
> doesn't match what upstream does, nor how it's packaged for Python 3.

i agree that this is not viable.

>
> The only reason Scott created this package is to help people maintaining
> a wxPython application who want to migrate it to wxPython 4.0 - that
> involves both porting it from Python 2 to Python 3 and from wxPython 3.0
> to wxPython 4.0.  Rather than having to do both together, with this
> package you can port to Python 2 + wxPython 4.0 as an intermediate step.

this also makes it hard to drop wxPython 3.0, as right now there is
a need to run such apps on current systems.

>
> So I'd say the bug here is really that this isn't clear from the current
> packages.
>
>> Python 2 is fully supported by Debian during the lifetime of buster,
>> and there are various reasons why many users are stuck with Python 2
>> for some more time.
>
> There are, but people sticking with Python 2 are really unlikely to want
> to use wxPython 4.0.

Sticking to Python2 is not the reason, no. The argument would be to
use wxPython 4.0,
and have it painlessly run on current systems and with packages
that aren't yet ported to python3.
without wxPython 4.0 on python2, you have to stick to wxPython 3.0,
and either bet on upwards compatibility or test on both libraries.

Personally I would prefer a mutual-exlusive installation or
an update-alternatives scheme as sym-linking the wx folder did work for me.

Norbert