Remove bundled openfhe from PyPI wheel#3058
Conversation
j2kun
changed the title
j2kun
force-pushed
the
stop-shipping-openfhe
branch
from
e4d730d to
c165d8c
Compare
j2kun
force-pushed
the
stop-shipping-openfhe
branch
from
212f8de to
a6c741a
Compare
|
Miraculously, it works. I will give this code a bit of a cleanup tomorrow and then we can merge it in, which unblocks hermetic LLVM (and buildbuddy) |
j2kun
force-pushed
the
stop-shipping-openfhe
branch
from
4388391 to
f0de467
Compare
j2kun
requested review from
AlexanderViand
and removed request for
AlexanderViand
j2kun
force-pushed
the
stop-shipping-openfhe
branch
2 times, most recently
from
4fdf13a to
38f07ff
Compare
|
@AlexanderViand this should be ready now. |
j2kun
force-pushed
the
stop-shipping-openfhe
branch
from
1797de5 to
cebb498
Compare
| if "openfhe" in name and not any( | ||
| x in name for x in ["core", "pke", "binfhe"] | ||
| ): | ||
| return [str(p.resolve())] |
There was a problem hiding this comment.
do we want to return a list of all the possible resolved p's? (core, pke, and binfhe)
This change modifies the PyPI distribution of HEIR to no longer build and ship OpenFHE. The user must now provide a self-provided OpenFHE installation (shared libs and heaers) via environment variables. As a consequence, we updated the CI to: 1. Not run frontend tests in bazel 2. After the main bazel build/test, add new steps that install openfhe, `pip install -e .`, and runs `pytest` to evaluate the frontend tests outside of bazel. I also discovered that more recent manylinux containers have a sanctioned clang, so I updated the cibuildwheel container to use 2_34. We may be able to go back to supporting 2_28 after the hermetic LLVM lands, because I believe they have hermetic glibc that you can pick explicitly.
j2kun
force-pushed
the
stop-shipping-openfhe
branch
from
cebb498 to
e59bbc1
Compare
j2kun
added
the
pull_ready
AlexanderViand
removed
the
pull_ready
AlexanderViand
left a comment
AlexanderViand
left a comment
There was a problem hiding this comment.
Sorry to be annoying about this, but can we avoid bumping minimum python from 3.10 to 3.11 again? This is a strong preference of the xdsl folks and wasn't hard to achieve in the past.
| description = "The HEIR compiler" | ||
| readme = "README.md" | ||
| requires-python = ">=3.10" | ||
| requires-python = ">=3.11" |
There was a problem hiding this comment.
Do we really need this version bump?
There was a problem hiding this comment.
Ah, I did that because we didn't actually test 3.10 or build any 3.10 wheels. I can put it back on Monday with a proper build.
| "torch>=2.8.0", | ||
| "setuptools>=80.9.0", | ||
| "cibuildwheel>=3.0.0", | ||
| "cibuildwheel>=4.0.0", |
There was a problem hiding this comment.
| "cibuildwheel>=4.0.0", | |
| "cibuildwheel>=4.0.0" ; python_version >= '3.11'", |
cibuildhweel 3+ does need python 3.11+ but since it's not a core dependency we can just gate it away.
(and maybe specify cibuildwheel>=2.0.0 ; python_version < 3.11 but I don't think that's even necessary
There was a problem hiding this comment.
Can't you use a newer cibuildwheel but build for an older python? I don't think there's a conflict here.
There was a problem hiding this comment.
You can build for really old target versions, but the package itself still requires a relatively new version to run on
There was a problem hiding this comment.
So this suggestion is purely about making sure uv sync doesn't error on 3.10
| if sys.version_info >= (3, 11): | ||
| from typing import TypeVarTuple, Unpack | ||
| else: | ||
| # TypeVarTuple/Unpack landed in typing in 3.11; use the backport on 3.10. |
There was a problem hiding this comment.
Why drop the 3.10 compatibility shim here?
|
This got merged just as I was getting into work. I'll push another fix restoring 3.10 |
|
It may also be worth noting that Python 3.10 is EOL this October (about 4 months away), so the xdsl folks should consider upgrading. |
3 participants
This change modifies the PyPI distribution of HEIR to no longer build and ship OpenFHE. The user must now provide a self-provided OpenFHE installation (shared libs and heaers) via environment variables.
As a consequence, we updated the CI to:
pip install -e ., and runspytestto evaluate the frontend tests outside of bazel.I also discovered that more recent manylinux containers have a sanctioned clang, so I updated the cibuildwheel container to use 2_34. We may be able to go back to supporting 2_28 after the hermetic LLVM lands, because I believe they have hermetic glibc that you can pick explicitly.
part of #3047