-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[libshortfin] Add package build script for Linux using manylinux. #230
[libshortfin] Add package build script for Linux using manylinux. #230
Conversation
0ce1f57
to
9223811
Compare
} | ||
|
||
function build_shortfin() { | ||
export SHORTFIN_ENABLE_TRACING=ON |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we always want to build _shortfin_tracy
and have it in the same wheel?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so, matching IREE: https://iree.dev/reference/bindings/python/#profiling
The lib.cpython-313-x86_64-linux-gnu.so
is currently 450 KB in _shortfin_default
and 851 KB in _shortfin_tracy
. We could split them into separate packages or an "extra", like shortfin[tracing]
: https://packaging.python.org/en/latest/specifications/dependency-specifiers/#extras
Progress on #130, follow-up to #230. ## Overview This gets us the general structure of a release pipeline that: 1. Computes some version information metadata based on build id and date 2. Calls `shortfin/build_tools/build_linux_package.sh`, which runs `python -m pip wheel` under a manylinux Docker container 3. Uploads wheels to both GitHub artifacts (for the workflow run itself) and GitHub releases (for archival and developer usage) This follows how stablehlo (https://github.com/openxla/stablehlo/releases/tag/dev-wheels) and torch-mlir (https://github.com/llvm/torch-mlir-release/releases/tag/dev-wheels) both publish to a constantly growing "dev-wheels" release rather than separate releases like IREE does. That makes it harder to directly "promote" a candidate release, but it avoids polluting the release history with nightly builds. ## Testing * Sample run: https://github.com/ScottTodd/SHARK-Platform/actions/runs/11078636913 * Dev wheels release: https://github.com/ScottTodd/SHARK-Platform/releases/tag/dev-wheels * Install with `python -m pip install shortfin -f https://github.com/ScottTodd/SHARK-Platform/releases/expanded_assets/dev-wheels` ## What's next In no particular order, - [ ] Verify that the Tracy build enabled by `SHORTFIN_ENABLE_TRACING` is functional - [ ] Set up dependencies and optional components such that a user can just `pip install shortfin` and have it bring along a compatible version of packages like `iree-runtime` and `iree-compiler` - [ ] Update the dockerfile version from manylinux2014 (that is independent of this workflow) - [x] Build for Python 3.13 free threaded and test that - [ ] Build for other platforms/architectures (macOS, Windows, arm64, etc.) - [ ] Set up a workflow like IREE's pkgci that installs the packages and runs some tests on them - [ ] Document how to install the developer packages --------- Co-authored-by: Marius Brehler <marius.brehler@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, from iree-org/iree#15856:
I think we can actually completely forgo most of the gunk in build_linux_packages.sh (all of the docker stuff). For other projects, I'm either using GHA action runners that are already the right OS or telling GHA to run in the context of the manylinux docker image. Makes it really, really simple.
Progress on #130
This is forked from
TODO (future PRs?):