Suppress the false type error on assigning a CA bundle to verify

[tomchop]

Reported from a downstream pipeline that type-checks this package's source after vendoring it:

ERROR `str` is not assignable to attribute `verify` with type `bool` [bad-assignment]
   --> third_party/py/yeti/api.py:178:36
    |
178 |             authd_session.verify = self._tls_cert

The code is correct

requests documents the field as accepting both:

verify – (optional) Either a boolean, in which case it controls whether we verify the server's TLS certificate, or a string, in which case it must be a path to a CA bundle to use.

Passing a path is exactly what tls_cert exists for.

Why the checker disagrees

requests ships no py.typed and no annotation on the attribute. A checker reading its source therefore infers the type from the only assignment it can see, in Session.__init__:

self.verify = True      # -> inferred as bool

With types-requests stubs it is bool | str and there is no error, which is why this does not reproduce in environments that resolve stubs rather than vendored source.

Change

A bare # type: ignore on both assignment sites, with a comment recording why the assignment is sound.

Both sites — __init__ (line 81) and auth_api_key (line 178). Only the second was reported, but they are the same assignment and the first would surface as soon as that code path is reached by the same analysis.

Bare rather than coded because the rule name differs per checker — assignment for mypy, bad-assignment for ty, reportAttributeAccessIssue for pyright — and a code that does not match the checker in use is itself flagged as an unused suppression. A bare ignore is honoured by all three.

Tests

31 passing, unchanged. This repository has no type-check job of its own, which is why the error only surfaced downstream.