Breaking change - `http_client.py` removed in supabase-auth 2.23.3

[wilt-vetrec]

Describe the bug

We are using supabase-py==2.21.1 . About an hour ago, our CI started to fail with this error:

ModuleNotFoundError: No module named 'supabase_auth.http_clients'

This seems to be caused by http_client.py being fully deleted in a patch release of supabase-auth, 2.23.3.

v2.23.2...v2.23.3

Please revert this change, or increment semver.

Reproduction

`pip install supabase-py==2.21.1`

Steps to reproduce

No response

Library affected

supabase-auth

Library version

supabase-auth 2.23.3

Python version

python 3.10.13

[o-santi]

Yes this is a change, but I don't think this qualifies as a breaking change, as you shouldn't be relying on those in the first place, for they're not exported in __init__.py. They were only there for a stupid patch on the sync client. You should just use httpx.Client there instead (and httpx.AsyncClient for the async version.)

[the-rich-piana]

@o-santi respectfully your answer makes absolutely no bombaclat sense

[o-santi]

The client offered in supabase_auth.http_clients is the same as httpx, and the old SyncClient class was only there for technicalities related to how sync is generated from sync (that I explained in #1298).

Furthermore, the library is allowed to change internal workings, as long as they're not part of the "public" API. Given that http_clients.py is not formally exported in __init__.py, we should not consider it part of the public API, and thusly we should be allowed to change it, or even remove it, so long as the rest of the library keeps working fine (which is the case). Of course, this is python, which means that anyone can import anything if they know the path, so there's nothing we can do if someone was importing that file.

I can reintroduce the file if this is a hard change to do, however notice that it will just be re-exporting httpx clients, and that isn't really a meaningful PR that I want to make.

[wilt-vetrec]

@o-santi To clarify, we're not importing this internal file. We're using an old version of supabase-py as directed. We pin the old version for app stability, but not supabase-auth, to ensure we get security updates. Any user who attempts to use supabase-py versions prior to 2.23.3 will experience this failure.

[silentworks]

@the-rich-piana be mindful of your language to others. As a fellow maintainer to @o-santi and as a Jamaican you cannot use respectfully in the same line as that word.

@wilt-vetrec If we re-introduce that class in the way @o-santi has mentioned it will probably still break your code, so I'd suggest you pin a version of auth-py that has that in it until you are able to upgrade supabase-py.

In hindsight you are correct this should have probably had been a minor release rather than a patch. I will chat with @o-santi tomorrow and see if there is anything we can do about this.

[wilt-vetrec]

It looks like the real issue is that, between supabase 2.19.0 (when you switched to a monorepo) and 2.22.2, the pypi package wasn't correctly specifying version ranges in requires_dict (see $ curl https://pypi.org/pypi/supabase/2.22.2/json | jq .info). Not sure what can be done about that, short of yanking affected versions. In this case, upgrading to latest seems not to be causing problems for us so far.

[ideallical]

our build breaks too going from 2.23.2 to 2.23.3

AttributeError: <module 'supabase._sync.client' from '/venv/lib/python3.13/site-packages/supabase/_sync/client.py'> does not have the attribute 'SyncClient'

It seems I had to replace the mocking decorator in our unit tests:

@patch("supabase._sync.client.SyncClient")

with

@patch("httpx.Client")

You might want to add that to the release notes.

[silentworks]

@ideallical that's a good point about mentioning this in the release note. We will take that into consideration on the next release.

[o-santi]

I'll be closing this issue as v2.24.0 is officially published, and we've yanked 2.23.3 warning that it contained minor breaking changes. The changelog for the new version should also reflect that the two classes were removed, and warn people to look for potential places where they were relying on it (like unit test patches).

[wilt-vetrec]

@silentworks @o-santi It still feels as though the team doesn't understand the nature of the breakage. This is not resolved. Bumping the minor version is irrelevant. The resolution here should be:

• Yank all versions between 2.19.0 and 2.22.2 inclusive
• Backport fix(supabase): pin dependencies versions #1273 (with the equivalent version numbers) to each minor release branch between 2.19 and 2.22, and release a new patch version with the change

Any user who, for whatever reason, is unable to upgrade past these versions will continue to experience this error if they do not have a lockfile, and probably future errors as well.

Minimal reproduction:
repro.py:

# /// script
# dependencies = [ "supabase==2.22.2" ]
# ///

import supabase
print("Imported")

$ uv run repro.py
Installed 33 packages in 18ms
Traceback (most recent call last):
  File "/Users/wt/code/Neum-Vet/scratch.py", line 5, in <module>
    import supabase
  File "/Users/wt/.cache/uv/environments-v2/scratch-16b8e711adc7ad5e/lib/python3.10/site-packages/supabase/__init__.py", line 22, in <module>
    from ._async.auth_client import AsyncSupabaseAuthClient as ASupabaseAuthClient
  File "/Users/wt/.cache/uv/environments-v2/scratch-16b8e711adc7ad5e/lib/python3.10/site-packages/supabase/_async/auth_client.py", line 9, in <module>
    from supabase_auth.http_clients import AsyncClient
ModuleNotFoundError: No module named 'supabase_auth.http_clients'