Include type checker versions in long description

[srittau]

Cf. python/typeshed#6843

[ilevkivskyi]

Generally I like the idea, but I have one comment and I think it may be worth writing few unit tests for _read_requirements().

[ilevkivskyi]

What if at some point in future someone will (accidentally) write e.g. mypy>=1.5.1?

[AlexWaygood]

Stub-uploader already has packaging as a requirement, so we could use the packaging.requirements.Requirement class to parse each line (once it's been stripped of comments), rather than doing our own parsing. That would simplify this code and also be more robust/better tested.

[srittau]

Edit: The build will fail. I see that as a feature. Using a non-pinned version in typeshed would make tests non-reproducible. Although maybe we could reorganize requirements-tests.txt a bit and add a comment to that effect?

Edit: I will make the fails explicit tomorrow + unit tests.

[AlexWaygood]

I agree that most of our test dependencies (and definitely our type-checker dependencies) in typeshed should be pinned. But if we want to test that, I feel like we should have a dedicated test (or lint) for it, rather than having some unrelated code in stub-uploader inexplicably fail when that rule is broken.

[hauntsaninja]

(We run stub_uploader tests in typeshed, so if you have an integration test that makes sure this works, we should get failures at typeshed PR time)

[srittau]

Generally I like the idea, but I have one comment and I think it may be worth writing few unit tests for _read_requirements().

Good idea, I will do so tomorrow.

[srittau]

typeshed is prepared now. I will add tests and switch to use packaging tomorrow.

[srittau]

Also, commit should probably become part of TypeshedData, but I will send a separate PR after this is merged to keep the changes minimal.

[AlexWaygood]

This looks great to me, and I think will be really useful. Thanks @srittau!