Publish each stubs as stub-only package

[eggplants]

Please publish each stubs to PyPI as stub-only packages like python/typeshed.

I would like to see *-stubs (or *-ms-stubs?) in PyPI soon!

Or should I wait for them to be merged to typeshed as the README says?

[gramster]

I agree this is a good idea, and easier than meeting the criteria for typeshed.

[fhocutt]

Our project uses netaddr - would appreciate similar if they're not likely to meet the typeshed criteria anytime soon.

[Avasam]

+1 On this. I'd like to have access to these stubs, even if incomplete. For now I have to copy the ones I use in the typings folder of my project, which is quite cumbersome. I would also like to move away from https://github.com/Avasam/pywin32-stubs / https://github.com/kaluluosi/pywin32-stubs and instead use and improve the pythonwin and win32 stubs found here.

I don't even need them on PyPi, available from github would be fine for me, but trying to run pip install git+https://github.com/microsoft/python-type-stubs.git results in the following:

``` Collecting git+https://github.com/microsoft/python-type-stubs.git Cloning https://github.com/microsoft/python-type-stubs.git to c:\users\avasam\appdata\local\temp\pip-req-build-unelvtus Running command git clone --filter=blob:none --quiet https://github.com/microsoft/python-type-stubs.git 'C:\Users\Avasam\AppData\Local\Temp\pip-req-build-unelvtus' Resolved https://github.com/microsoft/python-type-stubs.git to commit 0aa15ddf9f6ec4c38b822306d3e05b45e22b6680 Installing build dependencies ... done Getting requirements to build wheel ... error error: subprocess-exited-with-error × Getting requirements to build wheel did not run successfully. │ exit code: 1 ╰─> [14 lines of output] error: Multiple top-level packages discovered in a flat-layout: ['cv2', 'django', 'pygame', 'netaddr', 'jmespath', 'openpyxl', 'pendulum', 'tenacity', 'matplotlib', 'sqlalchemy']. To avoid accidental inclusion of unwanted files or directories, setuptools will not proceed with this build. If you are trying to create a single distribution with multiple packages on purpose, you should not rely on automatic discovery. Instead, consider the following options: 1. set up custom discovery (`find` directive with `include` or `exclude`) 2. use a `src-layout` 3. explicitly set `py_modules` or `packages` with a list of names To find more information, look for "package discovery" on setuptools docs. [end of output] note: This error originates from a subprocess, and is likely not a problem with pip. error: subprocess-exited-with-error × Getting requirements to build wheel did not run successfully. ╰─> See above for output. note: This error originates from a subprocess, and is likely not a problem with pip. ```

[eggplants]

It would be nice if stub_uploader could be introduced to this project as well as typeshed. https://github.com/typeshed-internal/stub_uploader

[hauntsaninja]

Hello @gramster !

I'm a maintainer of typeshed. First and foremost, thanks for all your work here. These are widely used libraries so having stubs for them is great — so great that it would be nice to be able to install them from PyPI ;-)

But if we're at that point, it's worth considering why stubs aren't in typeshed to begin with. typeshed attracts a lot of potential contributors interested in improving the ecosystem. We also have a lot of tooling in place, e.g. automation to release stubs to PyPI.

So I'm interesting in talking about:

easier than meeting the criteria for typeshed.

Maybe my memory is terrible and I'm forgetting some discussion somewhere. But https://github.com/python/typeshed/issues?q=is%3Aissue+is%3Aopen+commenter%3Agramster also doesn't have very much to go on. But I'd love to know what painpoints you've encountered when upstreaming things previously?

Potential guesses:

• Some typeshed policies aren't aligned with what Microsoft is getting at here, e.g. maybe there's been hesitance about stub quality?
• typeshed CI takes a lot of effort to get green
• typeshed typically caters to lowest common denominator features supported by type checkers

Anyway, I'd love to hear back and get a better understanding of the concerns on your end! And apologies if I'm totally forgetting some prior discussion; I'd appreciate any links if so.

[gramster]

@hauntsaninja , we worked on a number of stubs around the launch of pylance to get a decent experience on common packages. Several of those stubs were upstreamed to typeshed. Post pylance launch the stubs here are mostly just worked on by me in my spare time (last I did pandas, with a lot of help from @Dr-Irv , now I am doing matplotlib). When I was doing the pandas stubs I tried meeting the criteria for typeshed submission (running mypy against the stubs), and I had a lot of reported issues, and fixing those issues would have cost me a lot of time without necessarily helping much for the pylance editing experience. But my goal with all of these stubs is to not own them forever, so ideally they do all eventually end up either in typeshed or handed off to the package owners.

[Avasam]

[...] fixing those issues would have cost me a lot of time without necessarily helping much for the pylance editing experience. But my goal with all of these stubs is to not own them forever [...]

I am mainly interested in pywin32 (https://github.com/Avasam/pywin32-stubs) and cv2 (https://github.com/Avasam/Auto-Split/tree/main/typings/cv2-stubs) and I have contributed to typeshed in the past. I understand you would prefer not spending your own time on meeting typeshed criterias, but maybe a community member (like myself) could? I could also help further complete the aforementionned stubs (for now I've just been adding what I needed as I encountered issues and missing types). I know #213 is currently a big issue with cv2.

At the very least, being able to install types from here until they're moved to typeshed/original package would be a significant boon.