Enable using mypy manually

[MarcSkovMadsen]

In #7079, @gandhis1 contributes a typing improvement. In order to be able to review this PR I would like to run mypy.

This PR configures the project in such a way that you can

• run pip install -e .[mypy] to install the mypy dependencies
• run mypy path/to/file.py to check a specific file.

It removes the errors raised about missing stubs and dependencies that do not support typing.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.21%. Comparing base (ad94551) to head (0b72a5a).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7081      +/-   ##
==========================================
- Coverage   82.22%   82.21%   -0.02%     
==========================================
  Files         326      326              
  Lines       48536    48536              
==========================================
- Hits        39908    39903       -5     
- Misses       8628     8633       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[hoxbro]

I pushed some changes so we can see the result of type checking in the CI. I have set the CI to never fail, but this should be removed at some point.

[gandhis1]

So this works, however I think what you choose to run depends on what you are looking to do. My original issue was concerned primarily with the public API, and to run Mypy on the files changed would also be checking elements of the private API and library internals.

Ideally, you would want to run Mypy on panel itself and check for / catch issues / validate annotations, but that would expose a larger number of errors to fix.

If we want to check the public API, I think the best thing would be to run mypy in strict mode on the examples folder, and when all the issues are fixed, adding it to the CI as well.

[gandhis1]

I ran Mypy in the same way you were @MarcSkovMadsen and I got a bunch of additional errors on unrelated files. At least for now, maybe it's worth turning off the unrelated file errors?

Suggested change

	exclude = []
	exclude = []
	follow_imports = "silent"

From https://mypy.readthedocs.io/en/stable/running_mypy.html#following-imports:

If you are starting a new codebase and plan on using type hints from the start, we recommend you use either --follow-imports=normal (the default) or --follow-imports=error. Either option will help make sure you are not skipping checking any part of your codebase by accident.

If you are planning on adding type hints to a large, existing code base, we recommend you start by trying to make your entire codebase (including files that do not use type hints) pass under --follow-imports=normal. This is usually not too difficult to do: mypy is designed to report as few error messages as possible when it is looking at unannotated code.

Only if doing this is intractable, we recommend passing mypy just the files you want to type check and use --follow-imports=silent. Even if mypy is unable to perfectly type check a file, it can still glean some useful information by parsing it (for example, understanding what methods a given object has). See Using mypy with an existing codebase for more recommendations.

[MarcSkovMadsen]

I don't think we should change it with the argument that what we want to check in the pipeline is everything as that is the end goal for the Panel project to have no issues whether internal facing or external facing.

I believe for "the current effort" which is focused on outward facing api we should add the relevant settings via flags manually when running mypy manually. Makes sense?

[gandhis1]

LGTM