On 2020/01/09 15:05, clematis wrote: > Hi team, > > How should we handle a port update which breaks the (EOL) python2 > FLAVOR? > > I had the issue on net/py-urwid which I didn't initially catch. > But their latest version uses async stuff that aren't supported in py2 > nor will be. > > So I am wondering what would be the best way to proceed. > > 1/ Should we wait for py3 to become default to update these ports? > And they become py3 only? will py2 still be a legacy FLAVOR? how to > handle the RUN_DEPENDS? > > 2/ Should we have two versions of the port? The latest being py3 only? > What would be the prefered way to enforce this? > Then progressively update RUN_DEPENDS switching them to py3 as well. > > 3/ ... any other way ? > > Open for comments. I am sure some of you already have kind of a plan to > make the switch at some point. > > Thanks. > -- > clematis (0x7e96fd2400fe7b59) >
Case by case really I think .. 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. 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).
