Use of proxies kwarg in httpx==0.28.0

[DJRHails]

Confirm this is an issue with the Python library and not an underlying OpenAI API

• This is an issue with the Python library

Describe the bug

httpx version 0.28.0 removes the deprecated proxies argument; this argument is hardcoded in the library at the moment.

To Reproduce

1. Update to httpx version 0.28.0

Code snippets

  File "/var/lang/lib/python3.10/site-packages/openai/_client.py", line 337, in __init__
    super().__init__(
  File "/var/lang/lib/python3.10/site-packages/openai/_base_client.py", line 1438, in __init__
    self._client = http_client or AsyncHttpxClientWrapper(
  File "/var/lang/lib/python3.10/site-packages/openai/_base_client.py", line 1335, in __init__
    super().__init__(**kwargs)
TypeError: AsyncClient.__init__() got an unexpected keyword argument 'proxies'

OS

macOS

Python version

Python 3.10.12

Library version

openai-1.55.2

[stestagg]

This is causing a fresh install of openai to be broken currently.

Here's a reproducer: (Dockerfile)

from alpine:edge

RUN apk update
RUN apk add python3 py3-pip

RUN pip install  --break-system-packages openai
RUN python -c 'import openai; client=openai.AsyncOpenAI(api_key="X")'

Gives:

 => ERROR [5/5] RUN python -c 'import openai; client=openai.AsyncOpenAI(api_key="X")'                              0.4s
------
 > [5/5] RUN python -c 'import openai; client=openai.AsyncOpenAI(api_key="X")':
0.307 Traceback (most recent call last):
0.307   File "<string>", line 1, in <module>
0.307   File "/usr/lib/python3.12/site-packages/openai/_client.py", line 337, in __init__
0.307     super().__init__(
0.307   File "/usr/lib/python3.12/site-packages/openai/_base_client.py", line 1438, in __init__
0.307     self._client = http_client or AsyncHttpxClientWrapper(
0.307                                   ^^^^^^^^^^^^^^^^^^^^^^^^
0.307   File "/usr/lib/python3.12/site-packages/openai/_base_client.py", line 1335, in __init__
0.308     super().__init__(**kwargs)
0.308 TypeError: AsyncClient.__init__() got an unexpected keyword argument 'proxies'
------
Dockerfile:7
--------------------
   5 |
   6 |     RUN pip install  --break-system-packages openai
   7 | >>> RUN python -c 'import openai; client=openai.AsyncOpenAI(api_key="X")'
   8 |
--------------------

[Pablo-Merino]

Having this issue too, with the synchronous client. A temporary fix I've found is to hardcode the httpx version in my requirements to the previous release, which is 0.27.2.

Just adding httpx==0.27.2 makes my code work again.

[dgellow]

Hi, thank you for the reports, we (@stainless-api) are actively working on a fix.

Edit: we have a patch under review right now and expect to push it to this repo in a few minutes

[RobertCraigie]

Thanks for the reports, this will be fixed shortly

[dgellow]

Should be fixed once #1905 gets merged (all the credits to the amazing @RobertCraigie for the quick fix)

[RobertCraigie]

Sorry for the delay, we're trying to get a hold of someone with the credentials to publish a new release.

[stainless-app]

Fixed by #1905

[vvaezian]

@dgellow @RobertCraigie In the pyproject.toml file, the httpx version is defined as httpx>=0.23.0, <1. Isn't this too wide? It seems to me the dependent libraries versions should only include the current and tested versions. But <1 allows many future upgrades that can potentially break stuff like the current issue. Other dependent libraries are defined in the same manner and seems to have the same issue.

[dgellow]

Hi @vvaezian, thanks for pointing that out. I tend to agree, though I'm not sure how strict the version range should be in this specific context. That's something we identified and will be discussing today as part of our internal post-mortem for that httpx v0.28.0 incident. I expect we will share an update later today in this thread.

[kristapratico]

@dgellow @RobertCraigie FYI it looks like we need the same fix in the CLI:

openai-python/src/openai/cli/_cli.py

Lines 179 to 182 in 534d6c5

	http_client = httpx.Client(
	proxies=proxies or None,
	http2=can_use_http2(),
	)

[RobertCraigie]

ah good catch thank you!

[dgellow]

@vvaezian Following up on your question, we decided against narrowing the version constraints. Instead we decided to invest into improving our testing setup to be sure we have coverage for nightly/dev versions of httpx (and other core dependencies), before they are released publicly.