MAINT strict mypy checking

[romanlutz]

Is your feature request related to a problem? Please describe.

We currently have strict mypy checking disabled. Turning that on in pyproject.toml via

strict = true

causes 991 errors in 177 files as of 12/21/2025.

We should tackle these module by module. Help is explicitly encouraged but please comment in this thread claiming a module.

• pyrit/analytics
• pyrit/auth
• pyrit/auxiliary_attacks
• pyrit/chat_message_normalizer
• pyrit/cli
• pyrit/common @AryanBagade
• pyrit/datasets
• pyrit/embedding
• pyrit/exceptions
• pyrit/executor
• pyrit/memory
• pyrit/models @AryanBagade
• pyrit/prompt_converter
• pyrit/prompt_normalizer
• pyrit/prompt_target
• pyrit/scenario
• pyrit/score
• pyrit/setup
• pyrit/ui

To validate, run pre-commit run mypy --files pyrit/<module/*.py

[romanlutz]

Maybe it would be even better to just replace with ty since it's meant to be orders of magnitude faster and mypy is so painfully slow... and then do this series of fixes with ty rather than mypy.

[AryanBagade]

@romanlutz if its open for external contributors, shall i work on

• pyrit/backend
• pyrit/chat_message_normalizer
• pyrit/cli

[romanlutz]

Definitely open for contributions! I was a bit too fast with adding backend into this list because it doesn't exist yet. The others do, of course. That said, you may have to figure out how to configure the pre-commit hooks to run "strict" mode on only a selected subset of modules. I've tried a couple of things today that didn't quite succeed (i.e., overriding in pyproject.toml). It turns out when you enable strict mode mypy tracks all imports back through other modules so you end up checking quite a bit more unless you start from a very foundational module like common, models, auth, datasets. cli builds on top of everything else so I would leave that for the end.

[AryanBagade]

Got it, that makes sense 👍
I’ll start with the foundational pieces like common and models (if needed) and get those solid under strict mode first, then move upward gradually.

[romanlutz]

Thank you! It's sometimes tempting to do all of them or quite a few at a time but there are lots of people working on the repo and chances are things get stale before you have a chance to merge it and it's more pain than necessary hence the recommendation to split it by module. I'll reserve those two for you.

[AryanBagade]

Hey @romanlutz, started digging into this!

Noticed there's a circular dependency between common and models:

• common imports ChatMessage, DataTypeSerializer, etc. from models
• models imports YamlLoadable, PATHS_DICT, combine_dict from common

So enabling strict mode on one pulls in the other. Planning to tackle it as:

1. PR 1): pyrit/common - right now all 41 errors fixed, added [[tool.mypy.overrides]] for per-module strict
2. PR 2): pyrit/models

Are you okay with this approach?
Will push the first PR soon, pre-commit passes and tests are green.

[romanlutz]

Oh! Model probably shouldn't depend on common. I need to see why and address that (or suggest how to so that you can). Suggestions welcome 🙂

[AryanBagade]

@romanlutz Here's the actual dependency, these are DEFINED in common/ but imported by models/:

1. YamlLoadable class - defined in common, used only by models:

https://github.com/Azure/PyRIT/blob/main/pyrit/common/yaml_loadable.py#L15-L18

2. PATHS_DICT - path constants defined in common:

https://github.com/Azure/PyRIT/blob/main/pyrit/common/path.py#L67-L84

3. DB_DATA_PATH - path constant:

https://github.com/Azure/PyRIT/blob/main/pyrit/common/path.py#L41-L42

4. combine_dict - utility function:

https://github.com/Azure/PyRIT/blob/main/pyrit/common/utils.py#L40-L56

---

To make models truly foundational, we could:

1. Move YamlLoadable → models/yaml_loadable.py (only used by seed classes)
2. Move path constants → new pyrit/config/paths.py
3. Inline combine_dict (just 5 lines) or move to models

Want me to do this refactor first? Or proceed with strict mypy and tackle separately?
we will go step by step!

[romanlutz]

Indeed! YamlLoadable should just move to models.

The paths are interesting... Perhaps path.py should just be top-level rather than under any particular module. It's certainly not depending on anything else. Notably, that would require adjusting the PYRIT_PATH accordingly.

I'm a little on the fence about combine_dict. There is a dict merge operator now since Python 3.9 with | so we could do

(existing_dict or {}) | (new_dict or {})

instead of

combine_dict(existing_dict or {}, new_dict or {})

at least for the occurrences in pyrit.models to remove the circular import. pyrit.common can keep depending on models, of course.

Does that make sense? Wdyt?

FWIW if you agree I would probably recommend making this change separately or at the very least highlighting it well in your PR so that reviewers notice 🙂 Thanks again for your help!