Bug#1071073: ITP: pydataverse -- Python module for interacting with Dataverse APIs
Package: wnpp Severity: wishlist Owner: Edward Betts X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: pydataverse Version : 0.3.2 Upstream Author : Jan Range * URL : https://github.com/gdcc/pyDataverse * License : MIT Programming Lang: Python Description : Python module for interacting with Dataverse APIs pyDataverse provides a comprehensive Python interface for interacting with Dataverse's APIs, facilitating the manipulation, validation, import, and export of all Dataverse data-types, including Dataverses, Datasets, and Datafiles. Whether it's for importing large volumes of data into Dataverse, testing instances post-deployment, or executing basic API calls, pyDataverse streamlines these processes. Features include a comprehensive API wrapper covering all Dataverse API endpoints, data models for key Dataverse data types, data conversion tools for Dataverse's JSON format, easy mass imports/exports through CSV templates, utility functions, documented examples, custom exceptions, and a test suite. I plan to maintain this package as part of the Python team.
Re: Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8
On Wed, Apr 03, 2024 at 03:58:21PM -0400, Jeremy Bícha wrote: > I noticed one package affected by this issue, prettytable, has > switched to a fork, pytest-lazy-fixtures (note the s at the end of the > name). > > Would someone like to package this for Debian to fix several packages > failing to build? > > https://github.com/dev-petrov/pytest-lazy-fixtures > > Thank you, > Jeremy Bícha Dear all affected by pytest-lazy-fixture: pytest-lazy-fixtures is now in testing and unstable; in many cases, it can be used as a drop-in replacement for pytest-lazy-fixture (though not all, it turns out). I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from Debian unstable. Best wishes, Julian
Advice about pydevd and debugpy
Hi! Background: debugpy vendors pydevd (which in turn vendors an old version of bytecode). Until version 1.8.0 of debugpy (currently in testing), the vendored copy of pydevd was (almost) identical to the separately published pydevd, so I had replaced the vendored version of pydevd with the Debian-packaged version. pydevd now has an FTBFS, so needs fixing or updating. But now I've found that the version of pydevd published separately (now bumped from version 2.10.0 to 3.0.x) has started diverging fairly significantly from the vendored version in debugpy (as it moved from version 1.8.0 to 1.8.1): both are being modified, but along different paths. Trying to use pydevd 3.0.3 with debugpy 1.8.1 leads to multiple test failures. My thought is that at this point, seeing that these two packages are now diverging sufficiently that tests break, that for debugpy, I should stop trying to use a separately-packaged version of pydevd and instead switch to using the vendored version shipped with debugpy. If we do this, then at some point (probably after trixie, if nothing changes with the forked debugpy - pydevd relationship), I will suggest that we remove the pydevd package from Debian, as debugpy is the only package that depends on it, and I doubt that anyone else is using pydevd directly. (A separate issue is that the chances are that the pydevd tests that have started failing with the separately packaged pydevd will fail with the vendored version in debugpy as well, but they are not being run in the upstream test suite, and I'm not sure they would be able to run in this vendored environment anyway.) Does anyone have any comments on my plan? Best wishes, Julian
Re: Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8
On May 13, 2024 8:13:06 PM UTC, Julian Gilbey wrote: >On Wed, Apr 03, 2024 at 03:58:21PM -0400, Jeremy Bícha wrote: >> I noticed one package affected by this issue, prettytable, has >> switched to a fork, pytest-lazy-fixtures (note the s at the end of the >> name). >> >> Would someone like to package this for Debian to fix several packages >> failing to build? >> >> https://github.com/dev-petrov/pytest-lazy-fixtures >> >> Thank you, >> Jeremy Bícha > >Dear all affected by pytest-lazy-fixture: pytest-lazy-fixtures is now >in testing and unstable; in many cases, it can be used as a drop-in >replacement for pytest-lazy-fixture (though not all, it turns out). > >I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from >Debian unstable. Please transition all the rdepends first. Asking before that's done just creates more work for everyone. Scott K
Re: Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8
Le lun. 13 mai 2024 à 22:59, Scott Kitterman a écrit : > >I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from > >Debian unstable. > > Please transition all the rdepends first. Asking before that's done just > creates more work for everyone. > > Scott K It looks like for this one package it's already clear. @Julian: here it looks you forgot to check build-depends: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067200 I don't know what's the best way to check this, I use this template hereunder Greetings #!/bin/sh Sources=/var/lib/apt/lists/ftp.*.debian.org_debian_dists_unstable_*_source_Sources Packages=/var/lib/apt/lists/ftp.*.debian.org_debian_dists_unstable_*_binary-amd64_Packages ben query '.build-depends ~ "python3-lazy-fixture"' $Sources -s Package,Maintainer ben query '.build-depends-indep ~ "python3-lazy-fixture"' $Sources -s Package,Maintainer ben query '.depends ~ "python3-lazy-fixture"' $Packages -s Package,Maintaine
Re: Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8
Le mar. 14 mai 2024 à 08:35, Julian Gilbey a écrit : > > On Mon, May 13, 2024 at 11:07:54PM +0200, Alexandre Detiste wrote: > > Le lun. 13 mai 2024 à 22:59, Scott Kitterman a écrit > > : > > > >I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from > > > >Debian unstable. > > > > > > Please transition all the rdepends first. Asking before that's done > > > just creates more work for everyone. > > > > > > Scott K > > > > It looks like for this one package it's already clear. > > > > @Julian: here it looks you forgot to check build-depends: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067200 > > Oh, gosh, I thought I had done so (this is cython3-legacy), but I > clearly made a serious mistake in my attempt! I made a mistake in my attempt too..., here's the real list: Maintainer: Sandro Tosi Package: prettytable Maintainer: Debian GIS Project -> CC'ing Antonio Package: pycoast Package: pyresample Maintainer: Debian Python Team Package: python-django-timezone-field Package: python-limits Package: python-marshmallow-sqlalchemy
Re: Bug#1063957: python-pytest-lazy-fixture: autopkgtest regression with pytest 8
On Mon, May 13, 2024 at 11:07:54PM +0200, Alexandre Detiste wrote: > Le lun. 13 mai 2024 à 22:59, Scott Kitterman a écrit : > > >I suggest that we soon ask ftpmaster to drop pytest-lazy-fixture from > > >Debian unstable. > > > > Please transition all the rdepends first. Asking before that's done just > > creates more work for everyone. > > > > Scott K > > It looks like for this one package it's already clear. > > @Julian: here it looks you forgot to check build-depends: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067200 Oh, gosh, I thought I had done so (this is cython3-legacy), but I clearly made a serious mistake in my attempt! > I don't know what's the best way to check this, I use this template hereunder Thanks Alexandre! > #!/bin/sh > Sources=/var/lib/apt/lists/ftp.*.debian.org_debian_dists_unstable_*_source_Sources > Packages=/var/lib/apt/lists/ftp.*.debian.org_debian_dists_unstable_*_binary-amd64_Packages > > ben query '.build-depends ~ "python3-lazy-fixture"' $Sources -s > Package,Maintainer > ben query '.build-depends-indep ~ "python3-lazy-fixture"' $Sources -s > Package,Maintainer > ben query '.depends ~ "python3-lazy-fixture"' $Packages -s Package,Maintaine As you say, though, in this case, pytest-lazy-fixture itself has an unfixable RC bug, so all of the rdepends need to be fixed (and by "soon", I was thinking "once all these packages no longer depend on it, but I should have said that explicitly ;-) Best wishes, Julian
