Test and document MYPY_FORCE_COLOR/FORCE_COLOR

[AlexWaygood]

Feature

MYPY_FORCE_COLOR is an environment variable that can be used to, well, force color in mypy's output. It's a useful configuration setting that's used by several projects.

The environment variable is currently undocumented and untested. If #13814 is merged, people will also be able to use FORCE_COLOR to specify the same thing, and that will also be undocumented and untested.

It would be good to add docs and tests for these environment variables.

[AlexWaygood]

For testing these environment variables, we could take inspiration from how termcolor does their testing. For example: https://github.com/termcolor/termcolor/blob/9492a856128015a4cf23d0168e0fb2f4ed8776e0/tests/test_termcolor.py#L105-L127.

[hauntsaninja]

We should definitely document it, but I wouldn't sweat too much about testing it, end-to-end mypy tests are slow anyway

[AlexWaygood]

We should definitely document it, but I wouldn't sweat too much about testing it, end-to-end mypy tests are slow anyway

Yeah the docs part of this is more important, for sure.

[nnrepos]

@AlexWaygood hey, could you explain where should documentation/tests be added for these variables?
thanks

[AmberAnsari89]

Can I add a sub heading under "Using mypy with an existing codebase" as introduced force color to output..and move with testing part...please advise...this is my first comment here .

[AlexWaygood]

hey, could you explain where should documentation/tests be added for these variables?

Hmm... interesting question. It should be documented somewhere in the "Configuring and running mypy" section of the docs. But now that I look, there doesn't seem to be a dedicated page or section for environment variables at the moment -- MYPYPATH is "documented", but the documentation for that environment variable is sort of scattered across various places in in https://mypy.readthedocs.io/en/stable/running_mypy.html#.

Maybe we should add a new documentation page for environment variables. @hauntsaninja, what do you think?

As @hauntsaninja says, maybe don't worry about adding tests for now -- other environment variables appear to be similarly untested, and it might be more trouble than it's worth. Let's focus on docs for now.

Can I add a sub heading under "Using mypy with an existing codebase"

No, I don't think that would be a good place to add documentation for these variables :)

[AmberAnsari89]

Thank you for your reply..please inform where to add the environmental variable.i am ready to contribute my first open source contribution and get confident to move others.. i went through the termcolor module what you mentioned above. it looks doable to include a test function if we build similar def function test_environmental_variable() in a python file..

[AmberAnsari89]

i want to contribute so please assign me a issue which is good for me..

[AlexWaygood]

Thanks @AmberAnsari89! Mypy can be quite a complex codebase for somebody who's completely new to open source, however. You might like to consider helping out over at typeshed, instead :)

We've got lots of incomplete stubs over at typeshed where we'd welcome PRs. For example, there's lots of functions in this file that don't currently have annotations for parameters or return types. If you'd like to help fill out the annotations in that file (or any other file in typeshed where we don't currently have annotations!), that would be great!

[AmberAnsari89]

Thanks, I'll take a look and get back to you for help. Thanks you again..

…

On Mon, 10 Oct, 2022, 2:16 am Alex Waygood, ***@***.***> wrote: Thanks @AmberAnsari89 <https://github.com/AmberAnsari89>! Mypy's can be quite a complex codebase for somebody who's completely new to open source, however. You might like to consider helping out over at typeshed <https://github.com/python/typeshed>, instead :) We've got lots of incomplete stubs over at typeshed where we'd welcome PRs. For example, there's lots of functions in this file <https://github.com/python/typeshed/blob/master/stubs/fpdf2/fpdf/drawing.pyi> that don't currently have annotations for parameters or return types. If you'd like to help fill out the annotations in that file (or any other file in typeshed where we don't currently have annotations!), that would be great! — Reply to this email directly, view it on GitHub <#13815 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKUXK4UZN52AR3F4RUHUJ5LWCMVIPANCNFSM6AAAAAAQ46UFIA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[darshanip]

@AlexWaygood, I'ld love to contribute to typeshed. Please guide me what is required in return types and parameters in drawing.pyi .

[AlexWaygood]

@darshanip great! There's lots of different ways to go about working out what the type annotation should be for a certain parameter or return type. The fpdf source code is pretty readable, and already has a lot of type annotations in the runtime package, so with that package it's often easiest to figure out what the type should be just by reading the source code. Other tools you can use are reading the docs for a package, reading function/class docstrings, or pip installing the package and playing around with it in a Python REPL.

More info in our guide for contributors :)

[Axel-Jacobsen]

Are there any updates on this?

[AlexWaygood]

Are there any updates on this?

None that I'm aware of. If there were any updates, you'd find them in this issue thread. What kind of updates are you looking for here?