[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Updated PEP 394 (python and python2 commands)



On 18.05.2018 18:14, Scott Kitterman wrote:
> On Friday, May 18, 2018 11:31:37 AM Matthias Klose wrote:
>> On 18.05.2018 05:19, Piotr Ożarowski wrote:
>>> [Matthias Klose, 2018-05-17]
>>>
>>>> PEP 394 [1] saw an update in April 2018 [2], the diffs at [3].
>>>>
>>>> The most important change from my point of view is
>>>>
>>>> -* It is suggested that even distribution-specific packages follow the
>>>> -  ``python2``/``python3`` convention, even in code that is not intended
>>>> to
>>>> +* It is strongly encouraged that distribution-specific packages use
>>>> ``python2`` +  or ``python3`` rather than ``python``, even in code that
>>>> is not intended to>> 
>>>>    operate on other distributions.
>>>
>>> FTR: the day this PEP asks us to point /usr/bin/python to python3 is the
>>> day I start ignoring it, to say the least.
>>>
>>>> I don't think there is enough time to replace all python shebangs to
>>>> python2 in time for the buster release, however there is no harm in
>>>> starting this process now.
>>>
>>> too late, this process has already started (since dh_python2 v3.20180313)
>>> ;-P> 
>>>> But I'd like to get this done for buster+1, in the case we still need to
>>>> ship a Python2/2.7, so that buster+1 doesn't ship with a python command,
>>>> but maybe with a python2 command.
>>>
>>> we already ship /usr/bin/python2. Removing /usr/bin/python makes sense
>>> as well (administrators can symlink it to whatever they want once it's
>>> gone from Debian), but...
>>>
>>>> The first step is to create a set of python2* packages in
>>>> python-defaults, with contain all the python2* symlinks, and having the
>>>> python* packages depend on those python2 packages.  This change itself
>>>> is a no-op and shouldn't affect anything.
>>>>
>>>> As a second step change the dh_python2 (in python-defaults), and
>>>> dh-python to generate dependencies on python2 instead of python, and
>>>> replacing the shebang from python to python2.
>>>>
>>>> This should cover the majority of packages to replace dependencies on
>>>> python with dependencies on python2.  There are packages which don't
>>>> check for python2, so these probably need adjustments.  But again, the
>>>> goal for buster+1 is to ship as few Python2 dependent packages as
>>>> possible, if any.
>>>
>>> this is useless. What will we gain by renaming packages?
>>
>> who said, that we should rename packages? The only packages being dropped
>> are the python defaults packages.
>>
>>> I refuse to do that work!
>>
>> There is no work in renaming the packages. It's about the dependency
>> generation and the shebang.
>>
>>> The only message it sends is that we don't think /usr/bin/python or
>>> python package is Python 2.7 anymore and that's definitely not the
>>> message I want to send.
>>
>> No, that's not what the PEP says.
> 
> Upstream is free to follow Arch in their insanity (even if more slowly) and 
> suggest pointing /usr/bin/python at a python3 version is a reasonable thing to 
> do (eventually).  It's not (and they even explain why in the PEP).  Debian 
> doesn't have to follow.  We can have higher standards.

I don't see how "having higher standards" and being explicit about using
"python2" are exclusive.

And I'm asking you how you come to your statement about "Upstream insanity", and
to your statement that upstream suggests of pointing python to python3.

> I don't see any reason to be able to "apt install python2" instead of "apt 
> install python".  I think it's perfectly fine the way it is now where the same 
> package provides /usr/bin/oython and /usr/bin/python2.  If you exclude 
> eventually pointint /usr/bin/python at a python3 version (and we should), then 
> there's no value in doing it.
> 
> I agree with Piotr.  I don't think we need to "create a set of python2* 
> packages".

no, it gives users the freedom what to do with the python link, with the distro
explicitly going away of using the unversioned python.  This doesn't hurt the
distro.  And the amount of work to do that should not be excessive for the set
of packages targeted to buster+1, if there are any.

Matthias


Reply to: