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