error: Skipping analyzing 'flask_mysqldb': found module but no type hints or library stubs

You are getting this error because mypy is not designed to try type checking every single module you try importing. This is mainly for three reasons:

1. The module you’re trying to import could be written in a way that it fails to type check. For example, if the module does something like my_list = [] in the global scope, mypy will ask for a type hint since it doesn’t know what this list is supposed to contain.

   These sorts of errors are out of the control of people using the libraries, and so it would be annoying and disruptive to potentially spam them everywhere.

2. Even if the library module you’re trying to import type checks cleanly, if it’s not using type hints, you won’t gain much benefit from trying to use it with mypy. If the library is dynamically typed, mypy could silently accept code that actually does not type check at runtime.

   This can be surprising to people/silently doing the wrong thing is generally a bad idea. Instead, you get an explicit warning.

3. Not all modules are written in Python — some modules are actually C extensions. Mypy cannot analyze these modules and so must implement some mechanism for ignoring modules.

If you do not get this error, this means one of five things:

1. The type hints for your library already exist in Typeshed, which comes pre-bundled with mypy. Typeshed mostly contains type hints for the standard library and a handful of popular 3rd party libraries.

2. The library is already using type hints and declared that it wants to be analyzed and type checked by mypy. This is done by including a special py.typed file within the package which makes it PEP 561 compatible.

3. You’ve installed a 3rd party “stubs-only” package. This package can be installed alongside the library and lets people provide type hints without having to modify the library itself. For example, the django-stubs package contains type hints for the Django library, which is not PEP 561 compatible.

4. You’ve configured mypy to use your own custom stubs. That is, you’ve basically created your own local “stubs-only” package and told mypy to use it.

5. You’ve decided to suppress the error and live with the fact that the library is dynamically typed for now — for example, by using the command line flags you found or by adding a # type: ignore to the import.

For more details on how to deal with this error, see the mypy docs on dealing with missing type hints from 3rd party libraries.