Thanks for contributing to Homebrew! 🎉 It looks like you're having trouble with a CI failure. See our contribution guide for help. You may be most interested in the section on dealing with CI failures. You can find the CI logs in the Checks tab of your pull request.

If it is not a requirement of the build system to build the project with .git directory, I'd prefer to use tarball and add libpg_query as a resource or new formula

If it is not a requirement of the build system to build the project with .git directory, I'd prefer to use tarball and add libpg_query as a resource or new formula

I switched to clone because we need the submodules for libpg_query and tree-sitter-sql during the build. Hope to resolve that at some point, but right now I fear we cannot go with tarballs only.

I request that this formula not be called "postgrestools". That's too generic and not useful. It would make more sense and be more recognizable to use "postgres-language-server".

I request that this formula not be called "postgrestools". That's too generic and not useful. It would make more sense and be more recognizable to use "postgres-language-server".

The website is called pgtools though. Is it not confusing to use a different name than the public website?

The website is called pgtools though. Is it not confusing to use a different name than the public website?

Well, the website is "pgtools", the source code repo is "postgres-language-server", and the proposed formula is "postgrestools". Which one is it? They're not doing themselves any favors in their branding.

In any case, I'm a developer from the PostgreSQL project. I'm pretty confident that no one in that community would think of this piece of software when they think of "postgres tools". So I think this would be inappropriate name squatting and prone to mislead users. Maybe something like "supabase-pgtools" would be clearer.

The website is called pgtools though. Is it not confusing to use a different name than the public website?

Well, the website is "pgtools", the source code repo is "postgres-language-server", and the proposed formula is "postgrestools". Which one is it? They're not doing themselves any favors in their branding.

In any case, I'm a developer from the PostgreSQL project. I'm pretty confident that no one in that community would think of this piece of software when they think of "postgres tools". So I think this would be inappropriate name squatting and prone to mislead users. Maybe something like "supabase-pgtools" would be clearer.

thanks for your feedback! I totally get the conflict of interest here.

for transparency: the project is evolving from just a language server to what I as an outsider would call a language toolchain that includes a linter and eventually a formatter among other things. Still, I agree that "Postgres Tools" can be misleading for many. We also had "Postgres Language Tools" in mind, but found the name to be too long.

What do you think about these?

• pgtools to match the domain (probably no for said reasons)
• postgres-language-tools or any abbreviation
• if not -> also happy to go with postgres-language-server for now to match the repo name. note that we plan to rename that once we have the "tool" part of it sorted out more.

Just pick one and I will go for it :) We would like to keep Supabase out of the name though. The project is supposed to be for anyone building with Postgres, not just Supabase users. They are just supporting us with resources.

Sorry for the forth and back!

Personally, I think postgres-language-server has good brand recognition. There were several Hacker News etc. stories about it, and it's a project I would actually try to go out and find.

The other stuff, evolving it into a box of language tools, I think that's either (a) not that important, the current name is good enough, or (b) a problem for the future, you can always rename it, or (c) then you think of a completely new and unique name, like superelephant or pglinguist or some artificial word.

It makes sense to me to keep this as postgrestools, unless upstream are planning to change the naming of their built binaries. I think it works well to keep the formula name in line with the binary path wherever practical.

Personally, I think postgres-language-server has good brand recognition

@petere - thanks for weighing in here. We'd love to keep it simple, and at the same time make it clear that it's a contribution for the pg community - not specific to Supabase. (In that vein we're happy to relocate the repo it into it's own GitHub org, accept other contributors, rename it, donate it - generally whatever is required to make that obvious.)

The other stuff, evolving it into a box of language tools, I think that's either (a) not that important, the current name is good enough,

@psteinroe - on Peter's point here, my preference is also postgres-language-server. That's the problem we set out to solve and the thing the Postgres community lacks. The other tools could be thought of as extensions or nice to haves, but ultimately we want the tool to work as an LSP and if that's all that's achieved then we've done well for the ecosystem.

@petere if you agree with postgres-language-server, I will reach out on the Postgres mailing list to ask permission (or you can make a call on this thread for go/no-go). We can also rebuild binaries and change domains - better that we do this work now than in 2 years' time

#218049 (comment):

for transparency: the project is evolving from just a language server to what I as an outsider would call a language toolchain that includes a linter and eventually a formatter among other things. Still, I agree that "Postgres Tools" can be misleading for many. We also had "Postgres Language Tools" in mind, but found the name to be too long.

Currently,

• the repository name is "postgres-language-server"
• the only binary it provides could be named "postgres-language-server" (not actually important)
• the Homebrew formula could be named "postgres-language-server" for now (and could be renamed later)

In the future,

• the repository could be renamed to "postgres-language-tools"
• it could provide more binaries, named like "postgres-language-server", "postgres-lint", "postgres-format", etc.
• the Homebrew formula could be renamed to "postgres-language-tools"
• the formula alias "postgres-language-server" will redirect from old name to "postgres-language-tools"

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.