silence the aiohttp BasicAuth deprecation warning in the test run (the call itself has to stay)

[LeyckerS]

This issue was rewritten on 7 August 2026. The original version asked for the wrong fix and @slegarraga implemented it faithfully in #152 before I caught it. The reasoning and the evidence are in this comment; the short version is that moving proxy credentials into a header breaks them for https downloads, which is all of them. The scope below is what the issue should have said in the first place.

Every test run prints this:

tests/test_proxy_pool.py::test_proxy_pool_load_valid
  moon_download.py:114: DeprecationWarning: BasicAuth is deprecated and will be removed
  in aiohttp 4.0; use aiohttp.encode_basic_auth() with headers={'Authorization': ...} instead
    "auth": aiohttp.BasicAuth(user, passwd),

The BasicAuth call is staying. This issue is only about the noise in the test output.

Why the call stays

moon_download.py:114 builds proxy credentials, and they are handed to aiohttp as proxy_auth. That parameter accepts nothing else:

if proxy_auth and not isinstance(proxy_auth, helpers.BasicAuth):
    raise ValueError("proxy_auth must be None or BasicAuth() tuple")

and helpers.BasicAuth(...) is what emits the warning. aiohttp has deprecated the only type its own proxy_auth parameter accepts, without shipping a replacement for that parameter.

Passing the credentials as a header instead is not a workaround — it changes what goes on the wire. For an https target aiohttp authenticates the proxy on a CONNECT request, so anything in headers= is sent inside the finished TLS tunnel where the proxy cannot read it. Both providers here serve https, so that breaks authenticated proxies on every real download while still passing every unit test. Do not do it.

requirements.txt pins aiohttp>=3.9,<4, so the upper bound holds the actual removal off. When aiohttp 4 ships a proxy-auth API, that is a separate issue and a real one.

The work

Give pytest a filterwarnings entry so this specific warning does not print. The repo has no pytest configuration file at all today, so this means creating one — either pytest.ini or a [tool.pytest.ini_options] block in a new pyproject.toml. Pick whichever you can justify in the PR body; I have no preference beyond it being a deliberate choice.

Two things the entry must get right:

1. Target this warning only. A blanket ignore::DeprecationWarning would hide every future deprecation in every dependency, which is a worse outcome than the noise. Match on the message or the module.
2. Leave a comment pointing at this issue. Otherwise someone reads a suppressed warning in a year, "fixes" it properly, and re-introduces the bug described above. The comment is the actual deliverable here; the config line is two minutes.

Done when

• pytest tests/ -q runs clean with no BasicAuth deprecation output
• An unrelated DeprecationWarning would still be shown — check by adding one temporarily, or by matching narrowly enough that it is obvious from reading
• moon_download.py is unchanged
• The config file explains why the suppression exists and links here

Small — genuinely small this time. Comment to claim it.

[slegarraga]

I will take this one. I will move proxy auth to Proxy-Authorization, confirm the supported aiohttp floor, and update the tests.

[slegarraga]

Correction: PR #152 already implements this exact change and closes this issue, including Proxy-Authorization, the feature-detected fallback, and tests. I will not duplicate it; the existing PR is open and ready for review.

[LeyckerS]

Correcting this issue: the fix I described in it is wrong, and I am sorry — @slegarraga built exactly what I asked for in #152 and it cannot ship.

I wrote that the proxy credentials "belong in Proxy-Authorization". That is true as far as it goes, but I stopped one step short, and the step I skipped is the one that matters. Here is what I should have checked before opening the issue.

aiohttp/connector.py, _update_proxy_auth_header_and_build_proxy_req — the docstring says it outright, "Set Proxy-Authorization header for non-SSL proxy requests and builds the proxy request for SSL proxy requests":

auth = proxy_req.headers.pop(hdrs.AUTHORIZATION, None)
if auth is not None:
    if not req.is_ssl():
        req.headers[hdrs.PROXY_AUTHORIZATION] = auth        # http  → on the request
    else:
        proxy_req.headers[hdrs.PROXY_AUTHORIZATION] = auth  # https → on the CONNECT

For an https target through a proxy, aiohttp opens a tunnel with CONNECT and the proxy authenticates that request. Anything passed in headers= travels inside the finished TLS tunnel, encrypted end to end with the file host — the proxy never sees it and answers 407.

Every download here is https (datanodes.to/api/file/direct_link and the fuckingfast CDN links both), so a header-based fix authenticates against nothing on the exact path the program actually uses. Plain-http targets would work, which is the worst kind of bug: it looks fine in any test that does not go through a real authenticated proxy.

Worse, there is no non-deprecated path at all. proxy_auth still rejects anything that is not a BasicAuth:

if proxy_auth and not isinstance(proxy_auth, helpers.BasicAuth):
    raise ValueError("proxy_auth must be None or BasicAuth() tuple")

and helpers.BasicAuth(...) is the thing emitting the warning. aiohttp has deprecated the only object its own proxy_auth parameter accepts, without shipping a replacement for that parameter. So the warning cannot currently be resolved by changing how we authenticate — only by changing what we send, which is a real behaviour change to dodge a cosmetic warning.

What I should have opened instead, and what this issue now is:

The BasicAuth call stays. If the noise in the test output is worth removing, remove it as noise — a filterwarnings entry, which needs a pytest.ini or a [tool.pytest.ini_options] block since this repo has neither yet — with a comment pointing at this thread so nobody "fixes" it again in six months. The upgrade to a real API waits until aiohttp 4 offers one for proxy_auth.

proxy_headers={"Proxy-Authorization": ...} would reach the CONNECT and is the one header-based approach that works — but only for https, and it reimplements by hand what proxy_auth already does correctly for both schemes. I do not think that trade is worth making.

Relabelling this and rewriting the body accordingly. The mistake was mine: I verified that Authorization was the wrong header and then failed to verify that Proxy-Authorization in headers= was the right one.