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


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

Bug#942106: (some kind of) transition: add python3.8 as a supported python3 version

Started by"Rebecca N. Palmer" <rebecca_palmer@zoho.com>
First post2019-10-26 22:30 +0200
Last post2019-10-27 12:30 +0100
Articles 4 — 2 participants

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Bug#942106: (some kind of) transition: add python3.8 as a supported python3 version "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-10-26 22:30 +0200
    Bug#942106: (some kind of) transition: add python3.8 as a supported python3 version Matthias Klose <doko@debian.org> - 2019-10-27 00:00 +0200
      Bug#942106: (some kind of) transition: add python3.8 as a supported python3 version "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-10-27 00:40 +0200
        Bug#942106: (some kind of) transition: add python3.8 as a supported python3 version "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2019-10-27 12:30 +0100

#11948 — Bug#942106: (some kind of) transition: add python3.8 as a supported python3 version

From"Rebecca N. Palmer" <rebecca_palmer@zoho.com>
Date2019-10-26 22:30 +0200
SubjectBug#942106: (some kind of) transition: add python3.8 as a supported python3 version
Message-ID<yVARc-31x-15@gated-at.bofh.it>
What should be done with modules where Python 3.8 compatibility requires 
moving to a new upstream release that doesn't support Python 2, but the 
Python 2 package still has dependencies (so can't be removed yet under 
existing rules)?

- Split them into two source packages with different upstream versions, 
as was done for matplotlib and numpy?
- Remove the Python 2 package anyway?
- Let them be broken in Python 3.8 for now?

e.g. pandas dropped python2 support in 0.25.0, and gained python3.8 
support in 0.25.2:
https://github.com/pandas-dev/pandas/issues/29043

Ubuntu got pandas 0.23 to build with python3.8, but only by ignoring 268 
test failures (I haven't yet had time to assess their severity):
https://bugs.launchpad.net/ubuntu/+source/pandas/+bug/1849374
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/p/pandas/20191024_181815_7c017@/log.gz

[toc] | [next] | [standalone]


#11949

FromMatthias Klose <doko@debian.org>
Date2019-10-27 00:00 +0200
Message-ID<yVCgh-3Lz-1@gated-at.bofh.it>
In reply to#11948
On 26.10.19 22:09, Rebecca N. Palmer wrote:
> What should be done with modules where Python 3.8 compatibility requires moving 
> to a new upstream release that doesn't support Python 2, but the Python 2 
> package still has dependencies (so can't be removed yet under existing rules)?
> 
> - Split them into two source packages with different upstream versions, as was 
> done for matplotlib and numpy?
> - Remove the Python 2 package anyway?
> - Let them be broken in Python 3.8 for now?
> 
> e.g. pandas dropped python2 support in 0.25.0, and gained python3.8 support in 
> 0.25.2:
> https://github.com/pandas-dev/pandas/issues/29043

yes, that will be an ongoing problem, I see the same for pillow (latest 2.7 
supporting release is 6.2.1) and numpy (1.16 not supporting 3.8, and 1.17 not 
supporting 2.7).

> Ubuntu got pandas 0.23 to build with python3.8, but only by ignoring 268 test 
> failures (I haven't yet had time to assess their severity):
> https://bugs.launchpad.net/ubuntu/+source/pandas/+bug/1849374
> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/p/pandas/20191024_181815_7c017@/log.gz 

yes, https://bugs.launchpad.net/bugs/1849374 documents where I ignored test 
results for a first build, and numpy test results are ignored as well due to a 
packaging bug.

Ubuntu already dropped python-pandas, I wasn't involved with that. So this 
should be possible to do.  Please ask Steve Langasek for details. In the case 
for pandas it should be possible to remove it now with some work, avoiding a 
second Pandas source.

Having a first build in the archive allows you to get more packages built, and 
more people working on the stack. For example the whole astropy stack builds and 
passes tests (except astropy itself). So there is value. Lets enable to build 
stuff first for 3.8 as a supported non-default option.

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


#11950

From"Rebecca N. Palmer" <rebecca_palmer@zoho.com>
Date2019-10-27 00:40 +0200
Message-ID<yVCSZ-4eV-1@gated-at.bofh.it>
In reply to#11949
On 26/10/2019 22:50, Matthias Klose wrote:
> Ubuntu already dropped python-pandas, I wasn't involved with that.
This seems to have been done by the "let things break" approach that 
isn't allowed in Debian, e.g. they can no longer build python-matplotlib:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934870
https://launchpad.net/ubuntu/+source/matplotlib2/2.2.4-2/+build/17968574

pandas is part of the big tangle discussed in
https://lists.debian.org/debian-python/2019/10/msg00092.html

I haven't yet had time to investigate whether it can be removed from 
that tangle (by e.g. dropping Build-Depends and accepting skipped tests).

There's also the possibility that upgrading pandas to 0.25 will break 
API enough to break some reverse dependencies.

I intend to look into this tomorrow.

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


#11951

From"Rebecca N. Palmer" <rebecca_palmer@zoho.com>
Date2019-10-27 12:30 +0100
Message-ID<yVOU9-3m0-1@gated-at.bofh.it>
In reply to#11950
Detailed discussion of pandas has moved to #931557 / debian-science.

Summary:
- python-pandas removal looks feasible, but there is one item that needs 
ftpmaster or release team authorization: either let pypubsub out of NEW 
(preferred), or give us permission to break tnseq-transit.

- 0.23 -> 0.25 API breakage not yet tested.  This will be the first time 
I've done a transition this size (~54 rdeps), so suggestions for good 
testing tools would be welcome.

[toc] | [prev] | [standalone]


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


csiph-web