Replies: 3 comments 6 replies
|
Over at Belfort Labs, we've wanted this so much we've gone ahead and published our own (fork-based) package https://pypi.org/project/belfort-torch-mlir/ :) Since we weren't familiar with the existing build workflow (and it seemed to have some significant issues, including no macOS support), we actually based this on the release workflow from HEIR, which is pretty proven and robust at this point: https://github.com/belfortlabs/torch-mlir/pull/3/changes |
|
I would be willing to try to port @AlexanderViand's PyPI release process to torch-mlir, if the torch-mlir maintainers are open to it. |
|
Oh this is great to know, I think publishing to pypi will be quite helpful for new users as it will lower the barrier to adoption. I'd prefer to use https://github.com/llvm/torch-mlir-release and integrate the PyPI release process as a workflow there -- adding macOS has been in my todo for a while but bandwidth is a problem 😄 |
Uh oh!
There was an error while loading. Please reload this page.
(Migrating from a short discord discussion)
Our group over at HEIR is adding experimental support for a torch frontend, using
torch-mliras one supported method to get from torch to linalg on tensors.Our main issue is that it's a bit clumsy to get our community started with torch-mlir, since
pip install torch-mlirdoesn't work without finding the right dev wheel. Moreover, I can't seem to get bazel (withrules_python) to properly depend on torch-mlir's dev wheels. I'm not sure what the exact problem is, but I suspect it's expecting some extra manifest information that comes from PyPI by default.This led me to ask: what is stopping torch-mlir from pushing the current dev wheels to PyPI? Is it a matter of bandwidth (and if so, might I provide some help)? And is torch-mlir at a decent enough point to start cutting non-dev releases?
All reactions