You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@Secrus Thank you for responding!
Rust itself is not currently working on some platforms (OpenBSD on ppc, as an example of current releases, a lot of older macOS versions, perhaps a lot of tier-3 archs for *BSD), and it is not likely to get fixed soon.
But even on supported platforms bootstrapping rust from source is non-trivial (I am not even sure it is possible outside of x86). And not everyone is happy to install opaque binaries.
I doubt we will put much effort into this. We (maintainers) have limited time we can spend on the project and currently available build backends don't provide solutions that are elegant enough to consider IMHO. I am sorry that your use case is broken, but it seems like an edge case, not a mainstream case.
I will keep this issue open, maybe at some point we will get a better build backend that will allow elegant way to switch between compiled and pure Python builds.
I appreciate that you're leaving the door open. I have a command-line calculator tool I use a lot and I used to be able to run it on Android with Termux, but I have been unable to get it to work since I switched from arrow to pendulum. Again, another edge case, but I've considered switching away from pendulum so I can run it on my phone again.
So, this may be a naive question, but how hard would it be? I have a decent amount of Python experience and have been a professional software developer since the 80s. Is there an issue or some documentation that would explain what needs to be done?
@RickGutleberNVR one way of doing that could be to do what whenever did, adding their own backend implementation and handling the setuptools_rust dependency that way. I have few problems with this solution:
it relies on a dirty hack (maintaing special build backend code)
uses setuptools (which is legacy, has a history of random breakages and is pretty slow)
relies on setup.py script that encourages legacy practices
TL;DR it's either hacking our own build scripts or creating a totally new build backend that can do what is needed. Currently existing solutions are not good enough
Yeah, having a pure-Python and Rust build in parellel is tough. Like you say there is no “ideal” option.
In my experience this comes from the need to balance two competing demands:
The end-user that installs your library (e.g. in their container or dev machine) wants to be able to (easily) choose between Rust and pure-Python
Downstream library authors should (easily) be able to depend on your library in a way that’s agnostic of Rust or pure-Python.
There’s currently no option that scores full marks in both these areas. The most popular options seem to be (1) releasing a separate package on PyPI or (2) having some sort of flag (i.e. env var) to toggle which version to build from source.
it relies on a dirty hack (maintaing special build backend code)
uses setuptools (which is legacy, has a history of random breakages and is pretty slow)
relies on setup.py script that encourages legacy practices
It certainly felt hacky to implement yes! However, there's something to say in its defence:
The custom build backend is unfortunate, but it comes officially recommended. So it's not something that will break without announcement.
setuptoolsitselfis not legacy deprecated. It's definitely not my favorite bit of the Python ecosystem, but I can't deny it's probably the most future-proof tool out there due to its central position in the ecosystem.
I can't deny setup.py feels icky, I wish this was configurable too. In practice though, I don't find myself editing it often so the risk of spiraling complexity feels manageable.
I agree that it all seems like a really kludgy way to support different backends. Rust on the backend shouldn't be a second-class citizen. Perhaps my energies are best used by going back and trying again to get it to run on Android with the Rust backend.
Activity
Secrus commentedon Jul 25, 2025
What architectures/systems are you missing? We could add them to our build matrix, so that you can use pre-built wheels.
barracuda156 commentedon Jul 25, 2025
@Secrus Thank you for responding!
Rust itself is not currently working on some platforms (OpenBSD on ppc, as an example of current releases, a lot of older macOS versions, perhaps a lot of tier-3 archs for *BSD), and it is not likely to get fixed soon.
But even on supported platforms bootstrapping rust from source is non-trivial (I am not even sure it is possible outside of x86). And not everyone is happy to install opaque binaries.
Secrus commentedon Jul 27, 2025
I doubt we will put much effort into this. We (maintainers) have limited time we can spend on the project and currently available build backends don't provide solutions that are elegant enough to consider IMHO. I am sorry that your use case is broken, but it seems like an edge case, not a mainstream case.
I will keep this issue open, maybe at some point we will get a better build backend that will allow elegant way to switch between compiled and pure Python builds.
ConceptJunkie commentedon Jul 27, 2025
I appreciate that you're leaving the door open. I have a command-line calculator tool I use a lot and I used to be able to run it on Android with Termux, but I have been unable to get it to work since I switched from arrow to pendulum. Again, another edge case, but I've considered switching away from pendulum so I can run it on my phone again.
Secrus commentedon Jul 27, 2025
Like I said, I am open to allowing a rust-free version, but there are more urgent matters to address within the limited time.
RickGutleberNVR commentedon Jul 31, 2025
So, this may be a naive question, but how hard would it be? I have a decent amount of Python experience and have been a professional software developer since the 80s. Is there an issue or some documentation that would explain what needs to be done?
Secrus commentedon Jul 31, 2025
@RickGutleberNVR one way of doing that could be to do what
wheneverdid, adding their own backend implementation and handling thesetuptools_rustdependency that way. I have few problems with this solution:setuptools(which is legacy, has a history of random breakages and is pretty slow)setup.pyscript that encourages legacy practicesTL;DR it's either hacking our own build scripts or creating a totally new build backend that can do what is needed. Currently existing solutions are not good enough
ariebovenberg commentedon Aug 1, 2025
Yeah, having a pure-Python and Rust build in parellel is tough. Like you say there is no “ideal” option.
In my experience this comes from the need to balance two competing demands:
There’s currently no option that scores full marks in both these areas. The most popular options seem to be (1) releasing a separate package on PyPI or (2) having some sort of flag (i.e. env var) to toggle which version to build from source.
It certainly felt hacky to implement yes! However, there's something to say in its defence:
setuptoolsitself is notlegacydeprecated. It's definitely not my favorite bit of the Python ecosystem, but I can't deny it's probably the most future-proof tool out there due to its central position in the ecosystem.setup.pyfeels icky, I wish this was configurable too. In practice though, I don't find myself editing it often so the risk of spiraling complexity feels manageable.edit: clarify legacy vs deprecated, grammar
RickGutleberNVR commentedon Aug 4, 2025
Thanks for the explanation.
I agree that it all seems like a really kludgy way to support different backends. Rust on the backend shouldn't be a second-class citizen. Perhaps my energies are best used by going back and trying again to get it to run on Android with the Rust backend.
Thanks again, and keep up the good work.
Secrus commentedon Aug 4, 2025
@RickGutleberNVR I am more than open to adding code that would be required for Pendulum to run on Android. Feel free to open PR if needed.
RickGutleberNVR commentedon Aug 4, 2025
Thank you. If I can figure out what's needed, I will do so.