Start testing with CPython 3.13

[graingert]

investigate #848

[codecov-commenter]

:warning: Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 92.19%. Comparing base (35650b1) to head (934a7ab). Report is 4 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #862 +/- ## ========================================== + Coverage 91.75% 92.19% +0.43% ========================================== Files 27 27 Lines 1807 1831 +24 Branches 270 346 +76 ========================================== + Hits 1658 1688 +30 + Misses 102 94 -8 - Partials 47 49 +2 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[graingert]

@graingert thanks for the adjustments, much cleaner now. The use of pytest_httpbin.certs.where is a nice idea but the way it's introduced is probably more complex than necessary (and the tight coupling with Python 3.13 support is not clear); also no longer calling load_cert_chain could use an explanation why it's expected to not be needed for all environments (I'm curious, happy to understand).

It's coupled to 3.13 because python 3.13 changed the validation requirements for certificates in the default SSL context, and I updated the pytest-httpbin certs using trustme which names them differently. pytest_httpbin.certs.where() is the public interface to these files, they should not be accessed by filename.

load_cert_chain is needed for server contexts and is redundant here.

The key question should be: what problem are we trying to solve? The answer seem to be: Invoking the test suite without need for REQUESTS_CA_BUNDLE="$(python3 -m pytest_httpbin.certs)" hacks and without default failure — anything else?

No, it's because I renamed the certs in pytest-httpbin because they are the names that trustme uses, and otherwise the tests crash here.

Probably the simplest and backwords-compatible way forward would be a tiny patch that…

* uses `ssl_ca_location = os.environ.get("REQUESTS_CA_BUNDLE", pytest_httpbin.certs.where())`

* starts using `ssl_ca_location` in two places more in the same function

* then drop `REQUESTS_CA_BUNDLE` from `runtests.sh`

Backwards compatibility is not a concern here, it's just in the tests. REQUESTS_CA_BUNDLE is still required in runtests.sh .

If we need any of the other parts of the suggest diff, please share their motivation so that it becomes apparant and documented why we need them. Thank you!

I'm not sure what other parts of the diff you're referring to.

[hartwork]

@graingert thanks for the adjustments, much cleaner now. The use of pytest_httpbin.certs.where is a nice idea but the way it's introduced is probably more complex than necessary (and the tight coupling with Python 3.13 support is not clear); also no longer calling load_cert_chain could use an explanation why it's expected to not be needed for all environments (I'm curious, happy to understand).

It's coupled to 3.13 because python 3.13 changed the validation requirements for certificates in the default SSL context, and I updated the pytest-httpbin certs using trustme which names them differently. pytest_httpbin.certs.where() is the public interface to these files, they should not be accessed by filename.

load_cert_chain is needed for server contexts and is redundant here.

I found your commit https://github.com/kevin1024/pytest-httpbin/commit/7bf62b4e8848ce0990cb8d09b8b630dc4140f41b now, so the VCR.py tests will break with pytest-httpbin>=v2.1.0rc1 unless patched, I see.

I'm not sure what other parts of the diff you're referring to.

The diff in 58ef14708dfaf74bed9a734bf9176bc31125f60d is quite big, e.g. httpbin_ssl_context is also resolved rather than fixing it in place (which would give a tiny diff). If you see value in inlining it after fixing, making that two commits would make things clear. Right now none of the parts are separated and non of the intentions/reasoning are documented. I can demo how I'd do it, if you want.