Packages name change

[silentworks]

Chore

Migrate to the new package names and stop maintaining the older package names

Describe the chore

We need to fully migrate from the gotrue package name to supabase_auth. Currently, we maintain support for both packages by using a CLI workaround that copies all files and applies a regex to replace supabase_auth with gotrue before publishing.

However, this approach has become problematic-most notably, it prevents us from installing the package locally for development and testing. I’d like to deprecate gotrue entirely and move forward exclusively with supabase_auth.

The same issue exists with the transition from supafunc to supabase_functions. We're still using the old package imports in the supabase-py package to avoid breaking backward compatibility for users who may be importing exceptions or errors directly from these packages.

Additional context

Add any other context or screenshots that help clarify the task.

[grdsdev]

We should do a final release for the gotrue and supafunc packages, and include the classifiers as:

classifiers=[
    "Development Status :: 7 - Inactive",
],

Also, introduce a warning when initializing the client through the deprecated package, or when importing them (not sure if it's possible).

The warning message should state that the package name isn't supported anymore, and redirect it to the new package name.

import warnings

warnings.warn(
    "The 'old-package-name' is deprecated. Use 'new-package-name' instead.",
    UserWarning,
    stacklevel=2
)

We can then post an announcement on discussions about it, also say that old package names aren't receiving new features, and only patches for X months.

wdyt @silentworks and @o-santi ?

[o-santi]

I agree with that approach.

[developerlee79]

Hi. Are the final release(deprecation) for the gotrue and supafunc packages, and the migration to the new package names, open for contributions?

[silentworks]

@grdsdev I don't think those changes alone will do it. There is a scenario where a user might be making use of the AuthAPIError from gotrue based on knowing supabase-py installs it. I think the first step is to make all the exception imports available directly from supabase-py first.

So instead of a user importing from gotrue.errors:

from gotrue.errors import (
    AuthApiError,
    AuthInvalidCredentialsError,
    AuthWeakPasswordError,
)

they would import from supabase or even supabase.errors:

from supabase.errors import (
    AuthApiError,
    AuthInvalidCredentialsError,
    AuthWeakPasswordError,
)

There are no mention of the exceptions in the Supabase docs when it comes to the Python examples, so having all the exceptions/errors imported from the supabase-py package would be a give us more room to add these in the docs.

Also, introduce a warning when initializing the client through the deprecated package, or when importing them (not sure if it's possible).

I think we might be able to get this into the package files themselves by having some python comments which we would replace at publishing time inside the files. (I'm not keen on this, but it's an option).

[silentworks]

@developerlee79 this one will likely be handled by one of the existing maintainers as it's a bit more delicate. However if you see any other issue you wish to contribute to, feel free to open a PR and we'll review it.