Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions pyproject.toml
Original file line number Diff line number Diff line change
Expand Up @@ -48,11 +48,11 @@ litellm = ["litellm>=1.75.9,<2.0.0", "openai>=1.68.0,<1.110.0"]
llamaapi = ["llama-api-client>=0.1.0,<1.0.0"]
mistral = ["mistralai>=1.8.2"]
ollama = ["ollama>=0.4.8,<1.0.0"]
openai = ["openai>=1.68.0,<2.0.0"]
openai = ["openai>=1.68.0,<3.0.0"]
Copy link
Member

@pgrayy pgrayy Jan 9, 2026

Choose a reason for hiding this comment

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

Should we set >=2.0.0? I would want us to be careful about using a 2.x feature that causes problems for customers installing a 1.x version of openai.

Copy link
Member

Choose a reason for hiding this comment

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

It is more work on us to maintain two versions, but >=2 would be a breaking change since you can only import one python version of a dependency

Copy link
Member

Choose a reason for hiding this comment

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

Isn't that something we should accept though? Otherwise we won't be able to use 2.x specific features and so it defeats the purposes of us updating correct?

I guess though technically updating to 2.x allows users to run both openai 2.x and strands directly in the same environment. But then we we need to update our integ/unit tests to run with both 1.x and 2.x.

Copy link
Member

Choose a reason for hiding this comment

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

Do we really need to continue testing 1.x? They published 2.x on 9/30/2025, and havent updated 1.x since. I cant find any guidance on their ongoing support for 1.x, so im guessing they bumped it to just make a breaking change, and arent going to do any more massive feature development in 1.x

So long as we arent impacted by the breaking changes between 1.x and 2.x, I think we can move forward with this pr, especially since dean already called out the main place where this breaking change would be impacting: #975 (review)

Copy link
Member

Choose a reason for hiding this comment

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

Spoke with Patrick and from what we are seeing this would be breaking as it may force customers to upgrade when previously it would have worked. For example if a project previously imported a dependency which has a strict dependency on openai 1.x, they now have no path forward.

So the mechanism to upgrade is through conditional logic as is ubiquitous https://github.com/search?q=%22version.parse%28%22+%22.__version__%29%22&type=code.

However, it would be dangerous for us to continue with a check on ourselves to not break 1.0 users. Meaning we would want integ tests specifically on the various major versions supported.

writer = ["writer-sdk>=2.2.0,<3.0.0"]
sagemaker = [
"boto3-stubs[sagemaker-runtime]>=1.26.0,<2.0.0",
"openai>=1.68.0,<2.0.0", # SageMaker uses OpenAI-compatible interface
"openai>=1.68.0,<3.0.0", # SageMaker uses OpenAI-compatible interface
]
otel = ["opentelemetry-exporter-otlp-proto-http>=1.30.0,<2.0.0"]
docs = [
Expand Down
Loading