-
Notifications
You must be signed in to change notification settings - Fork 1.1k
PYTHON-5382 - Add a test with min dependencies #2410
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
Conversation
Using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does this install the lowest version of dnspython we support? And don't we need to actually run a test suite that uses dnspython to confirm compatibility?
Good catch, the |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
uv venv | ||
source .venv/bin/activate | ||
uv pip install -e ".[test]" --resolution=lowest-direct | ||
pytest -v test/test_srv_polling.py |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I just noticed this was test_srv_polling but test_dns would probably be a better choice. Or both? And should we do both sync and async?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost all of the test_dns
tests require a sharded or replica cluster. We can add it here anyway, but it'll only add a handful of tests. And good catch, we should run sync and async tests here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah okay then, could you add a comment explaining why we use test_srv_polling only and not test_dns?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like test_dns's mocking is not compatible with dnspython 1.0. Perhaps it's not worth it to add in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And unfortunately there's no resolver.query
method for the async resolver. I'll add a comment that the async test_dns
is not compatible with dnspython 1.x, which is consistent with our docs for the async API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a separate test for dnspython 2.0 for async support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ended up having to use dnspython 2.1.0, as 2.0.0 does not include the lifetime
kwarg we pass to our resolve
calls, but only for the async API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that mean we have to update our docs and error message to say >=2.1 is required for async?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I'll file a follow-up ticket for those changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No description provided.