Help needed to adapt python-skbio to Python3(?) / Pandas
Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1 https://github.com/biocore/scikit-bio/issues/1678
Hi Rebecca,
thanks a lot for working on the Pandas migration.
On Wed, Nov 13, 2019 at 10:19:56PM +, Rebecca N. Palmer wrote:
> The ones that are blocking pandas [1] are python-skbio,
>
> [1] https://qa.debian.org/excuses.php?package=pandas (cnvkit since fixed)
I've checked the issue with some patch from upstream[1] but failed. I
also tried to build HEAD from upstream which also leaves three remaining
errors which I reported in issue #1678[2]:
==
ERROR: test_munging_invalid_type_to_self_type
(skbio.sequence.tests.test_sequence.TestDistance)
--
Traceback (most recent call last):
File
"/build/python-skbio-0.5.5a/.pybuild/cpython3_3.7_skbio/build/skbio/sequence/tests/test_sequence.py",
line 2369, in test_munging_invalid_type_to_self_type
Sequence("ACGT").distance(42)
File
"/build/python-skbio-0.5.5a/.pybuild/cpython3_3.7_skbio/build/skbio/sequence/_sequence.py",
line 1539, in distance
other = self._munge_to_self_type(other, 'distance')
File
"/build/python-skbio-0.5.5a/.pybuild/cpython3_3.7_skbio/build/skbio/sequence/_sequence.py",
line 2161, in _munge_to_self_type
return self.__class__(other)
File
"/build/python-skbio-0.5.5a/.pybuild/cpython3_3.7_skbio/build/skbio/sequence/_sequence.py",
line 622, in __init__
s = np.frombuffer(sequence, dtype=np.uint8)
TypeError: a bytes-like object is required, not 'int'
==
ERROR: test_init_invalid_sequence
(skbio.sequence.tests.test_sequence.TestSequence)
--
Traceback (most recent call last):
File
"/build/python-skbio-0.5.5a/.pybuild/cpython3_3.7_skbio/build/skbio/sequence/tests/test_sequence.py",
line 465, in test_init_invalid_sequence
Sequence(('a', 'b', 'c'))
File
"/build/python-skbio-0.5.5a/.pybuild/cpython3_3.7_skbio/build/skbio/sequence/_sequence.py",
line 622, in __init__
s = np.frombuffer(sequence, dtype=np.uint8)
TypeError: a bytes-like object is required, not 'tuple'
==
FAIL: test_no_variation_pearson
(skbio.stats.distance.tests.test_mantel.MantelTests)
--
Traceback (most recent call last):
File
"/build/python-skbio-0.5.5a/.pybuild/cpython3_3.7_skbio/build/skbio/stats/distance/tests/test_mantel.py",
line 247, in test_no_variation_pearson
npt.assert_equal(obs, (np.nan, np.nan, 3))
File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line
355, in assert_equal
assert_equal(actual[k], desired[k], 'item=%r\n%s' % (k, err_msg), verbose)
File "/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line
427, in assert_equal
raise AssertionError(msg)
AssertionError:
Items are not equal:
item=0
ACTUAL: 0.0
DESIRED: nan
--
Ran 2352 tests in 44.011s
FAILED (SKIP=30, errors=2, failures=1)
I somehow suspect that the two errors above might be caused by a broken
Python3 conversion - any help to fix this would be welcome.
Kind regards
Andreas.
[1]
https://github.com/biocore/scikit-bio/commit/9c061da7e2746aee403b41621f71b118ce5c52f8
[2] https://github.com/biocore/scikit-bio/issues/1678
--
http://fam-tille.de
Re: Bug#942106: Adding Python 3.8 as a supported Python3 version
On 12.11.19 23:39, Matthias Klose wrote: > On 07.11.19 15:08, Matthias Klose wrote: >> This weekend, I am planning to upload python3-defaults, adding python3.8 as a >> supported Python3 version. This may introduce some churn in unstable until >> the >> basic binNMUs are available as well. >> >> Details for the addition can be found at [1], known issues and patches are >> filed >> [2]. There was no test rebuild in Debian itself, but the addition was made >> in >> the current Ubuntu development series. Things look good, and from my point >> of >> view don't block any unrelated transition work. python3-defaults will get a >> RC >> issue to stay in unstable until the packages build-depending on >> python3-all-dev >> are built, and after doing a test rebuild with the two supported Python3 >> versions. Earlier test rebuilds don't make sense. >> >> There are a few packages, where the upstream versions used in Ubuntu diverge >> from the ones currently in unstable (not naming those already updated in >> unstable by the DPMT): >> >> - hypothesis #942693, not sure if this is really needed, >> the testsuite stack might be fixed by the new pluggy >> version as well. >> >> - python-xarray #944044. 1.4 is already broken with Python 3.7. For >> Ubuntu I fell back to 1.2.1. 1.2.3 might work as well, still seeing >> one or two test failures. >> >> - Using numpy from experimental, and only building the Python2 numpy >> packages from the python-numpy source. >> >> - Using python-scipy from experimental, building the Python3 packages, >> and renaming the python-scipy package to python2-scipy, only building >> the Python2 packages. >> >> - matplotlib and pandas don't have Python2 packages in Ubuntu >> anymore, so I can't tell much what is needed here. Pandas needs >> a new upstream for 3.8. >> >> Packages building on top of numpy/scipy/pandas, like the PyAstro stack, >> continue >> to work with these updates, despite some new test failures. > > So this upload didn't happen, but thanks to Rebecca we now have an almost > Python2 free pandas in unstable. And apologies to the science team for the > 1-day > delayed NMUs for patsy and scikit-learn. > > Now planning the python3-defaults upload for Thursday or Friday. python3-defaults with 3.8 as a supported Python3 version is now built in unstable. Release team, please schedule binNMUs fpr stage1 and then stage2. I'll raise severity of the 3.8 issues, and follow-up with 2-days delayed NMUs. Matthias
Re: Severity bump script
On Mon, Nov 11, 2019 at 1:29 AM Ondrej Novy wrote: > > Hi Sandro, > > -- Forwarded message - > > We are going to raise the severity of the py2removal bugs to "serious" in > > several steps. In the > > first phase we are going to raise severity of the py2removal bugs for > > all leaf module packages and low popcon (< 300) application packages. > > Bugs marked with the "py2keep" user tag will not have their severity > > raised. > > is there any progress with script from your site please? First we need list > to check. Thanks a lot. where is the first draft: http://sandrotosi.me/debian/py2removal/would_raise_to_rc.txt (it will be updated every time the script runs) there are 703 unique severity bumps roughly half of the pending bugs. please note there are duplicates in the list as data is per binary package, while bugs are on a source package basis. you can read the heuristic to determine if it's a module (https://github.com/sandrotosi/debian-tools/blob/master/py2rm_progress.py#L472) or and app (https://github.com/sandrotosi/debian-tools/blob/master/py2rm_progress.py#L475) in the links, they are pretty weak, is there a better way? all in all i think this is not the effect people were expecting: there are too many packages that would become RC-buggy; also the severity bump is done at the source package level, even if only a single binary in the pkg set matches the criteria (which, if you read the request above, it is what's wanted). Let me know what you think, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
