On Thu, Jan 09, 2020 at 08:18:41PM +0000, Stuart Henderson wrote:
> If people want to help with py2 EoL, the thing that is really needed at
> this point is to look for application (rather than library) packages
> that currently use Python 2, and look into what's needed to get them
> moved to Python 3. For example beets, quodlibet, pysol have already
> been moved to py3, but there are plenty like fretsonfire, mnemosyne,
> gmapcatcher, mailpile and others that haven't. Prioritise ports that use
> common libraries that have already dropped py2 support upstream (for
> example Pillow, numpy, scipy, matplotlib, pandas - more examples at
> https://python3statement.org/) as they're the ones where we'll run into
> problems first.
Ok understood thanks for the details. I will go back and do my homework
on py-urwid first and will come back to this once I am done.
> In the specific case of py-urwid, 2.10 is basically OK with python 2
> (and they declare support for 2.7, 3.4-3.8, and PyPy). The file causing
> a problem is not used or needed for Python versions below 3.5:
>
> 1497 # Import Trio's event loop only if we are on Python 3.5 or above (async
> def is
> 1498 # not supported in earlier versions).
> 1499 if sys.version_info >= (3, 5):
> 1500 from ._async_kw_event_loop import TrioEventLoop
>
> The problems seen are
>
> 1) the compileall.py stage sees an error when building bytecode for it
>
> For this I think setuptools just needs to be told to skip _async_kw_event_loop
> (something with "exclude" maybe?).
>
> 2) packaging fails because the pyc doesn't exist
>
> Fixing 1 should mean that neither the _async_kw_event_loop.py nor
> _async_kw_event_loop.pyc are installed. Leaving 2, which is easily handled
> for the versions of Python that we're interested in by using ${MODPY_COMMENT}
> on those lines (which is set to @comment for the py2 version).
>
> Fixing 2 alone is the minimum needed to get the port working, but 1 ought to
> be fixed too really (and it should be easy enough to feed upstream). (I wonder
> why it's not a fatal build error if compileall fails - it would certainly help
> make it easier to spot these problems).
Thanks again for taking the time to provide all those details. It does help
a lot. I will go back and work on this. I will provide a new diff on the
previous py-urwid email thread once I've got something ready.
Thanks.
--
clematis (0x7e96fd2400fe7b59)
