Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #8784 > unrolled thread

on keep providing python 2 packages

Back to article view | Back to linux.debian.maint.python

Contents

  on keep providing python 2 packages Sandro Tosi <morph@debian.org> - 2016-08-19 09:30 +0200
    Re: on keep providing python 2 packages Olivier Sallou <olivier.sallou@irisa.fr> - 2016-08-19 09:50 +0200
    Re: on keep providing python 2 packages Ondrej Novy <novy@ondrej.org> - 2016-08-19 10:10 +0200
    Re: on keep providing python 2 packages Julien Cristau <jcristau@debian.org> - 2016-08-19 11:50 +0200
    Re: on keep providing python 2 packages "W. Martin Borgert" <debacle@debian.org> - 2016-08-19 12:20 +0200
    Re: on keep providing python 2 packages Dmitry Shachnev <mitya57@debian.org> - 2016-08-19 12:50 +0200
      Re: on keep providing python 2 packages Sandro Tosi <morph@debian.org> - 2016-08-19 13:00 +0200
        Re: on keep providing python 2 packages Dmitry Shachnev <mitya57@debian.org> - 2016-08-19 19:30 +0200
          Re: on keep providing python 2 packages Sandro Tosi <morph@debian.org> - 2016-08-20 18:50 +0200
            Re: on keep providing python 2 packages Mattia Rizzolo <mattia@debian.org> - 2016-08-20 21:10 +0200
              Re: on keep providing python 2 packages Sandro Tosi <morph@debian.org> - 2016-08-20 22:30 +0200
                Re: on keep providing python 2 packages Rick Thomas <rbthomas@pobox.com> - 2016-08-21 00:40 +0200
                Re: on keep providing python 2 packages Piotr Ożarowski <piotr@debian.org> - 2016-08-21 00:40 +0200
                  Re: on keep providing python 2 packages Mattia Rizzolo <mattia@debian.org> - 2016-08-21 09:50 +0200
                  Re: on keep providing python 2 packages Barry Warsaw <barry@debian.org> - 2016-08-21 22:20 +0200
      Re: on keep providing python 2 packages "Elena ``of Valhalla''" <elena.valhalla@gmail.com> - 2016-08-20 13:40 +0200
    Re: on keep providing python 2 packages Barry Warsaw <barry@debian.org> - 2016-08-19 15:30 +0200

#8784 — on keep providing python 2 packages

I got a feeling we are somehow discouraging the introduction of
python2 package in unstable (it was also discussed at the BoF).

while i can see why we dont want to introduce new python2-only
package, i feel that just providing a py3k pkg while the module is
also py2 compatible is a disservice to our users: wether we like it or
not, python 2 is the de facto interpreter for python and not having a
module available will not just make everyone switch to py3k (i already
faced it a couple of times already, where i needed a module to extend
an already existing project, and it was not there)

does anyone else agrees with this view? should we clarify that, when
available, python2 modules must be provided (along with their py3k)?

apps/scripts are fine being py3k by default, but the underlying
modules has to be provided by for py2 if compatible.

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

[toc] | [next] | [standalone]

#8785

----- Mail original -----
> De: "Sandro Tosi" <morph@debian.org>
> À: "debian-python" <debian-python@lists.debian.org>
> Envoyé: Vendredi 19 Août 2016 09:19:46
> Objet: on keep providing python 2 packages
> 
> I got a feeling we are somehow discouraging the introduction of
> python2 package in unstable (it was also discussed at the BoF).

Don't feel the same. After a try to push some python packages, there was clear indication that python2 only packages are not wanted.
But python 2+3 packages were not an issue at all.

Python2 is indeed still the default interpreter and as such, if app/lib is compatible, both should be delivered.

Olivier

> 
> while i can see why we dont want to introduce new python2-only
> package, i feel that just providing a py3k pkg while the module is
> also py2 compatible is a disservice to our users: wether we like it or
> not, python 2 is the de facto interpreter for python and not having a
> module available will not just make everyone switch to py3k (i already
> faced it a couple of times already, where i needed a module to extend
> an already existing project, and it was not there)
> 
> does anyone else agrees with this view? should we clarify that, when
> available, python2 modules must be provided (along with their py3k)?
> 
> apps/scripts are fine being py3k by default, but the underlying
> modules has to be provided by for py2 if compatible.
> 
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> G+: https://plus.google.com/u/0/+SandroTosi
> 
> 

[toc] | [prev] | [next] | [standalone]

#8786

[Multipart message — attachments visible in raw view] — view raw

Hi,

2016-08-19 9:19 GMT+02:00 Sandro Tosi <morph@debian.org>:

> does anyone else agrees with this view? should we clarify that, when
> available, python2 modules must be provided (along with their py3k)?
>

I agree. Nobody will move to Py3 because Debian doesn't have Py2 module.

-- 
Best regards
 Ondřej Nový

Email: novy@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

[toc] | [prev] | [next] | [standalone]

#8790

On Fri, Aug 19, 2016 at 08:19:46 +0100, Sandro Tosi wrote:

> I got a feeling we are somehow discouraging the introduction of
> python2 package in unstable (it was also discussed at the BoF).
> 
> while i can see why we dont want to introduce new python2-only
> package, i feel that just providing a py3k pkg while the module is
> also py2 compatible is a disservice to our users: wether we like it or
> not, python 2 is the de facto interpreter for python and not having a
> module available will not just make everyone switch to py3k (i already
> faced it a couple of times already, where i needed a module to extend
> an already existing project, and it was not there)
> 
> does anyone else agrees with this view? should we clarify that, when
> available, python2 modules must be provided (along with their py3k)?
> 
> apps/scripts are fine being py3k by default, but the underlying
> modules has to be provided by for py2 if compatible.
> 
Very much agree.

Cheers,
Julien

[toc] | [prev] | [next] | [standalone]

#8792

On 2016-08-19 08:19, Sandro Tosi wrote:
> does anyone else agrees with this view? should we clarify that, when
> available, python2 modules must be provided (along with their py3k)?

Yes.

[toc] | [prev] | [next] | [standalone]

#8793

[Multipart message — attachments visible in raw view] — view raw

Hi all,

On Fri, Aug 19, 2016 at 08:19:46AM +0100, Sandro Tosi wrote:
> does anyone else agrees with this view? should we clarify that, when
> available, python2 modules must be provided (along with their py3k)?

I disagree with the “must” wording.

For example, I have a module (which supports both Python 2 and 3), but
the only user of this module is an app (which is Python 3 only).

What’s the point of shipping the Python 2 version of that module then?

In my opinion, we should neither encourage nor discourage shipping the
Python 2 version, and let the maintainer make the decision.

--
Dmitry Shachnev

[toc] | [prev] | [next] | [standalone]

#8794

On Fri, Aug 19, 2016 at 11:42 AM, Dmitry Shachnev <mitya57@debian.org> wrote:
> Hi all,
>
> On Fri, Aug 19, 2016 at 08:19:46AM +0100, Sandro Tosi wrote:
>> does anyone else agrees with this view? should we clarify that, when
>> available, python2 modules must be provided (along with their py3k)?
>
> I disagree with the “must” wording.

i should have probably specified public modules

> For example, I have a module (which supports both Python 2 and 3), but
> the only user of this module is an app (which is Python 3 only).

then this should be an internal module, installed in /usr/share/<pkg>
and not importable via python -c "import <module>"

>
> What’s the point of shipping the Python 2 version of that module then?
>
> In my opinion, we should neither encourage nor discourage shipping the
> Python 2 version, and let the maintainer make the decision.

leaving the decision to the maintainer for public modules means we'll
have py3k-only packages leaving python2 without a usable module, and
if you need one then you file a bug, you wait for the maintainer to
act on it, maybe you need it in stable and you have to backport/ask
for it.

i think we have to support python2 and python3 at the best we can, as
we mandate to have py3k packages
(https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html)
i think we should extend the same level of support to python2, until
it will be decided to drop that stack completely

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

[toc] | [prev] | [next] | [standalone]

#8796

[Multipart message — attachments visible in raw view] — view raw

Hi Sandro,

On Fri, Aug 19, 2016 at 11:49:25AM +0100, Sandro Tosi wrote:
> > For example, I have a module (which supports both Python 2 and 3), but
> > the only user of this module is an app (which is Python 3 only).
>
> then this should be an internal module, installed in /usr/share/<pkg>
> and not importable via python -c "import <module>"

It was initially private, but then was split out into a separate module
because it can be potentially useful for others.

Since that, some third party projects are using it, but they are all
Python 3 AFAIK (module in question is pymarkups).

> i think we have to support python2 and python3 at the best we can, as
> we mandate to have py3k packages
> (https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html)
> i think we should extend the same level of support to python2, until
> it will be decided to drop that stack completely

How about at least replacing “must” with “should” in the proposed wording?

--
Dmitry Shachnev

[toc] | [prev] | [next] | [standalone]

#8802

On Fri, Aug 19, 2016 at 6:26 PM, Dmitry Shachnev <mitya57@debian.org> wrote:
> Hi Sandro,
>
> On Fri, Aug 19, 2016 at 11:49:25AM +0100, Sandro Tosi wrote:
>> > For example, I have a module (which supports both Python 2 and 3), but
>> > the only user of this module is an app (which is Python 3 only).
>>
>> then this should be an internal module, installed in /usr/share/<pkg>
>> and not importable via python -c "import <module>"
>
> It was initially private, but then was split out into a separate module
> because it can be potentially useful for others.
>
> Since that, some third party projects are using it, but they are all
> Python 3 AFAIK (module in question is pymarkups).

but you are not aware of all the potential users of the py2 version,
they are none now because there is not such version available for them
(as Elena mentioned out in her reply)

>
>> i think we have to support python2 and python3 at the best we can, as
>> we mandate to have py3k packages
>> (https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html)
>> i think we should extend the same level of support to python2, until
>> it will be decided to drop that stack completely
>
> How about at least replacing “must” with “should” in the proposed wording?

that text was not meant to be a patch to the policy (yet), but the
idea is to be mandatory to support every version upstream supports, so
the should is just too weak: you can if you want, but you are not
forced to. the must expresses that's mandatory

anyway, why wouldnt you want to provide a python2 package  if the code
supports it? if you got a py3k package working, it's usually
straightforward to have a py pkg. Doing that i've found several issues
with upsteam projects that were fixed, thus increasing the general
quality of their code and our distribution

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

[toc] | [prev] | [next] | [standalone]

#8803

[Multipart message — attachments visible in raw view] — view raw

On Sat, Aug 20, 2016 at 05:42:24PM +0100, Sandro Tosi wrote:
> anyway, why wouldnt you want to provide a python2 package  if the code
> supports it? if you got a py3k package working, it's usually
> straightforward to have a py pkg. Doing that i've found several issues
> with upsteam projects that were fixed, thus increasing the general
> quality of their code and our distribution

my opinion:

it just makes no sense to discuss this now:
 + it's less than 6 months from the freeze
 + I doubt that there will be that many "affected packages" right now,
   much less that many "buggy" (by your proposal) indroced in the next
   few months; I don't recall seeing any example in any email.
 + I very much hope we'll manage to get buster out without python2, in
   that case thinking about shipping py2 modules now when we're going to
   drop them next year would be a plain waste of time.


I'm curious: what triggered this email of yours?

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

[toc] | [prev] | [next] | [standalone]

#8804

On Sat, Aug 20, 2016 at 8:05 PM, Mattia Rizzolo <mattia@debian.org> wrote:
>
> On Sat, Aug 20, 2016 at 05:42:24PM +0100, Sandro Tosi wrote:
> > anyway, why wouldnt you want to provide a python2 package  if the code
> > supports it? if you got a py3k package working, it's usually
> > straightforward to have a py pkg. Doing that i've found several issues
> > with upsteam projects that were fixed, thus increasing the general
> > quality of their code and our distributionsuggestions
>
> my opinion:
>
> it just makes no sense to discuss this now:
>  + it's less than 6 months from the freeze

so, should we stop development/evolution/improvement?

>  + I doubt that there will be that many "affected packages" right now,
>    much less that many "buggy" (by your proposal) indroced in the next
>    few months; I don't recall seeing any example in any email.

dont draw conclusions without having crunched the numbers (i havent
myself), but there were already cases where the python2 support was
missing while it was available upstraem: http://bugs.debian.org/802582

let's fix this before it becomes widespread: better fix 3 (say)
packages than 100 i think

>  + I very much hope we'll manage to get buster out without python2, in
>    that case thinking about shipping py2 modules now when we're going to
>    drop them next year would be a plain waste of time.

it's way to early to say how the evolution will be, but given how
things are now, i very much hope that will NOT be the case, and we'll
be able to ship py2 interpreter and modules in buster. anyway, this is
way offtopic.

> I'm curious: what triggered this email of yours?

http://bugs.debian.org/834777


i'd like to hear the opinion of the dpmt admins and python maintainers
on the OP matter: public module py2 mandatory support, or -in a
boarder shape- to provide debian packages for all the versions of
python an upstream public module supports in its code.

>
> --
> regards,
>                         Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
> more about me:  https://mapreri.org                             : :'  :
> Launchpad user: https://launchpad.net/~mapreri                  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

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

[toc] | [prev] | [next] | [standalone]

#8805

On Aug 20, 2016, at 1:19 PM, Sandro Tosi <morph@debian.org> wrote:

> i'd like to hear the opinion of the dpmt admins and python maintainers
> on the OP matter: public module py2 mandatory support, or -in a
> boarder shape- to provide debian packages for all the versions of
> python an upstream public module supports in its code.

I’m just a user, not a maintainer or developer, but IMHO it makes sense to provide debian packages for all versions, and only those versions, in the intersection of the two sets {supported by upstream} and {supported by debian}.  Anything outside of that intersection either adds work for the debian maintainers or would be useless to debian users.

Enjoy!
Rick

[toc] | [prev] | [next] | [standalone]

#8806

[Multipart message — attachments visible in raw view] — view raw

[Sandro Tosi, 2016-08-20]
> i'd like to hear the opinion of the dpmt admins and python maintainers
> on the OP matter: public module py2 mandatory support, or -in a
> boarder shape- to provide debian packages for all the versions of
> python an upstream public module supports in its code.

IMO:
* all Python applications that support it, should use 3.X only *now*
  (and do not bother with things like alternatives or "-3" suffixes /
  "python3-" prefixes - at least for new packages; I'd even slowly start
  removing alternatives, if it doesn't affect users),
* libraries in Stretch should support 2.X (i.e. add python-foo binary
  packages) if that doesn't require too much additional work (py2dsp
  still creates them). I'm OK with shipping 3.X only packages in NEW
  packages, though. I'd not encourage people to do so but also not
  forbid it,
* we shouldn't accept 2.X only packages in Buster (Stretch+1, released ~2019)
  unless they're a dependency of other packages, and start shipping 3.X only
  packages where it makes sense (and I hope that decision will be mostly made by
  upstreams by simply dropping 2.X support). We can drop some 2.X packages
  (problematic to maintain? better alternatives available? low popcon?),
  but do not do a mass removal yet,
* for Bullseye (Stretch+2, released ~2021) we should start dropping 2.X packages,
  and maybe even remove 2.X interpreter,
* Bullseye + 1 (~2023) is the one without 2.X interpreter and
  python-foo packages for sure (and without /usr/bin/python symlink or
  at least without Debian packages mentioning it, there should be a rule
  to not speak about /usr/bin/python symlink! ;)

Note that Python upstream will stop supporting 2.X in ~2020 so about one
year (and a half?) after releasing Buster.
-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

[toc] | [prev] | [next] | [standalone]

#8808

[Multipart message — attachments visible in raw view] — view raw

On Sun, Aug 21, 2016 at 12:30:42AM +0200, Piotr Ożarowski wrote:
> * libraries in Stretch should support 2.X (i.e. add python-foo binary
>   packages) if that doesn't require too much additional work (py2dsp
>   still creates them). I'm OK with shipping 3.X only packages in NEW
>   packages, though. I'd not encourage people to do so but also not
>   forbid it,

Thanks for having some trust in your fellow package maintainers...

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

[toc] | [prev] | [next] | [standalone]

#8809

[Multipart message — attachments visible in raw view] — view raw

FWIW,

On Aug 21, 2016, at 12:30 AM, Piotr Ożarowski wrote:

>* all Python applications that support it, should use 3.X only *now*
>  (and do not bother with things like alternatives or "-3" suffixes /
>  "python3-" prefixes - at least for new packages; I'd even slowly start
>  removing alternatives, if it doesn't affect users),

+1

>* libraries in Stretch should support 2.X (i.e. add python-foo binary
>  packages) if that doesn't require too much additional work (py2dsp
>  still creates them). I'm OK with shipping 3.X only packages in NEW
>  packages, though. I'd not encourage people to do so but also not
>  forbid it,

I'd also say that it isn't worth *removing* Python 2.x support right now,
unless of course upstream drops it first.

>* we shouldn't accept 2.X only packages in Buster (Stretch+1, released ~2019)
>  unless they're a dependency of other packages, and start shipping 3.X only
>  packages where it makes sense (and I hope that decision will be mostly made
>  by upstreams by simply dropping 2.X support). We can drop some 2.X packages
>  (problematic to maintain? better alternatives available? low popcon?), but
>  do not do a mass removal yet,

+1

>* for Bullseye (Stretch+2, released ~2021) we should start dropping 2.X
>  packages, and maybe even remove 2.X interpreter,

+1 - remember that this will be 10-11 years after 2.7 was released!

>* Bullseye + 1 (~2023) is the one without 2.X interpreter and
>  python-foo packages for sure (and without /usr/bin/python symlink or
>  at least without Debian packages mentioning it, there should be a rule
>  to not speak about /usr/bin/python symlink! ;)

+1

>Note that Python upstream will stop supporting 2.X in ~2020 so about one
>year (and a half?) after releasing Buster.

As you point out, upstream will stop supporting Python 2.7 for normal bug
fixes in 2020, although I suspect it will be supported in security-fix
source-only mode for some years after that.  There has not be an official
announcement of that IIRC, and PEP 373 doesn't describe that, so it's just my
opinion.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#8800

On 2016-08-19 at 13:42:52 +0300, Dmitry Shachnev wrote:
> For example, I have a module (which supports both Python 2 and 3), but
> the only user of this module is an app (which is Python 3 only).
> 
> What’s the point of shipping the Python 2 version of that module then?

Speaking with the assumption that (as mentioned elsewhere in the thread)
the module is written in a way as to be potentially useful for other
users than the app.

As somebody who writes (and keeps running, see debops_) python code for
internal use targetting debian stable, I find that packaged modules are
extremely useful even if they aren't used as a dependency for some app
inside debian, and using them a much saner alternative than getting
dependencies with pip inside a virtualenv.

.. _debops: http://www.enricozini.org/blog/2014/debian/debops/

In this case, there is no real way to know whether people are using
python2 or python3 (except for hints from popcon, that aren't available
however is the python2 version doesn't exist in debian).

> In my opinion, we should neither encourage nor discourage shipping the
> Python 2 version, and let the maintainer make the decision.

I can imagine that there may be cases where adding a py2 version could mean
significant more work for the maintainer, and I can understand people
not being happy having to do that work for a legacy language that will
be removed in a few releases, but I don't thing it's reason enough not
to encourage shipping py2 versions in the vast majority of cases where
the effort required is low.

-- 
Elena ``of Valhalla''

[toc] | [prev] | [next] | [standalone]

#8795

On Aug 19, 2016, at 08:19 AM, Sandro Tosi wrote:

>I got a feeling we are somehow discouraging the introduction of
>python2 package in unstable (it was also discussed at the BoF).

Hi Sandro,

Just to clarify my own opinion, for *libraries* which upstream supports both
Python 2 and Python 3, we should provide both in Debian.  It's also easy, so
why not? :)

I think we should discourage libraries where upstream only provides Python 2
versions, by trying to find bilingual alternatives.  Sometimes this is
unavoidable though.

For *applications* which support both Python 2 and 3, we want to install them
only as Python 3 applications, unless there's some overriding reason why we
need to provide them for both.  That gets into the ugly `nose2-3` situation,
so let's really try to avoid that, and encourage `$python -m` style invocation
where possible.

Now let's talk about libraries for PyPy and Jython. :)

Cheers,
-Barry

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web