Closed khaeru closed 3 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 95.4%. Comparing base (
023b91a
) to head (d7c5f4f
).
…which does not seem future-proof. Maybe there's no need to comply with this option yet, but there will be and I think I'd like to see warnings before running into this wall. So maybe we should plan for some time to be allocated to manually enable CoW again and check that everything on our side still works as intended.
Totally agree with the thinking here.
Looking at khaeru/genno#133, notice the new fixture parametrize_copy_on_write. I used it via this setting: https://github.com/khaeru/genno/blob/57411be974d21f92b388f5d07913237e6fd58d91/pyproject.toml#L100-L102
So the steps to test ixmp or others would be:
pytest_plugins = (…, "genno.testing", …)
in conftest.py.CoW does indeed cause errors in our stack; for instance at iiasa/message_data#545 I found out that the change_technical_lifetime utility has code that does not work with CoW and will need an update. So I think it is prudent to do such checks.
We might have to pin plotnine to 0.13.1 for this.
I also notice now that plotnine itself has capped pandas < 3.0.0: https://github.com/has2k1/plotnine/blame/main/pyproject.toml#L27 —this could lead to the same kind of problem we've had with pyam, where a pin/cap introduced in recent versions causes pypi to resolve a dependency with an older version (without the pin/cap), leading to indirect weirdness that's hard to diagnose and work around. (Maybe there needs to be an essay like “Upper bounds on Python package dependencies considered harmful”.) We should not willingly create this kind of headache for ourselves and others, so where certain bounds on dependency versions are needed temporarily we should continue to handle those within CI workflows, not in pyproject.toml/releases.
As for this PR, I have not thought through all the user implications, but I guess:
So based on this logic I'd be okay to close the PR without merging.
We might want to cherry-pick d7c5f4f at least. Should I add it to #798?
We might want to cherry-pick d7c5f4f at least. Should I add it to #798?
Please do.
Done for now, until we come back via #804.
Use khaeru/genno#133 to work around has2k1/mizani#38.
Depending on changes made upstream in dask-expr, mizani, or others, this change could be later reverted; it's only for CI to pass.
How to review
Read the diff and note that the CI checks all pass.
PR checklist