hf: renamed from huggingface-cli

[abitrolly]

See huggingface/huggingface_hub#3229

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[github-actions]

Caution

Please do not modify the bottle block. Bottle block modifications can cause CI to misbehave.
@BrewTestBot will handle updating the bottle block before this PR is merged.

[abitrolly]

First the CI failed brew audit --formula hf --online --new output hf (https://github.com/Homebrew/homebrew-core/actions/runs/16529961532/job/46752885987?pr=231234):

    * New formulae in homebrew/core should not have a `bottle do` block
  Error: 1 problem in 1 formula detected.

Now that the block is removed, it complains that bottle block was modified and fails anyway.

@MikeMcQuaid any hints how to resolve the deadlock?

[p-linnane]

You need to rm the existing formula and create a new one under the new name. I did this for another project yesterday. You can use my PR as a reference: #231149

[abitrolly]

@p-linnane thanks! I will try it. Looks like the doc needs to updated https://docs.brew.sh/Rename-A-Formula

[gromgit]

@p-linnane thanks! I will try it. Looks like the doc needs to updated https://docs.brew.sh/Rename-A-Formula

Looks to me like it already says what @p-linnane said to do, just in slightly different words.

[abitrolly]

@gromgit my attempt to improve it Homebrew/brew#20316 although I am not sure copying and removing will work. Years ago git didn't track renames, so perhaps addition and removal needs to be done in seperate commits.

[github-actions]

Caution

Please do not modify the bottle block. Bottle block modifications can cause CI to misbehave.
@BrewTestBot will handle updating the bottle block before this PR is merged.

[abitrolly]

Yep. Coping and removing in one commit doesn't work.

✗ git rm h/huggingface-cli.rb
rm 'Formula/h/huggingface-cli.rb'
✗ git commit --amend
[hf-rename 0c1a314091f] hf: renamed from huggingface-cli
 Date: Fri Jul 25 22:04:54 2025 +0300
 3 files changed, 10 insertions(+), 18 deletions(-)
 rename Formula/h/{huggingface-cli.rb => hf.rb} (81%)

The doc needs to be updated to say it needs to be done in separate commits.

[abitrolly]

Looks everything is okay now. I've updated the doc PR too.

[carlocab]

hf as a formula name seems terribly non-descriptive. The formula name doesn't always have to match the name of the program it installs. Maybe we should just add an hf alias instead?

[p-linnane]

I don't have a super strong opinion here, but I think we need to come up with a standard convention to handle tools like this.

1. GitHub CLI is packaged as gh, which is the binary name.
2. AWS CLI is packaged as awscli and the binary is aws.

There are a few other options that we have as foo-cli where the binaries are just foo. We should try to standardize one way or another.

cc @Homebrew/core for thoughts.

[carlocab]

gh seems more likely to be more widely recognised, but I'm not opposed to having it be named github-cli instead. awscli seems sufficiently understandable enough on its own to not require expansion.

But standardising this would be good; I agree.

[abitrolly]

HuggingFace CLI is not as popular as gh or rg, but it is still quite popular.

✗ brew info huggingface-cli gh rg | grep "nstall:"
install: 3,984 (30 days), 11,668 (90 days), 28,398 (365 days)
install: 166,543 (30 days), 449,558 (90 days), 1,622,364 (365 days)
install: 14,467 (30 days), 39,610 (90 days), 170,178 (365 days)

Having a short name has more benefits than hunting for a long name. If you don't know what a tool does, the long name won't be descriptive anyways in majority of cases.

[daeho-ro]

Changing the binary name seems fine, but I am not sure about the formula. Others have already mentioned the same thing, but when I see the name hf, nothing comes to my mind.

[abitrolly]

There are a few other options that we have as foo-cli where the binaries are just foo. We should try to standardize one way or another.

I am sure it make sense to suffix all commands with -cli, because the majority of brew packaged software is CLI.

[carlocab]

jj is another pretty terrible name. That one should be named jujutsu (and need not be suffixed with -cli)

[abitrolly]

For automation and simplicity it is more beneficial to have packages named after binaries. Otherwise scripts need to maintain additional mapping. For example you need to know that to get fd on Ubuntu, you need to install fd-find package. Digging for a "proper" package name is a waste of time when you know exactly what you need. Also, people will have to spend time to maintain mapping for missing commands suggestion scripts.

[carlocab]

I'm not sure I follow. I'm not proposing that brew install jj not install jujutsu, or that brew install hf not install huggingface-cli, so I don't see why scripts needs to maintain additional mappings.

I just want formulae to have names that are easier to understand and easier to look up. For example, Googling jj does not return any useful results for me. The first result is the Wikipedia page of a singer named JJ, and the second result is that same singer's Instagram account. Googling jujutsu, on the other hand, at least returns the CLI tool's repo as the third result.

This is part of why I disagree with:

If you don't know what a tool does, the long name won't be descriptive anyways in majority of cases.

There is certainly a set of users who won't recognise a package with both its short name (e.g. jj) or long name (e.g. jujutsu). But it does seem likely to me that there are users who would've recognised the long name but not the short one, and anyone who recognises the short one would probably recognise the long one too.

That is to say: the longer name is, almost by definition, more descriptive than the short name, and therefore almost always more useful.

[MikeMcQuaid]

I don't have a super strong opinion here, but I think we need to come up with a standard convention to handle tools like this.

I think we shouldn't have a standard convention or at least the standard convention should not be one that results in consistency between tools.

Our convention should be "what do the upstream authors refer to the tool as" and/or "what do the users refer to the tool as".

Having a look at the website here, I don't think there's a good argument for renaming.

We literally have aliases for reasons like this. Perfectly happy to have a hf alias added in this case.

Furthermore, given renames/migrations are not transparent and 100% without cost to the user (even just time/output): we should avoid renames unless pressing. Mass renames for "consistency" are just annoying and messy.

jj is another pretty terrible name. That one should be named jujutsu (and need not be suffixed with -cli)

Good case study: go visit https://github.com/jj-vcs/jj and that's what it's referred to as.

Then again, in this case at least the actual GitHub repository is called jj which is an argument for the naming.

I just want formulae to have names that are easier to understand and easier to look up. For example, Googling jj does not return any useful results for me.

This is good reasoning.

If you don't know what a tool does, the long name won't be descriptive anyways in majority of cases.

This is very bad reasoning.

That is to say: the longer name is, almost by definition, more descriptive than the short name, and therefore almost always more useful.

I agree. This also goes for variables, for what it's worth.

Passing on this PR.