[Piglit] Port piglit framework to python3, round 2

[Dylan Baker]

I'm hoping to be no more than a week or two to be ready to send this to the
list.

On Mon, Jan 11, 2016 at 12:53 PM, Brian Paul <brianp at vmware.com> wrote:

> For getting to Python3, are you thinking a few weeks, a month, longer?
>
> Thanks.
>
> -Brian
>
> On 01/11/2016 01:36 PM, Dylan Baker wrote:
>
>> Sure.
>>
>> I've been working on a hybrid approach, using the six library (the
>> generators currently already work this way). Once my subprocess32
>> timeout stuff lands, the code I have will be based on upstream, and I
>> just need to finish sorting out the str/byte/unicode changes between
>> python 2 and 3.
>>
>> My thought is that we can use a hybrid approach while there are still
>> users needing python 2 support, (I know you guys still have some systems
>> using python 2.7 exclusively, as does Red Hat). We can just start
>> removing six and have a python 3 exclusive code base when there are no
>> consumers left for python 2.
>>
>> Dylan
>>
>> On Mon, Jan 11, 2016 at 12:30 PM, Brian Paul <brianp at vmware.com
>> <mailto:brianp at vmware.com>> wrote:
>>
>>     Hi Dylan,
>>
>>     We're actually interested in getting Piglit running on Python3.  Can
>>     you give an update on the status of this?
>>
>>     Thanks!
>>
>>     -Brian
>>
>>
>>     On 03/13/2015 04:30 PM, Dylan Baker wrote:
>>
>>         bump
>>
>>         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
>>             interfaces.
>>
>>             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
>>                  cleanly
>>             2) python changes necessary to keep the python2 branch
>>             running would be
>>                  backported
>>             3) When python2 is no longer necessary for anyone the branch
>>             could be
>>                  dropped.
>>
>>
>>
>>             _______________________________________________
>>             Piglit mailing list
>>             Piglit at lists.freedesktop.org
>>             <mailto:Piglit at lists.freedesktop.org>
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_piglit&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8&m=MlidIFJmNNAteLKJpWaTUweYaX0WsNQnZPUH_cagzoQ&s=YOGp-y6wLqMoZ-jZGT7tJ6mGcO1mHBYKdl6wicO8aHs&e=
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20160111/83c650a4/attachment-0001.html>