Skip to content

The toml workflow job will now install taplo-cli using cargo-binstall #18773

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

LikeLakers2
Copy link
Contributor

@LikeLakers2 LikeLakers2 commented Apr 9, 2025

Objective

Avoid needing to compile taplo-cli every time we use it in CI.

Solution

Use cargo-binstall to install taplo-cli.

cargo-binstall is different from cargo install, in that it will first attempt download a precompiled taplo-cli binary, in an attempt to avoid compilation. However, failing that (for any reason), it will fall back to installing the binary through cargo install.

While installing taplo-cli from source is relatively fast (around 50-60s), this still provides a small speed boost to the job, by not needing to spend time compiling taplo-cli from source at all.

Note on how this affects workflows

This PR does have one side-effect: Should taplo-cli need to be compiled from source at all, it is no longer guaranteed to use the latest stable version of rustc. This may be considered problematic, as taplo-cli doesn't appear to have a MSRV policy.

However, its MSRV (as of writing this PR) is 1.74 - a nearly 1.5 year old version. This seems to imply that, if taplo-cli's MSRV is ever updated, it won't be to the absolute latest stable version of Rust until said version is a few months old.

Combine that with the Github Actions runner images being frequently (and automatically) updated to use the latest Rust tooling, and I don't foresee taplo-cli's MSRV being an issue in 99% of circumstances.

Still, there is the possibility of it being a problem in those 1% of circumstances - if this is a concern, please let me know and I'll try to fix it.

Testing

This change was tested on my local fork. The specific job run can be found here.

@alice-i-cecile alice-i-cecile added A-Build-System Related to build systems or continuous integration C-Performance A change motivated by improving speed, memory usage or compile times S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Apr 9, 2025
Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a solid argument. I'm not worried about the MSRV: Bevy's MSRV will almost certainly run ahead of this.

@mockersf
Copy link
Member

mockersf commented Apr 9, 2025

I proposed to use cargo-quickinstall a few years back but was shot down. If no one is opposed to that anymore, let's do it! 👍

Co-authored-by: François Mockers <francois.mockers@vleue.com>
Copy link
Member

@TrialDragon TrialDragon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Outside of the one issue, looks good overall.

Copy link
Member

@TrialDragon TrialDragon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM; seems to be running correctly in the CI checks on this PR.

@TrialDragon TrialDragon added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Apr 17, 2025
@alice-i-cecile alice-i-cecile added this pull request to the merge queue May 6, 2025
Merged via the queue into bevyengine:main with commit b19f644 May 6, 2025
34 checks passed
@LikeLakers2 LikeLakers2 deleted the project/workflows/install-taplo-from-binstall branch May 6, 2025 02:35
andrewzhurov pushed a commit to andrewzhurov/bevy that referenced this pull request May 17, 2025
…bevyengine#18773)

# Objective
Avoid needing to compile `taplo-cli` every time we use it in CI.

## Solution
Use [cargo-binstall](https://github.com/cargo-bins/cargo-binstall) to
install `taplo-cli`.

cargo-binstall is different from `cargo install`, in that it will first
attempt download a precompiled `taplo-cli` binary, in an attempt to
avoid compilation. However, failing that (for any reason), it will fall
back to installing the binary through `cargo install`.

While installing `taplo-cli` from source is relatively fast (around
50-60s), this still provides a small speed boost to the job, by not
needing to spend time compiling `taplo-cli` from source at all.

## Note on how this affects workflows
This PR does have one side-effect: Should `taplo-cli` need to be
compiled from source at all, it is no longer guaranteed to use the
latest `stable` version of `rustc`. This may be considered problematic,
as `taplo-cli` doesn't appear to have a MSRV policy.

However, its MSRV (as of writing this PR) is `1.74` - a nearly 1.5 year
old version. This seems to imply that, if `taplo-cli`'s MSRV is ever
updated, it won't be to the absolute latest stable version of Rust until
said version is a few months old.

Combine that with [the Github Actions runner images being frequently
(and automatically) updated to use the latest Rust
tooling](actions/runner-images#11957), and I
don't foresee `taplo-cli`'s MSRV being an issue in 99% of circumstances.

Still, there is the possibility of it being a problem in those 1% of
circumstances - if this is a concern, please let me know and I'll try to
fix it.

## Testing

This change was tested on my local fork. The specific job run can be
found
[here](https://github.com/LikeLakers2/bevy/actions/runs/14350945588/job/40229485624).

---------

Co-authored-by: François Mockers <francois.mockers@vleue.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Build-System Related to build systems or continuous integration C-Performance A change motivated by improving speed, memory usage or compile times S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants