Enable (partial) type hinting for downstream consumers

[schuylermartin45]

Checklist

• I added a descriptive title
• I searched open requests and couldn't find a duplicate

What is the idea?

We should enable or partially enable type hinting support for the sake of projects that use conda.

Why is this needed?

My team heavily relies on the VersionOrder class to perform comparisons between software version numbers. We have started using mypy to statically verify our python code against most (and eventually all) of our projects.

When I import the VersionOrder class and the InvalidVersionSpec exception, mypy treats them as Any types and can't resolve that they are classes.

I know some parts of the project use type hinting but it isn't universal. For my particular use case, I just need a few classes exposed to mypy.

What should happen?

From memory this should be as simple as adding a py.typed file to the conda/ directory or we could slowly roll it out and enable it in a few folders at a time.

Additional Context

I believe the PR is simple, but it might be a little controversial. Getting full and accurate type hints for the entire conda project is a obviously a big ask and not what I need right now. BUT, saying we support full type hints when we don't could also be confusing and problematic for others.

For now, I can suppress mypy in my project as a work around. But it would be nice not to have to disable static analyzer checks everytime I try to use this class.

[travishathaway]

Hi @schuylermartin45,

As I started working on my conda-auth plugin, I also ran into to mypy errors, see here:

• Add py.typed marker to conda #13106

I have since added py.typed file to the conda project, so I believe everything is already in place. This has been available since version 23.9.0. Are you perhaps using an older version of conda?

If there's something else that needs to be done to make these classes more "typing friendly", we'd be happy to help make that happen. Feel free to submit your own pull requests too.

[schuylermartin45]

I completely missed that file when I briefly searched for it yesterday. This is what I get for not using search.

I appear to be on 23.10.0. Here are the messages I get from mypy:

anaconda_packaging_utils/api/repodata_api.py:206: error: Call to untyped function "VersionOrder" in typed context 
[no-untyped-call]
                self_v = VersionOrder(self.version)
                         ^~~~~~~~~~~~~~~~~~~~~~~~~~
anaconda_packaging_utils/api/repodata_api.py:207: error: Call to untyped function "VersionOrder" in typed context 
[no-untyped-call]
                other_v = VersionOrder(other.version)
                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
anaconda_packaging_utils/api/repodata_api.py:209: error: Expression has type "Any"  [misc]
                if self_v == other_v:
                   ^~~~~~~~~~~~~~~~~
anaconda_packaging_utils/api/repodata_api.py:211: error: Returning Any from function declared to return "bool" 
[no-any-return]
                return self_v < other_v
                ^~~~~~~~~~~~~~~~~~~~~~~
anaconda_packaging_utils/api/repodata_api.py:211: error: Expression has type "Any"  [misc]
                return self_v < other_v
                       ^~~~~~~~~~~~~~~~
anaconda_packaging_utils/api/repodata_api.py:212: error: Expression type contains "Any" (has type
"type[InvalidVersionSpec]")  [misc]
            except InvalidVersionSpec:

I guess what its actually mad about is that the parameters to the constructor are untyped and I just made an assumption typing wasn't being presented in the package. Still not sure what the issue with the exception is, but I can make a quick PR to add type hints to VersionOrder at least.

[schuylermartin45]

Ah, it seems none of the exceptions are typed, so the Any is coming from the exception constructor (and maybe inheritance?) as well.

[schuylermartin45]

Closing as the type hinting PR got merged and should be sufficient for my needs.