[Piglit] Port piglit framework to python3, round 2
brianp at vmware.com
Mon Jan 11 12:30:44 PST 2016
We're actually interested in getting Piglit running on Python3. Can you
give an update on the status of this?
On 03/13/2015 04:30 PM, Dylan Baker wrote:
> On Thu, Mar 05, 2015 at 02:04:00PM -0800, Dylan Baker wrote:
>> This is a proposal for another go at moving to python3 for the
>> framework. Due to the amount of work that's gone into piglit over the
>> last few months and years the codebase is very modern, and the
>> transition is pretty straightforward, the only major change is the
>> bytes/unicode/str conversion, which isn't that hard for us since we've
>> already relied on the unicode class for a number of our string
>> So why python3, and why now?
>> The first argument for python3 is features. Feature work is ongoing in
>> python3, while python2 is in long term maintenance mode, and there are
>> features landing in python3 that will either allow us to simplify the
>> piglit code, or to enable useful features with minimal effort. Patch 2
>> provides a sane, portable timeout implementation for piglit to
>> demonstrate this.
>> The second argument I can offer is that linux distributions are starting
>> to make the transition to python3 as their default python version. Arch
>> and Fedora have already made this jump. For windows and OSX the python
>> foundation provides pre compiled binaries.
>> But what about platforms that don't have python3.3+ available?
>> Well, the goal of recently landed changes to the generators was to
>> hybridize the generators to work under either python2.7 or python 3.3+,
>> with the same code base, and this series doesn't change that, nor do I
>> have any plans to do so while there are still python2 consumers. The
>> goal being that tests (including generated tests) should be backportable
>> to the python2 branch without any changes being necessary.
>> The idea then is that directly before landing this code a python2 branch
>> of piglit would be forked and pushed to the upstream repository. Those
>> that need python2 would be able to use the python2 branch for testing,
>> while upstream development would continue on master, which used python3.
>> Any changes that were strictly necessary to keep the python2 branch
>> working with the python3 branch would be backported, presumably by
>> myself, but the goal would be to minimize the number of python changes
>> backported. The one drawback here would be that if the summary format of
>> master (python3) changed it's unlikely that would be backported to
>> python2. Master would still be able to understand python2 generated
>> results, but not vice versa.
>> So, to sum up:
>> 1) branch a python2 branch, tests should be able to cherry-picked/merged
>> 2) python changes necessary to keep the python2 branch running would be
>> 3) When python2 is no longer necessary for anyone the branch could be
>> Piglit mailing list
>> Piglit at lists.freedesktop.org
More information about the Piglit