Repository navigation
test_parse_strict_noncritical_error_default fails on 3/4 exotic archs with AssertionError: Regex pattern did not match #17141
Description
I think this is caused by one of the OGIP changes that @eerovaher made recently (and @mhvk probably reviewed it). Somehow that change broke a test but only in the matrix of exotic archs job that uses some system libraries (but at a glance I don't see how sys lib can cause this error). This should be resolved before v7.0 is released.
astropy/.github/workflows/ci_cron_weekly.yml
Line 166 in eb98949
def test_parse_strict_noncritical_error_default():
with pytest.raises(
ValueError,
match=(
r"^if 'm\(s\)' was meant to be a multiplication, it should have been "
r"written as 'm \(s\)'\.\n"
"If you cannot change the unit string then try specifying the "
r"'parse_strict' argument\.$"
),
):
> assert u.Unit("m(s)", format="ogip")
E AssertionError: Regex pattern did not match.
E Regex: "^if 'm\\(s\\)' was meant to be a multiplication, it should have been written as 'm \\(s\\)'\\.\\nIf you cannot change the unit string then try specifying the 'parse_strict' argument\\.$"
E Input: "if 'm(s)' was meant to be a multiplication, it should have been written as 'm (s)'."
astropy/units/tests/test_units.py:263: AssertionError
_________________ test_parse_strict_noncritical_error_default __________________
self = <class 'astropy.units.core.Unit'>, s = 'm(s)', represents = None
format = 'ogip', namespace = None, doc = None, parse_strict = 'raise'
Activity
eerovaher commentedon Oct 8, 2024
8b124d3 that was merged yesterday requires
pytest >= 8.0, but the jobs in question use an older version. We already had #16884 for exactly the same reason. The oldest dependencies CI job should catch these kinds of problems, but it doesn't because it's not using oldest dependencies.pllim commentedon Oct 8, 2024
Ah, right!
mhvk commentedon Oct 8, 2024
Ouch! So, I guess the question now is whether again work around the pre-2024 version of
pytestnot being able to handle exception notes, or bite the bullet and insist onpytest>=8.0(and adjust allPYTEST_LT_8_0pieces).neutrinoceros commentedon Oct 9, 2024
I can't remember where but we've had a discussion about when to do this earlier and settled for "at least a year after pytest 8.0 was released"). In any case, I have a personal reminder to execute this when the time comes (sometimes next January).
pllim commentedon Oct 9, 2024
pytest 8.0.0 was only released Jan 27, 2024. I think we try to hold up the "2 years after release" rule of thumb if we can. But looks like pytest isn't covered under SPEC 0 either, so 🤷♀️
mhvk commentedon Oct 9, 2024
I guess it is a bit of a tricky one. For building astropy, there doesn't seem much reason to stick to the same 2 year timeline one has for dependencies needed to run astropy. But testing maybe is a little different (and certainly was, when we could do
astropy.test()).Maybe we should just go with raising the minimum to
pytest>=8.0for astropy 8.0 - almost 2 years and a major release.pllim commentedon Oct 9, 2024
Yes, feel free to comment here: