Export type information

[hawkaa]

Is your feature request related to a problem?
Kinda. I'm trying to use the opentelemetry-sdk in my mypy enabled project and get the following error message:

uogc/trace.py:1: error: Skipping analyzing 'opentelemetry.sdk.trace': found module but no type hints or library stubs

Describe the solution you'd like
I see that several packages in this repository is using types. However, these types are not published. Publishing the types is actually not that tricky. We just did it for another project, where the dialogue and code changes are referred to in this PR:

developmentseed/geojson-pydantic#5

In addition, the PyPi "Typing :: Typed" tag should probably be included. See https://github.com/hawkaa/pygeojson/blob/master/pyproject.toml#L14 .

Describe alternatives you've considered
I did think about distributing a separate stub library, but all the types are actually available in the original code. Publishing the type information should be an easy change.

Additional context
I don't know how many packages in this repository that actually has type information, and whether it is going to much work to change the workflow in this repository to add the py.typed file and do some changes in the package info.

Let me know what you think and if you have any questions!

[aabmass]

A lot (most?) of the code in opentelemetry-sdk doesn't have type annotations, and we aren't running mypy on the SDK code atm. Issue for that here #773.

All of the annotations in opentelemetry-api should be working (anything not under opentelemetry.sdk).

[hawkaa]

Ah right. I didn't check properly, then. I checked a file or two in the sdk and they seemed to have type annotations, so I concluded most of it had. I'm sorry.

Type information for the SDK would still be handy, either exporting types directly or creating stubs. What do you think? Should we open a ticket for that, and/or retrofit this one? Or does #773 include exporting the types as well?

Let me know what you think!

[aabmass]

@hawkaa no worries! I didn't know about that classifier, it would good to add that. AFAIK the inline types should just work for you as long as we have py.typed files. We can retrofit this issue to track that.

[github-actions]

This issue was marked stale due to lack of activity. It will be closed in 30 days.

[hawkaa]

Looks like they are added now, @aabmass ? :)

[aabmass]

Looks like Owais took care of the py.typed files in #1720

But we do not have the Typing :: Typed classifiers still. Do you think we should still add that @hawkaa ?

[hawkaa]

yes! I'm not sure if there is any practical difference, but I don't see why we shouldn't. Do you want me to try to open a PR to do it?

[flaeppe]

Are there any plans on packaging the type information as well? i.e. PEP 561 (include py.typed as package data)

[ettelr]

Any update on PEP 561 support?