messense

You don't need to ship both a binary and a library to support `python -m ruff`, you can add a `__main__.py` and `execv` the ruff executable. For example, https://github.com/PyO3/maturin/blob/main/maturin/__main__.py

`ruff` still works as long as Python `scripts` directory is in `PATH`, it's same as current setup, no Python interpreter is involved when invoking `ruff` directly.

If you can use [`abi3` features](https://pyo3.rs/v0.17.3/building_and_distribution.html#py_limited_apiabi3), one wheel per platform, otherwise you need to build separate wheels for every Python version.

> This could be tricky to solve in a clean manner. Is it possible to solve with `CFLAGS`? For example: `CFLAGS_x86_64_unknown_linux_gnu=--sysroot=/path/to/target/sysroot`

Same issue.

> SIM106 ("Handle error-cases first") `SIM106` was removed in `flake8-simplify` due to too many false-positives: https://github.com/MartinThoma/flake8-simplify/pull/108

> do you know if Maturin can be used here to build a binary + library in one package? Not yet, supporting both lib and bin will complicate bindings detection...

Note that we should name the artifact something like `ruff-.tar.gz/zip`, for example `ruff-x86_64-unknown-linux-gnu.tar.gz`, so that [cargo-binstall](https://github.com/cargo-bins/cargo-binstall) and [taiki-e/install-action](https://github.com/taiki-e/install-action) will also be able to use them.

> is that something that `maturin` could handle during the `maturin build` step? No, maturin is for building python wheels so I don't think this is suitable to include in...

WIP in https://github.com/datafuselabs/opendal/pull/1613