Re: Updated PEP 394 (python and python2 commands)

[Piotr Ożarowski]

[Matthias Klose, 2018-09-25]
> > how about generating dependencies on python2.7 and moving
> > pycompile/pyclean there as well (this also solves pre-dependency issue)
> > 
> >>  - Not having a python package in bullseye (buster+1), but a
> >>python2 package doesn't point to any "default" anymore. Many
> >>users are installing just python, because it's the unversioned
> >>package.  So make it clear that this is another version, and
> >>with having the choice of python2 and python3, most users will
> >>install python3.
> > 
> > same here
> > 
> > additional question: why do you need for all that python2-doc,
> > python2-minimal, python2-dev, libpython2-dev, libpython2-stdlib,
> > python2-dbg and libpython2-dbg binary packages?
> 
> yes, moving the symlinks to the 2.7 packages would be an option as well.  But 
> I
> don't see any difference why one or the other should be the preferred option.

If we start generating dependencies on python2 packages that are not
available in Stretch, we'll have to rebuild these packages (with
hardcoded dependencies) for backports. We'll also force unofficial
package maintainers to do some changes (for no clear reason or benefit)

Re: Updated PEP 394 (python and python2 commands)

[Matthias Klose]

sorry, I never replied to that email.

On 10.06.2018 13:59, Piotr Ożarowski wrote:
> [Matthias Klose, 2018-06-08]
>> from my point of view this doesn't address:
>>
>>  - being able to de-install the python command for buster, if
>>people don't use it.  Most dependencies are auto-generated, so
>>these could be replaced by dependencies on python2. I would
>>assume that the majority of users won't have to install the
>>python package anymore, unless they are doing python2
>>development.
> 
> how about generating dependencies on python2.7 and moving
> pycompile/pyclean there as well (this also solves pre-dependency issue)
> 
>>  - Not having a python package in bullseye (buster+1), but a
>>python2 package doesn't point to any "default" anymore. Many
>>users are installing just python, because it's the unversioned
>>package.  So make it clear that this is another version, and
>>with having the choice of python2 and python3, most users will
>>install python3.
> 
> same here
> 
> additional question: why do you need for all that python2-doc,
> python2-minimal, python2-dev, libpython2-dev, libpython2-stdlib,
> python2-dbg and libpython2-dbg binary packages?

yes, moving the symlinks to the 2.7 packages would be an option as well.  But I
don't see any difference why one or the other should be the preferred option.

Re: Updated PEP 394 (python and python2 commands)

[Piotr Ożarowski]

[Matthias Klose, 2018-06-08]
> from my point of view this doesn't address:
> 
>  - being able to de-install the python command for buster, if
>people don't use it.  Most dependencies are auto-generated, so
>these could be replaced by dependencies on python2. I would
>assume that the majority of users won't have to install the
>python package anymore, unless they are doing python2
>development.

how about generating dependencies on python2.7 and moving
pycompile/pyclean there as well (this also solves pre-dependency issue)

>  - Not having a python package in bullseye (buster+1), but a
>python2 package doesn't point to any "default" anymore. Many
>users are installing just python, because it's the unversioned
>package.  So make it clear that this is another version, and
>with having the choice of python2 and python3, most users will
>install python3.

same here

additional question: why do you need for all that python2-doc,
python2-minimal, python2-dev, libpython2-dev, libpython2-stdlib,
python2-dbg and libpython2-dbg binary packages?
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Updated PEP 394 (python and python2 commands)

[Matthias Klose]

On 19.05.2018 07:24, Stuart Prescott wrote:

Matthias Klose wrote:

The distro should get
out of the way of using the python symlink, and giving users the freedom /
choice what to do about the link.


I think I understand your rationale to stop shipping /usr/bin/python and
once the unversioned symlink disappears from use in Debian then at least
that particular avenue to breaking one's system disappears.

What I don't understand is why any changes to package names or dependencies
are required to achieve that goal.

It sounds like a reasonable amount of work in your proposal, but once we no
longer have any Python 2 applications left at some stage in the bullseye
cycle, isn't the following sufficient?

--- a/debian/rules
+++ b/debian/rules
@@ -247,12 +247,9 @@ binary-arch: build install stamp-doc
  
 : # provide the python and python.1 defaults

 mkdir -p debian/python-minimal/usr/bin
-   ln -sf python$(VER) debian/python-minimal/usr/bin/python
 ln -sf python$(VER) debian/python-minimal/usr/bin/python2
 mkdir -p debian/python-minimal/usr/share/man/man1
-   ln -sf python$(VER).1.gz \
-   debian/python-minimal/usr/share/man/man1/python.1.gz
 ln -sf python$(VER).1.gz \
 debian/python-minimal/usr/share/man/man1/python2.1.gz

and then either later in the bullseye or bookworm cycles, those python-
defaults simply go away along with all the other 'unversioned' python module
and interpreter packages.

What have I (and others!) missed that would make a rather elaborate
packaging dance preferable to this?


from my point of view this doesn't address:

 - being able to de-install the python command for buster, if
   people don't use it.  Most dependencies are auto-generated, so
   these could be replaced by dependencies on python2. I would
   assume that the majority of users won't have to install the
   python package anymore, unless they are doing python2
   development.

 - Not having a python package in bullseye (buster+1), but a
   python2 package doesn't point to any "default" anymore. Many
   users are installing just python, because it's the unversioned
   package.  So make it clear that this is another version, and
   with having the choice of python2 and python3, most users will
   install python3.

Note that with the command-not-found package installed (and using python3), and 
not having python installed, you get now a message


   $ python

   Command 'python' not found, but can be installed with:

   sudo apt install python3
   sudo apt install python

   You also have python3 installed, you can run 'python3' instead.

Assuming that you only have python2 installed in buster, you get this hint 
already in buster, pointing to python3. You can't do this without a separate 
python2 package.


Matthias

Re: Updated PEP 394 (python and python2 commands)

[Scott Kitterman]

On May 22, 2018 7:24:12 PM UTC, Thomas Goirand  wrote:
>On 05/20/2018 11:49 PM, Thomas Goirand wrote:
>> On 05/17/2018 08:53 PM, Matthias Klose wrote:
>>> 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.
>>>
>>> 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.  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.
>> 
>> I very much support this proposal, and don't understand why Scott and
>> Piotr aren't
>>
>> (plus seemingly inventing things you haven't proposed).
>
>Let me rephrase these last bits between brackets, because it looks like
>some people understood this as accusations, which isn't the case. So,
>the (politically) correct wording would be:
>
>"I believe Scott and Pitor misunderstood the intial proposal, and
>extrapolated it to the point that they thought things that were not in
>the initial proposal were there."

More nonsense.  There's nothing pc about avoidance of false accusations.  I 
guess you calling me incompetent to read English is a step up from saying I am 
making stuff up to complain about it, but still it's not great.

What's wrong with just saying something like "I understood Matthias' proposal 
differently.  I don't think he intended that."?  There's no need to accuse 
anyone of anything.

The point he thought most important (use /usr/bin/python2) was already done.  A 
number of people have spoken up against the idea of adding new python2 binary 
packages.  Maybe I'm wrong and that was never intended.  If so, then great, 
we're done.

Scott K

Re: Updated PEP 394 (python and python2 commands)

[Thomas Goirand]

On 05/20/2018 11:49 PM, Thomas Goirand wrote:
> On 05/17/2018 08:53 PM, Matthias Klose wrote:
>> 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.
>>
>> 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.  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.
> 
> I very much support this proposal, and don't understand why Scott and
> Piotr aren't
>
> (plus seemingly inventing things you haven't proposed).

Let me rephrase these last bits between brackets, because it looks like
some people understood this as accusations, which isn't the case. So,
the (politically) correct wording would be:

"I believe Scott and Pitor misunderstood the intial proposal, and
extrapolated it to the point that they thought things that were not in
the initial proposal were there."

Cheers,

Thomas Goirand (zigo)

Re: Updated PEP 394 (python and python2 commands)

[Thomas Goirand]

On 05/17/2018 08:53 PM, Matthias Klose wrote:
> 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.
> 
> 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.  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.
> 
> 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.
> 
> The third step for buster+1 would be to drop the set of python* packages from
> python-defaults.
> 
> Both Debian 8 and Debian 9 already have the python2 symlink, so you could even
> reuse binary packages in the older releases.  If needed, python-defaults could
> be packported to Debian 9 using versioned provides, and to Debian 8 
> introducing
> the same set of python2 packages.
> 
> Matthias

Hi Matthias,

We need to clear-out something.

Is your proposal includes changing:
"Build-Depends: python{,-all,-dev}"

with:
"Build-Depends: python2{,-all,-dev}"

I don't think that's part of your proposal, but it looks like someone
understood this, I'm not sure why.

Cheers,

Thomas Goirand (zigo)

Re: Updated PEP 394 (python and python2 commands)

[Thomas Goirand]

On 05/21/2018 01:38 AM, Scott Kitterman wrote:
> You probably didn't notice that this is already happening (mentioned in the 
> thread).

Great!

> There are other parts of the proposal that we are less sanguine about that 
> you conveniently removed.  It is probably a better idea to get your facts 
> straight before you start throwing around accusations.

I haven't "start throwing around accusations", I wrote that "[I] don't
understand why". Indeed, I found this thread confusing about what
Matthias proposed, and what you and Piotr didn't want. And I'm sure that
I'm not the only one confused.

Cheers,

Thomas Goirand (zigo)

Re: Updated PEP 394 (python and python2 commands)

[Scott Kitterman]

On May 20, 2018 9:49:27 PM UTC, Thomas Goirand  wrote:
>On 05/17/2018 08:53 PM, Matthias Klose wrote:
>> 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.
>> 
>> 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.  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.
>
>I very much support this proposal, and don't understand why Scott and
>Piotr aren't (plus seemingly inventing things you haven't proposed).

You probably didn't notice that this is already happening (mentioned in the 
thread).  Not only did we not object to this, Piotr already implemented it even 
before Matthias suggested it in this thread.  So bottom line is this is 
nonsense.

There are other parts of the proposal that we are less sanguine about that you 
conveniently removed.  It is probably a better idea to get your facts straight 
before you start throwing around accusations.

Scott K

Re: Updated PEP 394 (python and python2 commands)

[Thomas Goirand]

On 05/17/2018 08:53 PM, Matthias Klose wrote:
> 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.
> 
> 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.  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.

I very much support this proposal, and don't understand why Scott and
Piotr aren't (plus seemingly inventing things you haven't proposed).

Cheers,

Thomas Goirand (zigo)

Re: Updated PEP 394 (python and python2 commands)

[Stuart Prescott]

Matthias Klose wrote:
> The distro should get
> out of the way of using the python symlink, and giving users the freedom /
> choice what to do about the link.

I think I understand your rationale to stop shipping /usr/bin/python and 
once the unversioned symlink disappears from use in Debian then at least 
that particular avenue to breaking one's system disappears. 

What I don't understand is why any changes to package names or dependencies 
are required to achieve that goal. 

It sounds like a reasonable amount of work in your proposal, but once we no 
longer have any Python 2 applications left at some stage in the bullseye 
cycle, isn't the following sufficient?

--- a/debian/rules
+++ b/debian/rules
@@ -247,12 +247,9 @@ binary-arch: build install stamp-doc
 
: # provide the python and python.1 defaults
mkdir -p debian/python-minimal/usr/bin
-   ln -sf python$(VER) debian/python-minimal/usr/bin/python
ln -sf python$(VER) debian/python-minimal/usr/bin/python2
mkdir -p debian/python-minimal/usr/share/man/man1
-   ln -sf python$(VER).1.gz \
-   debian/python-minimal/usr/share/man/man1/python.1.gz
ln -sf python$(VER).1.gz \
debian/python-minimal/usr/share/man/man1/python2.1.gz

and then either later in the bullseye or bookworm cycles, those python-
defaults simply go away along with all the other 'unversioned' python module 
and interpreter packages.

What have I (and others!) missed that would make a rather elaborate 
packaging dance preferable to this?

cheers
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Re: Updated PEP 394 (python and python2 commands)

[Scott Kitterman]

On Friday, May 18, 2018 07:29:19 PM Matthias Klose wrote:
> 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.

I think /usr/bin/python2 is fine.  It doesn't hurt anything.  We provide it 
today and should continue to do so.  No package renaming needed.  As PEP 394 
says, there are substantial risks for non-packaged code if /usr/bin/python is 
pointed at a python3 version.  As long as Debian provides python2.7, 
/usr/bin/python should point at python2.7.  Once it's gone, the distro 
shouldn't provide /usr/bin/python at all.

The higher standards part is not following the eventual push to make 
/usr/bin/python point to a python3 version.  I do not think that Debian should 
ever do that.

> 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.

The existing python-defaults package 

Re: Updated PEP 394 (python and python2 commands)

[Matthias Klose]

On 18.05.2018 19:24, Piotr Ożarowski wrote:
>> A bit disappointed about this style of communication, Matthias
> 
> same here (you want us to do something without explaining reasons)
> EOT for me.

well, I thought I explained in the first message.  The distro should get out of
the way of using the python symlink, and giving users the freedom / choice what
to do about the link.

But that's no reason to presume unfounded behavior by either upstream or by 
myself.

Matthias

Re: Updated PEP 394 (python and python2 commands)

[Matthias Klose]

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

Re: Updated PEP 394 (python and python2 commands)

[Piotr Ożarowski]

> A bit disappointed about this style of communication, Matthias

same here (you want us to do something without explaining reasons)
EOT for me.
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Updated PEP 394 (python and python2 commands)

[Matthias Klose]

On 18.05.2018 19:02, Piotr Ożarowski wrote:
>> 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 work in dh-python is not trivial. The work needed in thousands of
> packages (all Python related packages build depend on python{,-dev} or
> python-all{,-dev} is not as well. Rebuilding all binary packages means
> even more work (${python:Depends} is not always the only dependency)…
> and that's only a work in Debian. There are lots of packages outside
> Debian that will need to be updated… for what purpose exactly?

buster+1 is not supposed to ship with "thousands" of Python2 packages, so you
are exaggerating this a lot. For what reason?

> To make it easier to propose later python2-foo binary package rename,
> like Fedora did?

What are you doing here? Accusing me of wrong-doing and lying?  I explicitly
said that no other packages should be renamed.

>>> 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.
> 
> not yet. We all know that it will happen sooner or later, though.

Again, you are accusing upstream about not being honest about their intentions.
Please could you give any rationale for doing so?
https://github.com/python/peps/pull/630 makes it quiet explicit that this is not
the case.

A bit disappointed about this style of communication, Matthias

Re: Updated PEP 394 (python and python2 commands)

[Piotr Ożarowski]

> 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 work in dh-python is not trivial. The work needed in thousands of
packages (all Python related packages build depend on python{,-dev} or
python-all{,-dev} is not as well. Rebuilding all binary packages means
even more work (${python:Depends} is not always the only dependency)…
and that's only a work in Debian. There are lots of packages outside
Debian that will need to be updated… for what purpose exactly?
To make it easier to propose later python2-foo binary package rename,
like Fedora did?

> > 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.

not yet. We all know that it will happen sooner or later, though.

How about creating DEP-394 with a strong message that we have default
Python 2.X and default Python 3.X interpreters and once 2.X will be
gone. Python 3 will NOT become default Python 2.X?
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Updated PEP 394 (python and python2 commands)

[Scott Kitterman]

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 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".

Scott K

Re: Updated PEP 394 (python and python2 commands)

[Matthias Klose]

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.

Matthias

Re: Updated PEP 394 (python and python2 commands)

[Piotr Ożarowski]

[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?

I refuse to do that work!

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.

> The third step for buster+1 would be to drop the set of python* packages from
> python-defaults.

if we manage to remove Python 2.7 from Buster+1, all python-* packages¹
will be gone, including python-defaults so why additional work?

[¹] without -doc packages
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Updated PEP 394 (python and python2 commands)

[Matthias Klose]

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.

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.  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.

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.

The third step for buster+1 would be to drop the set of python* packages from
python-defaults.

Both Debian 8 and Debian 9 already have the python2 symlink, so you could even
reuse binary packages in the older releases.  If needed, python-defaults could
be packported to Debian 9 using versioned provides, and to Debian 8 introducing
the same set of python2 packages.

Matthias

[1] https://www.python.org/dev/peps/pep-0394/
[2] https://github.com/python/peps/pull/630
[3] https://github.com/python/peps/pull/630.diff