Adrien 21aab77be4 ci(release): publish PEP 740 attestations to PyPI for hf-xet (#848)
## Summary

Switches the `release-pypi` job from `PyO3/maturin-action`'s upload
command to `pypa/gh-action-pypi-publish` with `attestations: true`, so
that every `hf-xet` artifact on PyPI ships with **PEP 740 / Sigstore
provenance**.

Today, `hf-xet 1.5.0` on PyPI shows `attestations: None` and
`https://pypi.org/integrity/hf-xet/1.5.0/<wheel>/provenance` returns
404. The existing `actions/attest-build-provenance` step does the work,
but its output never reaches PyPI: `gh attestation verify` works for
wheels people downloaded from GitHub releases, but `pip download
--verify-attestations` (and the equivalent uv / SLSA verifier flows)
have nothing to chain to.

## What changes

In `.github/workflows/release.yml`, `release-pypi` job:

- Add a step that collects every `wheels-*/<file>` artifact into a
single `dist/` directory. Debug-symbol artifacts (`dbg-*`) are
explicitly excluded from this directory and therefore from the upload.
- Point `actions/attest-build-provenance` at `dist/*` so the GitHub
attestation covers exactly the same bytes that get uploaded.
- Replace `PyO3/maturin-action@... command: upload` with
`pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b`
(v1.14.0, SHA-pinned) and `attestations: true`, `skip-existing: true`,
`print-hash: true`.

## Why two attestation steps?

They are complementary, not redundant:

| Step | Verifier | Where it lives |
|---|---|---|
| `actions/attest-build-provenance` | `gh attestation verify`,
sigstore-go | github.com attestations endpoint |
| `pypa/gh-action-pypi-publish` with `attestations: true` | `pip
download --verify-attestations`, uv, slsa-verifier | PyPI
`/integrity/.../provenance` |

The first one verifies wheels distributed anywhere; the second one is
what PyPI clients actually look at.

## Verification after merge

On the first release that runs this workflow:

```bash
$ pip download --no-deps hf-xet==<new-version>
$ python -c "from pypi_attestations import Distribution; print(Distribution.from_file('hf_xet-*.whl').identity)"
# should print the workflow / environment / repo identity
```

And on PyPI's web UI: each wheel should show a "Provenance" link instead
of "no attestations".

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Changes the release publishing path and artifact selection for PyPI
uploads; mistakes could block releases or upload the wrong artifacts
despite being confined to CI.
> 
> **Overview**
> Switches the `release-pypi` job to **collect all wheel/sdist artifacts
into a single `dist/` directory** (excluding `dbg-*`) and generate the
GitHub build provenance attestation over exactly those files.
> 
> Replaces the PyPI upload step from `PyO3/maturin-action` to
`pypa/gh-action-pypi-publish` using **Trusted Publishing + PEP 740
attestations** (`attestations: true`, `skip-existing: true`,
`print-hash: true`), and clarifies required workflow permissions.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
4f0c7f8db9. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
2026-06-02 08:20:34 +02:00
2026-05-21 21:27:59 +02:00
2025-09-29 10:25:25 -07:00
2024-10-23 17:57:45 -07:00

License GitHub release Contributor Covenant

🤗 xet-core - xet client tech, used in huggingface_hub

Welcome

xet-core enables huggingface_hub to utilize xet storage for uploading and downloading to HF Hub. Xet storage provides chunk-based deduplication, efficient storage/retrieval with local disk caching, and backwards compatibility with Git LFS. This library is not meant to be used directly, and is instead intended to be used from huggingface_hub.

Key features

chunk-based deduplication implementation: avoid transferring and storing chunks that are shared across binary files (models, datasets, etc).

🤗 Python bindings: bindings for huggingface_hub package.

network communications: concurrent communication to HF Hub Xet backend services (CAS).

🔖 local disk caching: chunk-based cache that sits alongside the existing huggingface_hub disk cache.

Packages

This repository produces the following packages:

Rust Crates (crates.io)

Crate Description
hf-xet High-level client library for uploading and downloading files with chunk-based deduplication
xet-client HTTP client for communicating with Hugging Face Xet storage servers
xet-data Data processing pipeline for chunking, deduplication, and file reconstruction
xet-core-structures Core data structures including MerkleHash, metadata shards, and Xorb objects
xet-runtime Async runtime, configuration, logging, and utility infrastructure

Python Package (PyPI)

Package Description
hf-xet Python bindings for the Xet storage system, used by huggingface_hub

Built from the hf_xet/ directory using maturin.

CLI Binary

Binary Description
git-xet Git LFS compatible command-line tool for Xet storage

Built from the git_xet/ directory. Distributed via GitHub releases.

Contributions (feature requests, bugs, etc.) are encouraged & appreciated 💙💚💛💜🧡❤️

Please join us in making xet-core better. We value everyone's contributions. Code is not the only way to help. Answering questions, helping each other, improving documentation, filing issues all help immensely. If you are interested in contributing (please do!), check out the contribution guide for this repository.

Issues, Diagnostics & Debugging

If you encounter an issue with hf-xet, please collect diagnostic information and attach it when creating a new Issue.

The scripts/diag/ directory contains platform-specific scripts that download debug symbols, configure logging, and capture periodic stack traces and core dumps:

OS Script
Linux scripts/diag/hf-xet-diag-linux.sh
macOS scripts/diag/hf-xet-diag-macos.sh
Windows (Git-Bash) scripts/diag/hf-xet-diag-windows.sh
# prefix your failing command with the script for your OS, e.g.:
./scripts/diag/hf-xet-diag-macos.sh -- python my-script.py

See scripts/diag/README.md for full usage, output layout, dump analysis instructions, and how to install debug symbols manually.

Quick debugging environment variables:

RUST_BACKTRACE=full          # full Rust backtraces on panic
RUST_LOG=info                # enable hf-xet logging
HF_XET_LOG_FILE=/tmp/xet.log # write logs to a file (defaults to stdout)

Local Development

Repo Organization

  • xet_pkg/ (hf-xet): High-level session API for uploading and downloading files with deduplication.
  • xet_client/ (xet-client): HTTP client for CAS and Hub backend services.
  • xet_data/ (xet-data): Chunking, deduplication, and file reconstruction pipeline.
  • xet_core_structures/ (xet-core-structures): MerkleHash, metadata shards, Xorb objects, and shared data structures.
  • xet_runtime/ (xet-runtime): Async runtime, configuration, logging, and utilities.
  • hf_xet/: Python bindings (maturin/PyO3), produces the hf-xet PyPI package.
  • git_xet/: Git LFS compatible CLI tool (git-xet).
  • wasm/: WebAssembly builds (hf_xet_wasm, hf_xet_thin_wasm).
  • simulation/: Simulation and benchmarking infrastructure.

Build, Test & Benchmark

To build xet-core, look at requirements in GitHub Actions CI Workflow for the Rust toolchain to install. Follow Rust documentation for installing rustup and that version of the toolchain. Use the following steps for building, testing, benchmarking.

Many of us on the team use VSCode, so we have checked in some settings in the .vscode directory. Install the rust-analyzer extension.

Build:

cargo build

Test:

cargo test

Benchmark:

cargo bench

Linting:

cargo clippy -r --verbose -- -D warnings

Formatting (requires nightly toolchain):

cargo +nightly fmt --manifest-path ./Cargo.toml --all

Building Python package and running locally (on *nix systems):

  1. Create Python3 virtualenv: python3 -mvenv ~/venv
  2. Activate virtualenv: source ~/venv/bin/activate
  3. Install maturin: pip3 install maturin ipython
  4. Go to hf_xet crate: cd hf_xet
  5. Build: maturin develop
  6. Test:
ipython
import hf_xet as hfxet
hfxet.upload_files()
hfxet.download_files()

Developing with tokio console

Prerequisite is installing tokio-console (cargo install tokio-console). See https://github.com/tokio-rs/console

To use tokio-console with hf-xet there are compile hf_xet with the following command:

RUSTFLAGS="--cfg tokio_unstable" maturin develop -r --features tokio-console

Then while hf_xet is running (via a hf cli command or huggingface_hub python code), tokio-console will be able to connect.

Ex.

# In one terminal:
pip install huggingface_hub
RUSTFLAGS="--cfg tokio_unstable" maturin develop -r --features tokio-console
hf download openai/gpt-oss-20b

# In another terminal
cargo install tokio-console
tokio-console

Building universal whl for MacOS:

From hf_xet directory:

MACOSX_DEPLOYMENT_TARGET=10.9 maturin build --release --target universal2-apple-darwin --features openssl_vendored

Note: You may need to install x86_64: rustup target add x86_64-apple-darwin

Testing

Unit-tests are run with cargo test, benchmarks are run with cargo bench. Some crates have a main.rs that can be run for manual testing.

References & History

Description
Languages
Rust 96.7%
Python 1.7%
Shell 1.3%
JavaScript 0.1%
HTML 0.1%