Consider pinning the version of the build module for pyodide-build #4593
Replies: 7 comments 2 replies
-
Can you also add the error you get? We had build pinned for a long time, wouldn't be a terrible thing to pin it again. cc @henryiii. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
0_deploy_V1.txt |
Beta Was this translation helpful? Give feedback.
-
You forgot to copy the pyproject.toml. That does (correctly, due to your setup.py directly importing wheel) declare wheel as a dependency.
|
Beta Was this translation helpful? Give feedback.
-
Thanks @henryiii. I think we can close this then as a problem with the particular package and not with our build system. |
Beta Was this translation helpful? Give feedback.
-
FYI, pip 24 did the same thing as build 1.1, removing wheel from the fallback environment. But it probably works with pip because the (correct) pyproject.toml is present. I’d still recommend making the wheel import conditional on making a wheel (you can access this without importing wheel, actually, as setuptools has a way to access command classes). |
Beta Was this translation helpful? Give feedback.
-
Having the |
Beta Was this translation helpful? Give feedback.
-
My few months old builds are failing with a seemingly unrelated error of a missing package called wheel.
Installing, updating it or any of the related packages does not help.
What I have noticed is that the the build package on recent builds is version 1.1.1
Two weeks ago it was version 1.0.3
Manually pinning build==1.0.3 resolves my problem.
I was wondering if it would make sense to pin a version in pyodide-build.
Just for context here is my broken build:
Beta Was this translation helpful? Give feedback.
All reactions