Filing Bugs for Python 3 Switch

[Alexander Bokovoy]

On Wed, 28 Jan 2015, Dan Williams wrote:
>On Wed, 2015-01-28 at 11:09 -0500, Bohuslav Kabrda wrote:
>> Hi,
>> I just filed 2 bugs [A], [B] for the Python 3 switch [C] and I
>> realized that I should probably follow the mass bug filing policy.
>> As I've said previously, we've already had both Python 2 and Python 3
>> on LiveCDs for few releases, so it makes sense to move as much as
>> possible to Python 3. My intention is to mass file bugs only for
>> "applications" (see the second item in second list at [D]) - in
>> short, these are packages for which it doesn't make sense to
>> introduce python3- subpackage, but it only makes sense to rebuild
>> them with Python 3.
>> The mass bug filing policy suggests providing text of the bug for review, so here it is:
>>
>>
>> Since your package requires Python and is considered an application
>> as per [1], I'd like to ask you to rebuild it with Python 3. Please
>> see recommendations and notes at [2]. Note: this switch should only
>> be done assuming you need to do none or very little downstream
>> patching of upstream source. If upstream source doesn't work with
>> Python 3, it's ok to stay with Python 2.
>>
>> Some general notes:
>> If your package depends on Python because of a Python script that has
>> /usr/bin/python in hashbang, you need to change this to
>> /usr/bin/python3. All "Requires" and "BuildRequires" on Python
>> extension modules have to be changed from "python-foo" to
>> "python3-foo" in order for this change to work. If your package is an
>> "application" (let's call it "foo") and it also generates a
>> subpackage with Python bindings (i.e. "python-foo" or "foo-python"),
>> you should provide a python3 subpackage ("python3-foo" or
>> "foo-python3") and use that as dependency of other subpackages.
>
>How about "#!/usr/bin/env python"?  I don't recall who suggested this a
>long time ago, but I'm 99% sure it was to better handle python3...
That would work for alternative implementations which don't differ in
functionality, syntax, and ABI. This is not true for python2/python3.
You can easily have an application package installed that would be
intending python2 via certain required modules (bindings to C libraries,
for example) which couldn't be launched with python3 interpreter.
-- 
/ Alexander Bokovoy