Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

feat: add legacy type compatibility aliases for v1.x migration #69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
zeke wants to merge 3 commits into main from dp-659-legacy-type-aliases

Conversation

@zeke
Copy link
Member

@zeke zeke commented Sep 23, 2025

This PR addresses DP-659 by adding backward compatibility aliases for legacy v1.x type names to ease migration to v2.x.

Changes

  • Created replicate/model.py module with legacy import paths
  • Aliased Model, Version, and Prediction types from their current locations
  • Added ModelResponse and VersionResponse aliases for response types
  • Added comprehensive tests for isinstance() checks and type annotations

Testing locally

gh repo clone replicate/replicate-python-stainless
cd replicate-python-stainless
gh pr checkout 67
rye sync
rye run pytest tests/test_legacy_compatibility.py -v

Prompts

work on this issue: https://linear.app/replicate/issue/DP-659/add-legacy-type-compatibility-aliases

zeke added 2 commits September 22, 2025 17:36
Adds support for the legacy api_token parameter in both Replicate and
AsyncReplicate client initialization as an alternative to bearer_token.
This enables backward compatibility with v1.x client code that uses:
- Client(api_token="...")
- AsyncClient(api_token="...")
The implementation:
- Accepts both api_token and bearer_token parameters
- Raises clear error if both are provided
- Maps api_token to bearer_token internally
- Maintains existing environment variable behavior
- Includes comprehensive test coverage
This PR addresses DP-659 by adding backward compatibility aliases for legacy v1.x type names to ease migration to v2.x.
## Changes
- Created `replicate/model.py` module with legacy import paths
- Aliased `Model`, `Version`, and `Prediction` types from their current locations
- Added `ModelResponse` and `VersionResponse` aliases for response types
- Added comprehensive tests for isinstance() checks and type annotations
## Impact
This allows existing code using v1.x type imports like `from replicate.model import Model` to continue working with v2.x, reducing breaking changes during migration.
@zeke zeke requested a review from a team as a code owner September 23, 2025 15:02
Copy link

linear bot commented Sep 23, 2025

DP-659 Add legacy type compatibility aliases

Problem

The legacy replicate-python v1.x client used different type names for type checking:

from replicate.model import Model
if isinstance(result, Model):
 print(result.name)

The new v2.x client uses different type names:

from replicate.types import ModelGetResponse
if isinstance(result, ModelGetResponse):
 print(result.name)

This breaks existing type checking code when migrating to v2.x.

Solution

Add compatibility aliases and import paths for legacy type names:

  • replicate.model.Model → alias for appropriate response types
  • Consider other legacy types that may need aliases

Implementation Notes

Create aliases for legacy type names

  • Add replicate.model module for backward compatibility
  • Map legacy types to appropriate new response types
  • Add tests for both legacy and new type checking patterns
  • Consider impact on type checkers (mypy, pyright)

Impact

This would reduce breaking changes for codebases that use type checking with isinstance() calls or type annotations.

@zeke zeke force-pushed the dp-659-legacy-type-aliases branch from 2238a50 to 617b0ff Compare September 23, 2025 15:07
The copy() methods need the same api_token parameter as __init__ to maintain
signature consistency for the test suite.
This automatically infers the `bearer_token` argument from the `REPLICATE_API_TOKEN` environment variable if it is not provided.
For legacy compatibility, you can also pass `api_token` instead of `bearer_token`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, not a fan of the term "legacy" here, that won't age too well (legacy is relative). I think it would be better to mention a major version number instead?

zeke reacted with thumbs up emoji
Copy link
Collaborator

@dgellow dgellow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks fine to me, the only thing I would change is the terminology. I think something like "For backward compatibility with v1.x, blablabla" instead of legacy.

I think you could also document api_token as deprecated 🤔

Copy link
Collaborator

dgellow commented Oct 9, 2025

@zeke Is this PR something you want to get merged before the release?

Copy link
Member Author

zeke commented Oct 10, 2025

Scrapping this per our IRL discussion yesterday. If it turns out to be an issue during the beta period we can revisit this.

@zeke zeke closed this Oct 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@dgellow dgellow dgellow left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

AltStyle によって変換されたページ (->オリジナル) /