Add py.typed marker to cosmology - #20568

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

Just a note that we should double check that this actually works - I thought it could only be defined at a package level

I agree this should be tested. https://peps.python.org/pep-0561/#packaging-type-information indicates that the PEP says it should work. But IDK what mypy does.

Verified that astropy/cosmology/py.typed is included in the source distribution. I also built a minimal test package with a subpackage-level marker and confirmed that demo/cosmology/py.typed was included in its wheel.

Tested mypy against the installed test package, but it inferred the same types after I removed the marker, so this test did not establish whether mypy's behavior depended on py.typed.

I haven't verified whether Astropy's actual wheel includes the marker. My local wheel build failed because the required Microsoft Visual C++ build tools were unavailable.

Is there a preferred test for verifying that mypy recognizes a py.typed marker placed inside a regular subpackage, such as astropy/cosmology/py.typed?

@gitpsii do you use WSL2? You might be able to grab C lib stuff off conda that way, but it has been a while since I used it, so I am not 100% sure.

Thanks for the suggestion! I currently don't have enough disk space to set up WSL2 and build Astropy in a Linux environment.

I verified that astropy/cosmology/py.typed is included in the source distribution. I also built a minimal test package with a subpackage-level marker and confirmed that demo/cosmology/py.typed was included in its wheel.

Would it be possible to verify the marker's inclusion in Astropy's wheel through an existing CI job, or is there a lighter-weight test you would recommend?

On the topic of checking the wheels: we should configure our test Linux wheel job to upload the artifact to actions so people can download it and check in situations like this.

@Cadair, a good idea! I opened an issue based on that comment. Feel free to edit it :)

Thanks @gitpsii!
I'd rather have this than not, even if it might be a no-op :)

Thanks for the review and for opening the follow-up issue! I appreciate the guidance. I'm glad this also highlighted a way to make wheel inspection easier for future contributors.