chore: pin the dev requirements to major.minor compatible

[tonyandrewmeyer]

Adjust the dev requirements to be pinned to the latest compatible version of the currently used major.minor version.

This should make breakage like the current issue with flake8 & Python 3 less common, and generally encourage developing using the latest versions of the dev tools (picking up bug fixes and security fixes in particular).

Pyright doesn't use semvar and newer versions have issues with some of the hinting we use (it's unclear whether this is limitations in Python, or a pyright bug, or something we should fix ourselves) so leave it tightly pinned to the same version.

Changes one line of (ops.testing) code to avoid an issue raised by newer flake8 (using != to compare types, rather than is not for an exact match or not isinstance for looser checks).

Temporarily use Python 3.11 for the CI linting check (rather than whatever the setup-python tool provides by default, currently 3.12), to work around an incompatibility between pyproject-flake8 and Python 3.12. This should be reverted when (a) we move away from flake8, or (b) pyproject-flake8 has a fix in a released version.

Temporarily use Python 3.11 for the CI build sdist check. We need to either explicitly install setuptools in that action, or modernise the setup.py to not require it (since we're considering moving to be more purely pyproject.toml, that might end up the solution).

[tonyandrewmeyer]

Hmm, this keeps installing the older flake8. Will check on that.

[tonyandrewmeyer]

Ah, the latest flake8 also has the 3.12 issue.

[tonyandrewmeyer]

Ah, it's not flake8, it's pyproject-flake8. A PR to fix it is still open

[tonyandrewmeyer]

So some options:

1. Move to ruff. This is tentatively scheduled for next sprint anyway. Probably not the ideal time to do it, though.
2. Adjust the Github action to use 3.11 rather than 3.12 (until either we move to ruff or the pyproject-flake8 fix is available).
3. Drop pyproject-flake8 (this would mean moving the tool configs out of pyproject.toml I think, which is a bit backwards considering that we are also planning on going all in on pyproject.toml), potentially temporarily.

[benhoyt]

Thanks for the detailed write-up. I think this is fine in the interim, till either pyproject-flake8 is fixed or we move to Ruff.