[REQUEST] Package standalone ruff binary & include in GitHub releases

[rahul-theorem]

Context for the request
I just came across ruff and it looks like a very promising pyflakes/isort replacement. We use Bazel to manage a large Python monorepo, and this seems like it could help shorten some critical dev loops and lead to a perf improvement in CI.

However, given the way that ruff is packaged (ie. the main python entrypoint just shells out to the ruff binary under the hood), it doesn't seem like we'll be able to use rules_python + the entry_point macro from pip-parse to include ruff as a tool in our build (see bazelbuild/rules_python#1000 for more discussion)

Request
OTOH, if ruff were available as a standalone binary (along w/ the source tgz/zip) as part of the GitHub release, we can pull this into our build w/ http_archive/set it up as an executable tool. This seems like it should be fairly straightforward to bake into the release process as a release asset

[rahul-theorem]

@charliermarsh I'd be happy to contribute this so we can run ruff as an aspect in our Bazel project if this is a contribution you'd be willing to accept.

[charliermarsh]

@rahul-theorem - Yeah I'm happy to include the binaries in the GitHub release. My only hesitation is that right now, our release process only includes building the Python wheels (which themselves package the per-platform binaries), so it may require more work than merely adding the wheels to the release (unless that works too?).

[rahul-theorem]

Thanks for the quick reply @charliermarsh!

I just took a look through ruff.yaml & also saw the same; does the maturin action also have the ability to build a standalone binary, or will it only emit a wheel? If attaching the wheel to the GH release is the only thing that's possible, then we can continue to use rules_python to download the wheel and hack around this bazel limitation in some other way.

[charliermarsh]

maturin build should build the binary as a side-effect:

> rm target/debug/ruff
> maturin build
> ls target/debug/ruff
target/debug/ruff

(In release, that would be target/release/ruff, just using debug for expediency.)

So, without looking at the YAML deeply, I think it should be enough to just wire those built binaries up to the final GitHub release -- we're already building them, and they exist in the filesystem after running maturin.

[rahul-theorem]

Ah nice. Happy to take a swing at this later today or tomorrow - from some basic testing (without running it as part of our build) it's pretty mind-blowing how quickly it can lint our mono-repo!

[charliermarsh]

That's what I like to hear :)

[messense]

Note that we should name the artifact something like ruff-<rustc target name>.tar.gz/zip, for example ruff-x86_64-unknown-linux-gnu.tar.gz, so that cargo-binstall and taiki-e/install-action will also be able to use them.

[rahul-theorem]

@messense is that something that maturin could handle during the maturin build step? Not quite familiar with how it names the compiled binary. See the linked PR, can incorporate your suggestions to name them correctly.

[messense]

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 it.

[charliermarsh]

cargo dist would be interesting for this.

[charliermarsh]

My current thinking is that we'll just copy ripgrep's release workflow, except instead of creating the GitHub Release, we'll trigger the workflow by the creation of a GitHub Release.

[lopopolo]

@rahul-theorem I'm intrigued by the ruff aspect you mentioned for your Python Bazel project. Is this setup something you could share? I'd like to do the same.