[BUG]: Use stdlib override when possible

[edrogers]

Description of changes

Fixes #5554

This PR uses typing.override in favor of the overrides dependency when possible. As of Python 3.12, the standard library offers typing.override to perform a static check on overridden methods.

Motivation

Currently, overrides is incompatible with Python 3.14. As a result, any package that attempts to import overrides using Python 3.14+ will raise an AttributeError. An issue has been raised and a pull request has been submitted to the GitHub repo for the overrides project. But the maintainer has been unresponsive.

To ensure readiness for Python 3.14, this package (and any other package directly depending on overrides) should consider using typing.override instead.

Impact

The standard library added typing.override as of 3.12. As a result, this change will affect only users of Python 3.12+. Previous versions will continue to rely on overrides. Notably, the standard library implementation is slightly different than that of overrides. A thorough discussion of those differences is shown in PEP 698, and it is also summarized nicely by the maintainer of overrides here.

There are 2 main ways that switching from overrides to typing.override will have an impact on developers of this repo.

1. typing.override does not implement any runtime checking. Instead, it provides information to type checkers.
2. The stdlib does not provide a mixin class to enforce override decorators on child classes. (Their reasoning for this is explained in the PEP.) This PR disables that behavior entirely by replacing the EnforceOverrides.

• Improvements & Bug fixes
  • The package won't crash in a Python 3.14 runtime due to overrides incompatibility
• New functionality
  • In Python 3.12+, the override decorations will not have a runtime impact. They merely expose information to static analysis tools

Test plan

After applying these changes, I'm able to import the modules locally in Python 3.14.0rc2 without errors. I don't have a plan to write tests. Open to suggestions

Migration plan

I've updated the pyproject.toml to use a PEP508 compliant dependency specifier so that overrides need not be installed for users of newer Python versions.

Observability plan

I don't have a plan at this time. Open to suggestions.

Documentation Changes

As far as I can tell, the change to the decorators doesn't have a user-visible impact, and therefore shouldn't necessitate docstring or documentation updates

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

[propel-code-bot]

Transition from overrides to typing.override for Python 3.12+ Compatibility

This PR updates the codebase to use the standard library's typing.override decorator when the runtime Python version is 3.12 or newer, instead of the third-party overrides package. All references to overrides are now version-guarded, ensuring backward compatibility for Python <3.12 and eliminating import-time errors with Python 3.14+, where the overrides package currently breaks due to upstream maintenance lag. The dependency specification for overrides in packaging files (pyproject.toml, requirements.txt) has also been updated to require the package only on Python versions older than 3.12. Import and decorator usage have been refactored project-wide, including a stub implementation for EnforceOverrides when using typing.override (since the stdlib does not provide a runtime checking class), and all module imports are now explicit about which override implementation is used, depending on Python version.

Key Changes

• Introduces conditional imports: uses typing.override on Python >= 3.12, falls back to overrides.overrides as override otherwise throughout all code that previously used overrides.
• Adds a fallback, no-op EnforceOverrides stub class for Python >= 3.12, where the runtime enforcement feature is not available.
• All decorator usages of @overrides are migrated to @override, with conditional import blocks added at the top of each relevant file.
• Packaging files (pyproject.toml, requirements.txt, and client files) updated so that overrides is only a dependency for Python < 3.12 using the appropriate environment markers.
• Removes strict reliance on overrides from all test suites, core modules, and sample files by introducing guarded imports and standardized decorator usage.
• No behavioral changes to business logic or collection/user APIs; all changes are import/pathing/decorator related.
• Removes duplicate or unnecessary overrides imports.
• Ensures that the codebase will not crash at import time on Python 3.14+, addressing an upstream AttributeError.

Affected Areas

• chromadb/errors.py and all major modules/submodules (API, config, segment, execution, db, tests)
• All test files and sample scripts using the overrides decorator
• Packaging files: pyproject.toml, clients/python/pyproject.toml, clients/python/requirements.txt
• GRPC client/server implementations
• Any class previously inheriting from EnforceOverrides

This summary was automatically generated by @propel-code-bot