Skip to content

Tags: llvm/torch-mlir-release

Tags

dev-wheels

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Nightly Release of Torch-MLIR python wheels for linux_x86_64 builds (#1)

Reuses [build_linux_packages.sh](https://github.com/llvm/torch-mlir/blob/main/build_tools/python_deploy/build_linux_packages.sh) script to build the project and generate python wheels. I however chose to not port the original github actions workflows for snapshot releases, which seemed to do a lot more than what I initially wanted. Here's what's roughly different in this trimmed down version:
- html patching for hosting pip wheels is no longer used - instead went with the [expand_assets trick](https://fzakaria.com/2024/01/15/abusing-github-as-a-pypi-server.html), similar to [openxla/stablehlo](https://github.com/openxla/stablehlo/blob/main/.github/workflows/publishWheelRelease.yml)
- only release linux x86_64 prebuilt wheels (not macos, windows, aarch64 builds) - this may be updated later by interested parties

I used a standalone fork which was useful for the initial bringup - it took a good 30-ish iterations on `main` branch to nail the github workflow right, and some playing with auth tokens. 

Here's how the release page looks like:
- https://github.com/sjain-stanford/torch-mlir-release/releases
- https://github.com/sjain-stanford/torch-mlir-release/releases/expanded_assets/dev-wheels
(it follows the same naming convention as existing wheels, but updates the same `dev-wheels` release in place to avoid changing the expand_assets link required for pip-style hosting)

Here's the workflow: 
- https://github.com/sjain-stanford/torch-mlir-release/actions/runs/7825872338

@stellaraccident and I took a call to avoid using Personal Access Tokens (PAT) here for release permissions, and instead elevating permissions on [GITHUB_TOKEN](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token) for `contents` scope (required for an action to make a release). We think this is reasonable considering this repo is locked down in terms of number of contributors with write access, and that this is scope specific and not a write-all.