Switch clang tools from static binaries to wheels?

[shenxianpeng]

Is your idea related to an existing feature?

No response

Describe the behavior you would like

Right now, cpp-linter-action still uses clang-tools-pip to install clang-tools-static-binaries.

Previously, cpp-linter-hooks also relied on clang-tools-static-binaries before version v1.0.0. Since v1.0.0 (now at v1.1.6), it has switched to using Clang Tools wheels — this change has proven to work better overall.

Today, I made a small update to cpp-linter-hooks to add CLI support for installing wheels since it already resolves version and installs before (see https://github.com/cpp-linter/cpp-linter-hooks/pull/136), similar to how clang-tools-pip installs binaries.

Example usage:

# Install the package
pip install cpp-linter-hooks

# Install specific version of clang-format
clang-tools-wheel --tool clang-format --version 21
clang-format installed at: /home/sxp/.local/bin/clang-format

# Check clang-format version
/home/sxp/.local/bin/clang-format --version
clang-format version 21.1.2

# Install specific version of clang-tidy
clang-tools-wheel --tool clang-tidy --version 21
clang-tidy installed at: /home/sxp/.local/bin/clang-tidy

# Check clang-tidy version
/home/sxp/.local/bin/clang-tidy --version
LLVM (http://llvm.org/):
  LLVM version 21.1.1
  Optimized build.

Maybe it’s time to switch Clang Tools from static binaries to wheels?

Describe alternatives you have considered

No response

Additional context

No response

[2bndy5]

Why add a CLI to cpp-linter-hooks?

It seems that you have the needed foundation in clang-tools-pip; all it needs is changing how downloads happen. Of course there's the problem of using pip in an env where pip is not setup. In which case, I think using the PyPI JSON API directly might be simpler.

[shenxianpeng]

Why add a CLI to cpp-linter-hooks?

Good point. I also feel it's not the best to have it in cpp-linter-hooks. But because I have used PyPI JSON API to get version automatically to cpp_linter_hooks/versions.py also have some common code already written in cpp_linter_hooks/util.py, it would be easy to implement the CLI.

I now think a better approach is to reuse that code in clang-tools-pip by importing it, rather than duplicating and maintaining similar logic in two places.

Does that make sense?

[2bndy5]

Yea that makes sense.

After noting the PyPI JSON API, I started prototyping a downloader in cpp-linter-rs. So, v3 should use 1 CLI to replace them all. Unfortunately, I can't just reuse code from astral-sh/uv (because it is not all published to crates.io).

[2bndy5]

I have used PyPI JSON API to get version automatically to cpp_linter_hooks/versions.py

This only gets the versions. At runtime, you still depend on pip being installed (and pip is not listed as a dependency).

there's the problem of using pip in an env where pip is not setup

I was thinking about downloading the binary wheel using only the PyPI JSON API at runtime (without using pip to figure out which wheel to download).

[2bndy5]

[!CAUTION] A venv created by uv does not have pip present. Instead, you would need to invoke uv pip. Determining if pip is available or if uv is available adds complexity to this idea.

There are a few instances where pip is not guaranteed installed. Linux by default has no pip installed, that's why they have so many python3-<pkg-name-here> packages on apt compatible PPA repositories.

Looking at the pip source code, I see they explicitly warn about using pip as a library in src/pip/py.typed file.

[shenxianpeng]

there's the problem of using pip in an env where pip is not setup

I’ll add pip to the dependencies section. That should be fine.

I was thinking about downloading the binary wheel using only the PyPI JSON API at runtime (without using pip to figure out which wheel to download).

This sounds good. Just don't know if doing this requires resolving other issues, like dependency conflicts—maybe it doesn't.

[2bndy5]

I was thinking about downloading the binary wheel using only the PyPI JSON API at runtime (without using pip to figure out which wheel to download).

This sounds good. Just don't know if doing this requires resolving other issues, like dependency conflicts—maybe it doesn't.

It does mean resolving the libC version on Linux (the hardest part). Otherwise its pretty straight forward because the built executable binaries are included in the wheel (a special zip file) that is downloaded. The supported python version does not matter. We only need to figure out the platform's OS and architecture (and Linux Lib C version/implementation).

[!tip] See also references about

• PyPA's wheel name convention
• How pip determines musl lib C version
• How pip determines GNU lib C version