feat: add py.typed marker so mypy uses the shipped type hints (#234)

[keel-code-review-tc]

Issue #234

Describe your changes

together is a fully annotated package — [tool.mypy] runs with strict = true — but it ships no PEP 561 py.typed marker, so type checkers treat it as untyped. Anyone running mypy against a project that imports it gets:

error: Skipping analyzing "together": module is installed, but missing library stubs or py.typed marker  [import-untyped]

The only workaround today is a per-project follow_untyped_imports override, repeated in every consumer. Adding the marker tells mypy the inline annotations that already exist are authoritative, so downstream users get real type checking against this SDK instead of Any.

What's in this PR:

• src/together/py.typed — the marker file, inside the package so it lands next to __init__.py in the installed distribution. Its contents are ignored by the spec; the file's presence is the signal.
• tests/unit/test_py_typed.py — asserts the marker is present relative to the imported together module, not relative to the repo tree. That distinction matters: resolving it through together.__file__ means the test fails if the marker is ever dropped from the built wheel, which is the failure mode that would silently bring the original error back for users while looking fine in-tree.

Worth noting tests/unit/test_imports.py already skips *.typed files when walking src/together/*, so the marker was anticipated there and needs no change to that test.

One thing for a maintainer to confirm before merge. [tool.poetry] declares no explicit packages, so Poetry auto-detects src/together and includes non-Python files found inside the package directory — which should carry py.typed into both the sdist and the wheel with no packaging change. I could not build a wheel here to prove it, so this is unverified rather than asserted. Please check the built artifact contains together/py.typed (unzip -l dist/*.whl | grep py.typed). If it does not, the fix is an explicit include entry in pyproject.toml scoped to both formats — happy to push that follow-up. The new test is what would catch this against an installed build.

---

Authored by Keel via the GitHub API as a DRAFT pull request. It awaits human review and is gated by CI (the agent runs no tests locally). Do not merge without an approving human review.

[broly-code-security-scanner]

Broly Security Scan

Note

✅ Clean scan
No vulnerabilities detected in this PR.

Note

Re-scan this PR anytime with /broly scan — useful after /broly undismiss, or to refresh findings without a new push.

Broly — SAST (zai-org/GLM-5.2) · Secrets · SCA · IaC · GH Actions · Base Images · Supply Chain Threats · Exploit Chains · Adversarial Verification

We're continuously improving Broly's accuracy and finding quality — your feedback is valuable. False positives, missed findings, bugs, and feature requests all welcome.

 

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.