chore: wheel not required for setuptools PEP 517 (all-repos)

[henryiii]

Committed via https://github.com/asottile/all-repos

[jpivarski]

@aryan26roy, dropping "wheel" from pyproject.toml is no the change I'm asking you to review (@henryiii did it to many of the Scikit-HEP projects at once; read PEP 517 to find out why).

The test failed because of numerical precision. I wrapped everything in pytest.approx (taking care because it doesn't automatically recurse through nested lists), though I'm not sure why you or GitHub Actions hasn't seen that before. If it's failing now, it should have failed before. We might not be able to figure this out, but I just wanted to give you a chance to look at it before merging it.

[henryiii]

This seems to be trying to run approx on a dict. It does support numpy arrays and lists, but not dicts.

[jpivarski]

I fixed that once. (Or something like that.) I'll look at it again now.

[jpivarski]

Oh, and you can run approx on dicts, just not anything deeper.

>>> {"one": 1.1+1e-12, "two": 2.2+1e-12} == pytest.approx({"one": 1.1, "two": 2.2})
True
>>> [{"one": 1.1+1e-12, "two": 2.2+1e-12}] == pytest.approx([{"one": 1.1, "two": 2.2}])
False

The case that's failing in the tests is a list of dict (like above).

[jpivarski]

I think I have done this before, because the quick fix of deepening everything with list comprehensions with dummy variables x and y is something that I would do. We're seeing this failure because now pytest.approx is looking one level of nesting less than it did before. Are we going backward in pytest versions? I would expect its range of applicability to broaden with time, not narrow.

(In fact, they could implement pytest.approx recursively and make it work for all levels of depth. Oh well.)

[henryiii]

I think you are looking for dirty-equals?

[henryiii]

Let's get this in to un-break things.