We have a number of issues with wptrunner that would be resolved by moving it to Python 3.
Most obviously #9007, which would be solved as the underlying CPython issue has been fixed on Python 3.
I recall there being other multiprocessing related issues that would be solved in Python 3, and we'd also potentially be able to move away from multiprocessing and to asyncio (if we could drop Py2 support).
Obviously, dropping Py2 support would require at least Gecko infra to be okay with Py3.6 dependencies.
If we decide to do this, are we keeping other pieces Py 2/3 compatible? Namely manifest & serve (and their dependencies), which are used in Blink infra. And I suspect serve may have to be Py2-compatible because of the large number of custom CGI scripts?
@Hexcles Right, serve is practically impossible to move away from Py2 (okay, not impossible, but it would be a huge amount of work to do and make it correct). manifest and lint should in theory already be Py2/3, and there's no reason to change that.
I don't know if it's possible to run Py3-only in Firefox CI yet, but I would expect us to move to supporting both, with opt-in to correct multiprocess behaiour on Python 3.
I'm not convinced that moving to asyncio is necessaraily a good idea, but i haven't thought about it much.
In https://github.com/w3c/web-platform-tests/issues/9007#issuecomment-368972309 @jgraham listed a "high effort (i.e. good)" option that still seems less effort and more conservative than requiring Python 3. Are there known bugs in Python 2 that will be never be fixed and for which we have no workaround?
@youennf, in WebKit infra, do you use the system-installed Python, or what would a dependency on Py3 mean?
@foolip Only Gecko uses wptrunner, so WebKit infra isn't relevant here.
Sure, that's true. How would we deal with wpt manifest being Python 2 and wpt run being Python 3? Maybe wpt already shells out so it doesn't matter what language the individual commands are implemented using?
@foolip other pieces like manifest & lint are Py 2/3 compatible, so they can be imported and called from both Python 2 (e.g. Blink infra scripts) and Python 3 (e.g. wpt run). And wpt serve is Python 2 only and runs in a separate process.
Resolving this would also fix https://github.com/w3c/web-platform-tests/issues/10143
Current dependencies that don't support Py3:
tools/wptrunner/requirements.txt: mozdebug
tools/wptrunner/requirements_firefox.txt: marionette_driver, mozleak, mozdownload
mozdebug is only actually imported when we're running with --debugger, so at least in principle there's nothing blocking us from getting wptrunner running on Python 3 now for browsers that aren't Firefox.
mozdebug is not that much code [1] and neither is mozleak [2]; a project to port wptrunner could port those without much difficulty.
mozdownload we only really use for downloading geckodriver, and we can easily replace that with something that accesses taskcluster directly.
marionette_driver is more work and somewhat discontinued; I think it would be a good idea to replace the bits of marionette_driver we actually use with a version of the internal webdriver module that uses the marionette commands as a backend. That would enable a lot of code sharing and should be pretty simple since most WebDriver commands map 1:1 to a marionette command.
[1] https://searchfox.org/mozilla-central/source/testing/mozbase/mozdebug/mozdebug/mozdebug.py
[2] https://searchfox.org/mozilla-central/source/testing/mozbase/mozleak/mozleak/
We're python3-first now, and going python3-only in Feb 2021, so I don't think this is tracking much useful? Please re-open if I've overlooked something worth tracking.
Most helpful comment
We're python3-first now, and going python3-only in Feb 2021, so I don't think this is tracking much useful? Please re-open if I've overlooked something worth tracking.