Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 5 additions & 14 deletions Formula/h/huggingface-cli.rb → Formula/h/hf.rb
Original file line number Diff line number Diff line change
@@ -1,21 +1,12 @@
class HuggingfaceCli < Formula
class Hf < Formula
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@carlocab carlocab Jul 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

@abitrolly abitrolly Jul 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

include Language::Python::Virtualenv

desc "Client library for huggingface.co hub"
desc "CLI for huggingface.co hub"
homepage "https://huggingface.co/docs/huggingface_hub/guides/cli"
url "https://files.pythonhosted.org/packages/22/cd/841bc8e0550d69f632a15cdd70004e95ba92cd0fbe13087d6669e2bb5f44/huggingface_hub-0.34.1.tar.gz"
sha256 "6978ed89ef981de3c78b75bab100a214843be1cc9d24f8e9c0dc4971808ef1b1"
license "Apache-2.0"

bottle do
sha256 cellar: :any, arm64_sequoia: "03d72a3e38eb08081f25dc958e13155abb397143842d79176014987455937756"
sha256 cellar: :any, arm64_sonoma: "433210d58f757b1262a3fbb861d981a87f87ad6a192d68d69294ddcea7619cad"
sha256 cellar: :any, arm64_ventura: "57e4fb06fa7a92ad4cb4e8f09920697dc4784b2332f4b28520ae6e6dd7a6f341"
sha256 cellar: :any, sonoma: "207ad04c0a8865d6b9c1cf6e448350965e0c3d6548370cf0926a572aeb3defb1"
sha256 cellar: :any, ventura: "46092324b73e329f44e2a9e34bd4f385a81db9f3c9eec0331cc1040d626e74b6"
sha256 cellar: :any_skip_relocation, x86_64_linux: "26e3a539318efa405ea8b77483659d366e2343d9a6d1827e004dd5182bb0fac3"
end

depends_on "pkgconf" => :build
depends_on "rust" => :build # for `hf-xet`

Expand Down Expand Up @@ -108,13 +99,13 @@ def install
end

test do
whoami_output = shell_output("#{bin}/huggingface-cli whoami")
whoami_output = shell_output("#{bin}/hf auth whoami")
assert_match "Not logged in", whoami_output
test_cache = testpath/"cache"
test_cache.mkdir
ENV["HUGGINGFACE_HUB_CACHE"] = test_cache.to_s
ENV["HF_HUB_CACHE"] = test_cache.to_s
ENV["NO_COLOR"] = "1"
scan_output = shell_output("#{bin}/huggingface-cli scan-cache")
scan_output = shell_output("#{bin}/hf cache scan")
assert_match "Done in 0.0s. Scanned 0 repo(s) for a total of 0.0.", scan_output
end
end
1 change: 1 addition & 0 deletions formula_renames.json
Original file line number Diff line number Diff line change
Expand Up @@ -78,6 +78,7 @@
"ht-rust": "xh",
"htop-osx": "htop",
"httpd24": "httpd",
"huggingface-cli": "hf",
"i386-elf-binutils": "x86_64-elf-binutils",
"i386-elf-gcc": "x86_64-elf-gcc",
"interactive-rebase-tool": "git-interactive-rebase-tool",
Expand Down
8 changes: 4 additions & 4 deletions pypi_formula_mappings.json
Original file line number Diff line number Diff line change
Expand Up @@ -445,6 +445,10 @@
"hatch": {
"exclude_packages": ["certifi", "cryptography", "uv"]
},
"hf": {
"package_name": "huggingface_hub[cli]",
"exclude_packages": ["certifi"]
},
"howdoi": {
"exclude_packages": ["certifi", "cryptography"]
},
Expand All @@ -455,10 +459,6 @@
"package_name": "httpie",
"exclude_packages": ["certifi"]
},
"huggingface-cli": {
"package_name": "huggingface_hub[cli]",
"exclude_packages": ["certifi"]
},
"icloudpd": {
"exclude_packages": ["certifi"]
},
Expand Down
Loading