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

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

[MBF] pybuild: Stop calling setup.py test?

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

Contents

  [MBF] pybuild: Stop calling setup.py test? Stefano Rivera <stefanor@debian.org> - 2022-08-15 20:30 +0200
    Re: [MBF] pybuild: Stop calling setup.py test? Louis-Philippe Véronneau <pollo@debian.org> - 2022-08-15 21:40 +0200
    Re: [MBF] pybuild: Stop calling setup.py test? Colin Watson <cjwatson@debian.org> - 2022-12-10 23:20 +0100
      Re: [MBF] pybuild: Stop calling setup.py test? Louis-Philippe Véronneau <pollo@debian.org> - 2022-12-11 02:00 +0100
        Re: [MBF] pybuild: Stop calling setup.py test? Stuart Prescott <stuart@debian.org> - 2022-12-13 00:30 +0100

#14348 — [MBF] pybuild: Stop calling setup.py test?

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

Calling "setup.py test" has been deprecated since setuptools 28.5.
That's 6 years ago.

pybuild calls currently setup.py test, when it can see that the package
supports it, and another test runner hasn't been selected. I looked at
dropping support for this (https://bugs.debian.org/982298) last year.
I did some test builds and decided that breaking 50 odd packages to stop
calling setup.py test wasn't worth it.

I just ran the tests again, and the numbers are 41 new FTBFS, and 54
packages start emitting "Ran 0 tests", so they lost test coverage.
dd-lists attached.

That's an improvement over last year, but still enough to give me pause
on just changing pybuild and breaking packages.

We also now know that calling setup.py at all is deprecated. "setup.py
test" support hasn't been removed yet, and I don't know if it will be,
at this point...

Options:
1. Change pybuild, cause 41 new FTBFS, and 54 packages to lose testing.
   File FTBFS bugs.
2. File "Severity: important" bugs on the packages that would FTBFS or lose
   testing.
   Change pybuild when most of these are closed.
3. File "Severity: minor" bugs on the packages that would FTBFS or lose
   testing.
   Leave pybuild as is, for now.
   Change pybuild when upstream setuptools drops support for "setup.py
   test".

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

[toc] | [next] | [standalone]

#14349

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

On 2022-08-15 14 h 27, Stefano Rivera wrote:
> Calling "setup.py test" has been deprecated since setuptools 28.5.
> That's 6 years ago.
> 
> pybuild calls currently setup.py test, when it can see that the package
> supports it, and another test runner hasn't been selected. I looked at
> dropping support for this (https://bugs.debian.org/982298) last year.
> I did some test builds and decided that breaking 50 odd packages to stop
> calling setup.py test wasn't worth it.
> 
> I just ran the tests again, and the numbers are 41 new FTBFS, and 54
> packages start emitting "Ran 0 tests", so they lost test coverage.
> dd-lists attached.
> 
> That's an improvement over last year, but still enough to give me pause
> on just changing pybuild and breaking packages.
> 
> We also now know that calling setup.py at all is deprecated. "setup.py
> test" support hasn't been removed yet, and I don't know if it will be,
> at this point...
> 
> Options:
> 1. Change pybuild, cause 41 new FTBFS, and 54 packages to lose testing.
>     File FTBFS bugs.
> 2. File "Severity: important" bugs on the packages that would FTBFS or lose
>     testing.
>     Change pybuild when most of these are closed.
> 3. File "Severity: minor" bugs on the packages that would FTBFS or lose
>     testing.
>     Leave pybuild as is, for now.
>     Change pybuild when upstream setuptools drops support for "setup.py
>     test".

I think we're currently in a good place wrt the Bookworm release. This 
gives us some leeway in what we want to do with the time we have until 
the freeze :)

I think option 2 is reasonable _IF_ (big 'if' here) we plan to stick 
with python 3.10. I don't think we need 50 extra RC bugs in addition to 
all the potential 3.11 failures. Otherwise, I'd go with 3. 1 seems 
unnecessary disruptive.

I guess fixing those bugs could be a valuable sprint goal for the 
potential remote sprint we discussed at DC22. I'll try to prod people on 
the ML in the next few days to see who'd be interested.

Cheers,

-- 
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
   ⠈⠳⣄

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

#14711

On Mon, Aug 15, 2022 at 06:27:22PM +0000, Stefano Rivera wrote:
> Calling "setup.py test" has been deprecated since setuptools 28.5.
> That's 6 years ago.
> 
> pybuild calls currently setup.py test, when it can see that the package
> supports it, and another test runner hasn't been selected. I looked at
> dropping support for this (https://bugs.debian.org/982298) last year.
> I did some test builds and decided that breaking 50 odd packages to stop
> calling setup.py test wasn't worth it.

I spent a bit of time this weekend converting some packages that I'm
interested in to use the pytest runner, focusing first on ones that were
using nose but also a few from this list (lazr.uri, python-wadllib,
zope.interface).

I needed a couple of workarounds, some due to packages using
importlib.metadata to get their own version at import time (typified by
the rather messy
https://salsa.debian.org/python-team/packages/lazr.uri/-/commit/786825acc6)
and some due to pre-PEP-420 namespace packages (typified by
https://salsa.debian.org/python-team/packages/zope.interface/-/commit/a8c7881b1a).
Fortunately pytest provides IMO rather convenient ways to hook in and
gently tweak the import system just before it tries to import the
modules under test, which I think is better in this context than
bringing up a virtualenv or whatever.

I'd be happy to do a bit more of this sort of thing.
https://veronneau.org/debian-python-team-2022-sprint-report.html said
that around 29 of 67 team-maintained packages were fixed during the
sprint, which means I'm going to have a slightly annoying hit rate if I
have to just go through this email to find targets.  Is there somewhere
else where the current list of target packages is being maintained, or
would it be possible to do this mass bug-filing at sub-RC level so that
there's a convenient list in the BTS?

Thanks,

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]

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

#14712

On 2022-12-10 17 h 09, Colin Watson wrote:
> On Mon, Aug 15, 2022 at 06:27:22PM +0000, Stefano Rivera wrote:
>> Calling "setup.py test" has been deprecated since setuptools 28.5.
>> That's 6 years ago.
>>
>> pybuild calls currently setup.py test, when it can see that the package
>> supports it, and another test runner hasn't been selected. I looked at
>> dropping support for this (https://bugs.debian.org/982298) last year.
>> I did some test builds and decided that breaking 50 odd packages to stop
>> calling setup.py test wasn't worth it.
> 
> I spent a bit of time this weekend converting some packages that I'm
> interested in to use the pytest runner, focusing first on ones that were
> using nose but also a few from this list (lazr.uri, python-wadllib,
> zope.interface).
> 
> I needed a couple of workarounds, some due to packages using
> importlib.metadata to get their own version at import time (typified by
> the rather messy
> https://salsa.debian.org/python-team/packages/lazr.uri/-/commit/786825acc6)
> and some due to pre-PEP-420 namespace packages (typified by
> https://salsa.debian.org/python-team/packages/zope.interface/-/commit/a8c7881b1a).
> Fortunately pytest provides IMO rather convenient ways to hook in and
> gently tweak the import system just before it tries to import the
> modules under test, which I think is better in this context than
> bringing up a virtualenv or whatever.
> 
> I'd be happy to do a bit more of this sort of thing.
> https://veronneau.org/debian-python-team-2022-sprint-report.html said
> that around 29 of 67 team-maintained packages were fixed during the
> sprint, which means I'm going to have a slightly annoying hit rate if I
> have to just go through this email to find targets.  Is there somewhere
> else where the current list of target packages is being maintained, or
> would it be possible to do this mass bug-filing at sub-RC level so that
> there's a convenient list in the BTS?
This is the list we used during the sprint to coordinate:

https://pad.riseup.net/p/FixSetupTest-keep

It's probably outdated though and I feel a real MBF would be helpful to 
keep track at this point...

-- 
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
   ⠈⠳⣄

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

#14718

On 11/12/2022 11:50, Louis-Philippe Véronneau wrote:
> On 2022-12-10 17 h 09, Colin Watson wrote:
>> On Mon, Aug 15, 2022 at 06:27:22PM +0000, Stefano Rivera wrote:
>>> Calling "setup.py test" has been deprecated since setuptools 28.5.
>>> That's 6 years ago.

> This is the list we used during the sprint to coordinate:
> 
> https://pad.riseup.net/p/FixSetupTest-keep
> 
> It's probably outdated though and I feel a real MBF would be helpful to 
> keep track at this point...

Yep, let's get an MBF in place for this. The BTS with usertags (or the 
BTS view through UDD with usertags) is a much better way of tracking a 
todo list at this stage.

I'm not sure if there is a published deprecation timeline for "setup.py 
test", but given the number of nasty surprises we've had from setuptools 
over the last year with their current break-it-and-see-who-complains 
development paradigm, let's assume the worst.

Given it's not currently broken, I guess it would start with 
severity:important and become severity:serious once setuptools stops 
supporting this?

Assuming that we're not going to suddenly get a breaking setuptools 
before bookworm, the MBF text should have a note that this will not 
become serious before the release of bookworm. (Do we know if that is true?)


cheers
Stuart


-- 
Stuart Prescott   http://www.nanonanonano.net/ stuart@nanonanonano.net
Debian Developer  http://www.debian.org/       stuart@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

[toc] | [prev] | [standalone]

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

csiph-web