Allow pure-Python, rust-free build

[barracuda156]

A switch to maturin in https://github.com/python-pendulum/pendulum/pull/755 has broken pendulum for systems without rust. It is desirable to restore pure-Python build, at least optionally.

[Secrus]

What architectures/systems are you missing? We could add them to our build matrix, so that you can use pre-built wheels.

[barracuda156]

@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]

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]

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]

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]

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]

@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

[ariebovenberg]

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:

1. 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
2. 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.
• setuptools itself is 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.

edit: clarify legacy vs deprecated, grammar

[RickGutleberNVR]

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]

@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]

Thank you. If I can figure out what's needed, I will do so.