NuGet package name

[FantasyTeddy]

When I first tried to use this Supabase C# client library, I was slightly irritated by the NuGet package name supabase-csharp.
If this were the only package related to this library, I wouldn't mind this naming choice too much, but since there are other packages involved (gotrue-csharp, realtime-csharp, etc.) the naming strikes me as being quite odd.

Have you ever considered using a more ".NET like" name for the NuGet packages?
One suggestion would be:

• Supabase for the top-level meta-package (currently supabase-csharp)
  • Supabase.PostgREST for the PostgREST client (currently postgrest-csharp)
  • Supabase.GoTrue for the GoTrue client (currently gotrue-csharp)
  • Supabase.Realtime for the Realtime client (currently realtime-csharp)
  • Supabase.Storage for the Storage client (currently storage-csharp)
  • Supabase.Functions for the Edge Functions client (currently functions-csharp)

This namespace-style naming convention would also convey the relation of the package better (it is not obvious that a package called realtime-csharp is related to Supabase).

If it is important to distinguish between the C# version of the client and the F# version, an additional suffix .CSharp/.FSharp could be added.

[acupofjose]

You make a good point. Back in 2020 I'd just written it to mirror the package names from the github repos. It looks like nuget doesn't support renaming so much as depreciating a package and recommending a new one.

I'm not opposed to a rename, but it would mark a "breaking" change for existing users. Regardless, the most popular packages on nuget all use the convention given by @FantasyTeddy.

Do you have any thoughts @wiverson?

[FantasyTeddy]

I absolutely agree that this would be a breaking change and would require some effort to coordinate and communicate properly. This is why I would totally understand if this is not something you are willing to do, or at least not now.

One thing I do like about the current naming is that it's very obvious with a quick search to find the repo from the name and vice versa.
[...]
From an aesthetic standpoint I do like the Supabase.* names better, but I do think that the GitHub repos should also be updated to match.

I tend to disagree here, because I do think the current naming of the GitHub repositories helps to distinguish between the different supported languages better. I think having a repository named Supabase.GoTrue would be quite confusing for anyone not directly involved.
The connection between GitHub repository and NuGet package is best done with the existing means; having a badge in the README of every repository that links to the NuGet package, and having the correct link to the "Source repository" on the NuGet page/in the NuGet package.

[...] I don't think the F# user base is big enough at this point, and AFAIK F# users could use the C# libs...?

I would therefore suggest to only add the .FSharp suffix for the F# version and leave the C# versions plain. And yes, the C# packages should also work for F# users, albeit probably not totally idiomatic.

[wiverson]

I tend to disagree here, because I do think the current naming of the GitHub repositories helps to distinguish between the different supported languages better. I think having a repository named Supabase.GoTrue would be quite confusing for anyone not directly involved.

Hmm, so maybe something like Supabase.GoTrue.csharp for the repo name? I don't recall if GitHub supports . so maybe something like Supabase-GoTrue-CSharp?

[FantasyTeddy]

In my opinion, I would not change the GitHub repository name at all. The naming scheme <module>-<language> works perfectly fine here, because the relation to Supabase is given by the supabase-community organization.

[acupofjose]

Thanks y'all - I believe that we should change the nuget package names (i.e. supabase-csharp to Supabase.Client, etc.) and leave the github repo names the same. That way we can continue to conform to the overall Supabase Community libraries and their naming conventions while also respecting the C# specific naming conventions for this library. For now, I'll open an issue as a reminder, but this will need to be done alongside the next major release. (Which, given the supabase announcements of being on v2 of the client libs, will likely be skipping v1.0.0 and just starting straight at v2.0.0)

This is now being tracked here