Quite disappointed with this change. The project was never slow to begin with, and the amount of data it has to process is so small that it’s honestly ridiculous to rewrite it into Rust.
But now that it is not pure Python any more, one can await problems that will arise when trying to run it on a non-mainstream platform. No Windows ARM, no PyPy, no musl+aarch64… The probability of having to compile it when installing is not worth it for a primarily CI-used tool.
@kytta@gaborbernat Do you need to run linters on a non-mainstream platform?
I run the linting on the CI in its own dedicated workflow, so it's on a vanilla Ubuntu. Then all the exotic platforms only run tests.
I prefer it this way: if the linting fails and tests pass, I know it's (usually) just an easy fixed needed. If linting is run with tests on all platforms, I don't know if a failure is from tests or linting. It's a form of "fail fast".
@hugovk@gaborbernat yeah, maybe not CI, although I do offload some CI tasks onto an Alpine (musl) machine with ARM64, which does not have wheels in this case. But it's also a problem for developers, who might work from an ARM-based Surface and might not want to get a whole Rust compiler to just run a tool locally.
But yes, I usually don't run linters in all platforms; I'm sorry for the confusing wording ofy previous post 😅
@kytta@gaborbernat Looking at the main dependency, there are wheels for musl (x86-64 and i686), manylinux (x86-64, s390x, ppc64le, ARMv7l, ARM64, i686) and a couple each for Windows and macOS.
Add comment