Re: Updated PEP 394 (python and python2 commands)

2018-05-18 Thread 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)

2018-05-18 Thread 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: Request access on DPMT salsa group

2018-05-18 Thread Piotr Ożarowski
[Víctor Cuadrado Juan, 2018-05-17]
> > I maintain some packages in DPMT, such as:
> > https://salsa.debian.org/python-team/modules/python3-proselint
> > https://salsa.debian.org/python-team/modules/python-neovim
> > and I wanted to push changes to them.
> > 
> > Could somebody add me to the following salsa group?
> > https://salsa.debian.org/python-team/modules
> > 
> > Many thanks in advance,
> I forgot to say that my salsa id is viccuad-guest

done :)
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645



Re: Updated PEP 394 (python and python2 commands)

2018-05-18 Thread 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)

2018-05-18 Thread 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)

2018-05-18 Thread 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)

2018-05-18 Thread 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)

2018-05-18 Thread 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)

2018-05-18 Thread 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




Updates to the Python/GitPackagingPQ wiki page

2018-05-18 Thread Edward Betts
Hello from the mini-DebConf in Hambug.

I've made some improvements to the Python packaging with gbp-pq wiki page.

https://wiki.debian.org/Python/GitPackagingPQ

I've replaced all the references to alioth with instructions for Salsa.

Feel free to revert or correct any of my changes that you think are wrong.

The page still needs some more work so it covers both the packaging of modules
and applications. Currently the examples are all for packaging modules.
-- 
Edward.



Re: Updated PEP 394 (python and python2 commands)

2018-05-18 Thread 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)

2018-05-18 Thread 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