feat: add legacy type compatibility aliases for v1.x migration#69
feat: add legacy type compatibility aliases for v1.x migration#69
Conversation
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.
DP-659 Add legacy type compatibility aliases
ProblemThe 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. SolutionAdd compatibility aliases and import paths for legacy type names:
Implementation NotesCreate aliases for legacy type names
ImpactThis would reduce breaking changes for codebases that use type checking with isinstance() calls or type annotations. |
zeke
force-pushed
the
dp-659-legacy-type-aliases
branch
from
2238a50 to
617b0ff
Compare
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`. |
There was a problem hiding this comment.
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?
dgellow
left a comment
dgellow
left a comment
There was a problem hiding this comment.
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 🤔
|
@zeke Is this PR something you want to get merged before the release? |
|
Scrapping this per our IRL discussion yesterday. If it turns out to be an issue during the beta period we can revisit this. |
2 participants
This PR addresses DP-659 by adding backward compatibility aliases for legacy v1.x type names to ease migration to v2.x.
Changes
replicate/model.pymodule with legacy import pathsModel,Version, andPredictiontypes from their current locationsModelResponseandVersionResponsealiases for response typesTesting 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 -vPrompts