Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test on current python/django versions, linter config #90

Merged
merged 9 commits into from
Sep 3, 2024

Conversation

chris48s
Copy link
Member

This PR continues the wider platform and version upgrades work I am looking at across DC repos.

Key topics on this one are bumping to current/applicable python/django versions and bringing linter setup into line with other DC projects.

Commit log should be pretty descriptive for this one. I will also leave some comments inline on the diff with a bit of further explanation.

Comment on lines -56 to +49
ruff format .
ruff format . --check
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Running ruff format . in CI isn't really helpful because ruff exits with code 0 even if it changes files, so if files need reformatting, ruff format . will just change them and not fail the build.
In CI we need to run ruff format . --check which will exit with code 1 if filed need reformatting.

Comment on lines +50 to +59
[tool.ruff]
line-length = 80
lint.ignore = ["E501"]
lint.extend-select = [
"I",
"C4",
"SIM",
"Q003",
"RET",
]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the standard config we should be using
See https://docs.google.com/document/d/1Sb_m86KG5ca0lOZMgtJZwch32eVfA0syAY9MeIW1Ljk/edit#heading=h.gnuw7hn63sl7
Note that adding the config here is the reason we now have a load of new errors that need fixing (mostly import sorting)

name: Curly Lint
command: |
curlylint .
git ls-files '*.html' | xargs djhtml --check
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as DemocracyClub/EveryElection#2210 (comment) here for the same reasons

mock_render.called_once_with(
mock_render.assert_called_once_with(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This never did anything because called_once_with isn't a function. Same with the other similar line in this file.

This was not a visible error when running the tests under python 3.10, but python 3.12 introduces a check for this. Related reading:

Comment on lines -4 to +9
py38:
docker:
- image: cimg/python:3.8
py39:
docker:
- image: cimg/python:3.9
py310:
docker:
- image: cimg/python:3.10
py312:
docker:
- image: cimg/python:3.12
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything we care about/where we consume this package should be running python 3.10 or 3.12 now.
We don't need to keep testing for python 3.8/3.9 compatibility.

Comment on lines -73 to +66
django_version: [ ">=3.2,<4.0", ">=4.0,<4.1", ">=4.1,<4.2" ]
python_version: [ py310, py312 ]
django_version: [ ">=4.2,<4.3", ">=5.1,<5.2" ]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything we care about/where we consume this package should now be running Django 4.2.x. We can drop compatibility testing for everything older than that.
I've also added testing on Django 5.1.x so we're flagging any compatibility issues we are likely to encounter when upgrading to Django 5.2.x after the May 2025 elections.

@@ -6,7 +6,7 @@ readme = "README.md"
authors = [{name = "Sym Roe"}, {name = "Virginia Dooley"}]

dependencies = [
"django>=3.2,<4.3",
"django>=4.2",
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, unless we know we're relying on something we know will break in a future release, I'd tend to avoid upper-bound version constraints for python packages.

@chris48s
Copy link
Member Author

TODO: once this is approved, cut a release after merging

@VirginiaDooley
Copy link
Contributor

I tested this by installing it locally in Website. Is the plan to remove pyproject.toml from upstream repos or is there further configuration needed to designate which pyproject.toml should be used in the event that more than one is found?

@VirginiaDooley
Copy link
Contributor

I tested this by installing it locally in Website. Is the plan to remove pyproject.toml from upstream repos or is there further configuration needed to designate which pyproject.toml should be used in the event that more than one is found?

Chris and I had a chat about this and he explained more about how pyproject.toml works so all sorted now.

@chris48s chris48s merged commit e66e3bf into main Sep 3, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants