Re: Fwd: next version of csvkit

[Ben Finney]

Brian May  writes:

>  I just noticed that Ubuntu plan to drop Python 2.7 completely - from
> default installs at least

That's a pretty important modifier!

Ubuntu does not yet plan to drop Python 2.7 completely. Rather, the
current plan is to ensure no *dependencies on* Python 2.7 in the default
installs.

It's the reverse dependencies that are being targeted; not Python 2.7
itself.

So, similar to what we Debian Python folk are striving to do: no plan to
drop Python 2.7, instead working on the reverse dependencies.

-- 
 \“Absurdity, n. A statement or belief manifestly inconsistent |
  `\with one's own opinion.” —Ambrose Bierce, _The Devil's |
_o__)Dictionary_, 1906 |
Ben Finney

Re: Fwd: next version of csvkit

[Brian May]

On 2017-04-04 08:21, Brian May wrote:

> I would suggest that Buster have Python 2.7, however we only support 3rd
> party libraries where it is practical to do so. Any library that has
> dropped Python 2.7 support upstream, is not practical for us to support
> in Python2. Anything that depends on such a package (directly or
> indirectly) also is not practical for us to support.

 I just noticed that Ubuntu plan to drop Python 2.7 completely - from
default installs at least - for the 18.04 release: 

"Plans for 18.04 LTS 

Overarching goals include: 

Python 3 only on the default installs for desktop, server, touch, snappy
images. (Some may already be there.)
Python 3.6 transition" 

https://wiki.ubuntu.com/Python 

Trying to find out what the situation will be for the 17.04 release, not
finding much yet however. 

  

Re: Fwd: next version of csvkit

[Brian May]

Vincent Bernat  writes:

> On the current subject, I also agree we should not drop prematurely
> packages targeted to Python 2. It is likely the support will be extended
> past 2020, at least by distributions with a 10-year support.

RHEL 7 will be supported until 2024.
https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_7

I seem to recall RH had a commitment to support Python 2.7 until 2030,
but I can't find that now.

However, just because some random distribution is supporting Python 2
past 2020, doesn't mean we have any obligation to do so.

Also "we support Python 2.7" doesn't mean "support Python 2.7 in
unstable." It is possible that we will continue supporting Stretch, post
2020 as a LTS release.

https://wiki.debian.org/LTS

Providing *full* Python 2.7 support in unstable is likely to prove to be
harder and harder when various upstreams start dropping Python 2.7
support, starting with Django this December. e.g. When Django drops
support, and we upload that version to unstable, suddenly everything
that depends on Django will also fail to work under Python 2.7.

https://docs.djangoproject.com/en/dev/releases/2.0/

If Django 2.0 is released on schedule, I would like to see it in Buster
- assuming our release cycle remains every 2 years, that will make it
early 2019.

I would suggest that Buster have Python 2.7, however we only support 3rd
party libraries where it is practical to do so. Any library that has
dropped Python 2.7 support upstream, is not practical for us to support
in Python2. Anything that depends on such a package (directly or
indirectly) also is not practical for us to support.
-- 
Brian May 

Re: Fwd: next version of csvkit

[Vincent Bernat]

 ❦  2 avril 2017 09:45 +0100, Ghislain Vaillant  :

>>> it's just a few lines down in the changelog:
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829744 (it is kinda
>>> sad that there was no discussion with the python team from the lintian
>>> maintainer before accepting and merging it, even if it was done after
>>> stretch freeze, which was indeed a clever move)
>
> I'll just point out that Scott did contribute to the discussion which
> lead to the introduction of this Lintian tag in the bug report
> mentioned above.
>
>> It's a general trend with Lintian: it's easier to push for a Lintian tag
>> in a random bug report than getting a consensus and translate it to a
>> Lintian tag.
>
> The introduction of the Lintian tag was ack'd by a member of the team
> (see message 40). Sure this is no consensus, but the decision was not
> "random" either.
>
> CC'ing lamby who might want to shed some light on this.

I said "random", but maybe "hidden" (in plain sight) is a better
word. This list should be a good place to discuss that. And this has
been discussed last year and I seem to remember that the favorite option
was to continue package Python 2 stuff. Conversation starts here:

 https://lists.debian.org/debian-python/2016/08/msg00094.html

And yet, Lintian says otherwise.

> Please focus on the current package (csvkit). It is an **application**
> package, so whether the console scripts are called with Python 2 or
> Python 3 really does not matter.
>
> Perhaps it used to be the case in the past, but the library component
> has been deported to the agate packages, for which I answered Sandro's
> request to package. The reward I am getting is anger and frustration
> from the team, despite my good will. Not cool :-(

Sorry for that. I didn't answer in the context of your package, so my
answers are not really relevant in your case.
-- 
The devil can cite Scripture for his purpose.
-- William Shakespeare, "The Merchant of Venice"


signature.asc
Description: PGP signature

Re: Fwd: next version of csvkit

[Vincent Bernat]

 ❦  2 avril 2017 10:21 +0100, Chris Lamb  :

>> > On the current subject, I also agree we should not drop prematurely
>> > packages targeted to Python 2.
>
> The Lintian tag in question does not suggest maintainers should be
> removing existing Python 2 support from packages.
>
> It merely suggests that you should think twice before *adding* Python 2
> support when putting together a new package. Such support can always be
> added later after user demand. The idea is that if we never add such
> support we've not only saved ourselves some effort in the future, we've
> also encouraged the general adoption of Python 3.
>
> Perhaps this is not clear in the tag/warning/description? This appears to
> be a constant source of confusion/frustration, alas.

I don't want to second-guess too much what people may think about such a
tag but being in Lintian is a strong signal that it is OK to remove
Python 2 support from packages (new ones and by extension existing
ones). But, you are right, the Lintian tag doesn't say that.

I don't believe that a user of a Python 2 packages will think "Gosh!
I'll upgrade to Python 3 right away". I think it is more likely to think
"Those pesky Debian maintainers, always trying to force their
ways". Maybe this will encourage the general adoption of Python 3 a
bit. But maybe this will also encourage people to think that Debian is
not relevant for their needs.

When a package only exists for Python 3, asking for a Python 2 version
will lead to two outcomes:

 1. You'll have to wait. Maybe a lot. But you'll get the package.

 2. You may have to argue. You may get an answer that Python 2 is
deprecated and end of support is soon. Then, you may not get the
package.

For most source packages, adding a Python 2 package is dead easy.
-- 
Don't stop with your first draft.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Fwd: next version of csvkit

[Chris Lamb]

Ghislain Vaillant wrote:

> > On the current subject, I also agree we should not drop prematurely
> > packages targeted to Python 2.

The Lintian tag in question does not suggest maintainers should be
removing existing Python 2 support from packages.

It merely suggests that you should think twice before *adding* Python 2
support when putting together a new package. Such support can always be
added later after user demand. The idea is that if we never add such
support we've not only saved ourselves some effort in the future, we've
also encouraged the general adoption of Python 3.

Perhaps this is not clear in the tag/warning/description? This appears to
be a constant source of confusion/frustration, alas.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Fwd: next version of csvkit

[Ghislain Vaillant]

On 02/04/17 08:39, Vincent Bernat wrote:

 ❦  1 avril 2017 19:42 -0400, Sandro Tosi  :


It's not at all clear where [1] came from.  The lintian changelog [3] does not
give a bug reference and I couldn't find a bug.


it's just a few lines down in the changelog:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829744 (it is kinda
sad that there was no discussion with the python team from the lintian
maintainer before accepting and merging it, even if it was done after
stretch freeze, which was indeed a clever move)


I'll just point out that Scott did contribute to the discussion which 
lead to the introduction of this Lintian tag in the bug report mentioned 
above.



It's a general trend with Lintian: it's easier to push for a Lintian tag
in a random bug report than getting a consensus and translate it to a
Lintian tag.


The introduction of the Lintian tag was ack'd by a member of the team 
(see message 40). Sure this is no consensus, but the decision was not 
"random" either.


CC'ing lamby who might want to shed some light on this.


On the current subject, I also agree we should not drop prematurely
packages targeted to Python 2. It is likely the support will be extended
past 2020, at least by distributions with a 10-year support.



IMO, it's not our job to decide how the ecosystem should work. We will
be alienating our own users. We are not in the strong position we were
10 years ago and those users will just switch to another distribution.


Please focus on the current package (csvkit). It is an **application** 
package, so whether the console scripts are called with Python 2 or 
Python 3 really does not matter.


Perhaps it used to be the case in the past, but the library component 
has been deported to the agate packages, for which I answered Sandro's 
request to package. The reward I am getting is anger and frustration 
from the team, despite my good will. Not cool :-(


Nowadays, the binary package produced by src:csvkit might as well be 
called `csvkit`, and be installed somewhere under /usr/share instead of 
the system site-packages for what it is worth.


Ghis

Re: Fwd: next version of csvkit

[Vincent Bernat]

 ❦  1 avril 2017 19:42 -0400, Sandro Tosi  :

>> It's not at all clear where [1] came from.  The lintian changelog [3] does 
>> not
>> give a bug reference and I couldn't find a bug.
>
> it's just a few lines down in the changelog:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829744 (it is kinda
> sad that there was no discussion with the python team from the lintian
> maintainer before accepting and merging it, even if it was done after
> stretch freeze, which was indeed a clever move)

It's a general trend with Lintian: it's easier to push for a Lintian tag
in a random bug report than getting a consensus and translate it to a
Lintian tag.

On the current subject, I also agree we should not drop prematurely
packages targeted to Python 2. It is likely the support will be extended
past 2020, at least by distributions with a 10-year support.

IMO, it's not our job to decide how the ecosystem should work. We will
be alienating our own users. We are not in the strong position we were
10 years ago and those users will just switch to another distribution.
-- 
Replace repetitive expressions by calls to a common function.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Fwd: next version of csvkit

[Sandro Tosi]

On Sat, Apr 1, 2017 at 4:03 PM, Scott Kitterman  wrote:
> On Saturday, April 01, 2017 05:12:38 PM Ghislain Vaillant wrote:
>> On Sat, 2017-04-01 at 15:55 +, Scott Kitterman wrote:
>> > On April 1, 2017 3:42:50 AM EDT, Ghislain Vaillant 
> wrote:
>> > > ...
>> > >
>> > > How so? Buster will not be supporting Python 2, so the narrative of
>> > > having new source packages only provide Python 3 binary packages is
>> > > totally justified.
>> >
>> > What makes you think this is true?
>>
>> I wonder whether I am the only one who read this [1] or that [2].
>>
>> Pasting the relevant quotes below:
>>
>> "The 2.x series of Python is due for deprecation and will not be
>> maintained past 2020 so it is recommended that Python 2 modules are not
>> packaged unless necessary."
>>
>> "The idea is to basically stop uploading new Python 2 only libraries,
>> port things on the critical path, and swap leaf packages to Python 3."
>>
>> csvkit definitely qualifies as such leaf package, since it is a
>> collection of command-line tools, not a Python library.
>>
>> > As far as I know, Python 2 will be around a long time yet.
>>
>> Python 2 will be supported until 2020. That's sooner rather than later
>> considering we are in 2017 and Stretch has not been released yet.
>>
>> [1] https://lintian.debian.org/tags/new-package-should-not-package-pyth
>> on2-module.html
>> [2] https://lists.debian.org/debian-devel-announce/2015/04/msg5.htm
>> l
>
> It's not at all clear where [1] came from.  The lintian changelog [3] does not
> give a bug reference and I couldn't find a bug.

it's just a few lines down in the changelog:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829744 (it is kinda
sad that there was no discussion with the python team from the lintian
maintainer before accepting and merging it, even if it was done after
stretch freeze, which was indeed a clever move)

>
> [2] is about porting Debian's own infrastructure to Python 3.  It's nothing to
> do with removing support for Python 2 from the archive.
>
> Although the current date is 2020, I don't know anyone in the Python community
> that doesn't expect that to be extended one way or another (it might be
> external to python.org).  No matter how it's managed there are huge Python 2
> code bases that aren't migrated and won't be done in three years.
>
> I believe it makes sense to consider if Python 2 support is needed for new
> packages or not (as an example, when we initially packaged PyQt5 we did it
> only for Python 3, but later had to add Python 2 packages to support upstreams
> that had migrated from Qt4 to Qt5, but not yet to Python 3).
>
> That is completely different than expecting the existing Python 2 things that
> we have will go away.  Pushing too hard on Python 2 removal is a great way to
> make Debian less relevant for things Pythonic.

Thanks for saying exactly what i'm thinking. I've been bitten already
twice (excluding agate) by source packages not shipping a python2
binary packages for pkgs depending on them.

I am sure that the python codebase i'm working on will not be migrated
to python 3 before the current deadline. This crusade against python 2
in debian is just making my work harder and in general a disservice to
debian users.

Dropping a package is a lot easier than passing thru NEW (even if it's
very quick nowdays, but it still requires manual intervention) to add
a new one: can we stop  considering python 2 dead, and make it as best
as we can in Debian (even eventual dropping it once we reach a
decision it's the right move)?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Re: Fwd: next version of csvkit

[Scott Kitterman]

On Saturday, April 01, 2017 05:12:38 PM Ghislain Vaillant wrote:
> On Sat, 2017-04-01 at 15:55 +, Scott Kitterman wrote:
> > On April 1, 2017 3:42:50 AM EDT, Ghislain Vaillant  
wrote:
> > > ...
> > > 
> > > How so? Buster will not be supporting Python 2, so the narrative of
> > > having new source packages only provide Python 3 binary packages is
> > > totally justified.
> > 
> > What makes you think this is true?
> 
> I wonder whether I am the only one who read this [1] or that [2]. 
> 
> Pasting the relevant quotes below:
> 
> "The 2.x series of Python is due for deprecation and will not be
> maintained past 2020 so it is recommended that Python 2 modules are not
> packaged unless necessary."
> 
> "The idea is to basically stop uploading new Python 2 only libraries,
> port things on the critical path, and swap leaf packages to Python 3."
> 
> csvkit definitely qualifies as such leaf package, since it is a
> collection of command-line tools, not a Python library.
> 
> > As far as I know, Python 2 will be around a long time yet.
> 
> Python 2 will be supported until 2020. That's sooner rather than later
> considering we are in 2017 and Stretch has not been released yet.
> 
> [1] https://lintian.debian.org/tags/new-package-should-not-package-pyth
> on2-module.html
> [2] https://lists.debian.org/debian-devel-announce/2015/04/msg5.htm
> l

It's not at all clear where [1] came from.  The lintian changelog [3] does not 
give a bug reference and I couldn't find a bug.

[2] is about porting Debian's own infrastructure to Python 3.  It's nothing to 
do with removing support for Python 2 from the archive.

Although the current date is 2020, I don't know anyone in the Python community 
that doesn't expect that to be extended one way or another (it might be 
external to python.org).  No matter how it's managed there are huge Python 2 
code bases that aren't migrated and won't be done in three years.

I believe it makes sense to consider if Python 2 support is needed for new 
packages or not (as an example, when we initially packaged PyQt5 we did it 
only for Python 3, but later had to add Python 2 packages to support upstreams 
that had migrated from Qt4 to Qt5, but not yet to Python 3).

That is completely different than expecting the existing Python 2 things that 
we have will go away.  Pushing too hard on Python 2 removal is a great way to 
make Debian less relevant for things Pythonic.

Scott K


[3] https://tracker.debian.org/media/packages/l/lintian/changelog-2.5.50

Re: Fwd: next version of csvkit

[Scott Kitterman]

On April 1, 2017 3:42:50 AM EDT, Ghislain Vaillant  wrote:
>...
>
>How so? Buster will not be supporting Python 2, so the narrative of
>having new source packages only provide Python 3 binary packages is
>totally justified.

What makes you think this is true?

As far as I know, Python 2 will be around a long time yet.  

Scott K