Rustfmt: Strategy for original `rustfmt` crate on crates.io

Created on 22 Jul 2020  路  8Comments  路  Source: rust-lang/rustfmt

There's an ancient rustfmt crate on crates.io in addition to the current/maintained rustfmt-nightly crate, and the former's latest version is v0.10.0 which was published over 2.5 years ago.

This has been a source of confusion for users, particularly those new to the Rust ecosystem who go to crates.io looking for rustfmt, so I'm wondering if we should try to deprecate it/yank versions or if there's some valid usage patterns for that crate I'm just not aware of.

Thoughts?

Most helpful comment

I'm okay with renaming rustfmt-nightly to rustfmt. I would slightly caution against shipping a binary here.

I would like to eventually start a discussion about https://github.com/rust-lang/rust/issues/70651 for rustfmt, because the current situation with updating over rustc-ap crates is not great. If that's implemented then it's going to be really tricky to publish rustfmt to crates, and it's worth looking at how people use the crate and if something that uses the tool can instead be used.

All 8 comments

I prefer to keep rustfmt over rustfmt-nightly as a valid name as the latter naming is for historical reasons.

I would like to publish to both rustfmt-nightly and rustfmt, advocate for using rustfmt over rustfmt-nightly and yank rustfmt-nightly at some point the future.

cc @nrc @steveklabnik who own https://crates.io/crates/rustfmt.

Ahh okay, SGTM (and sorry for the duplicate :smile:)

I would like to publish to both rustfmt-nightly and rustfmt, advocate for using rustfmt over rustfmt-nightly and yank rustfmt-nightly at some point the future.

This would be my personal preferred strategy as well, but in a policy sense, I am not sure who is in charge of doing this. My guess is @rust-lang/devtools ?

Is there not a concern that users try to install rustfmt and break their installation? I've seen that happen, where the user runs cargo install rustfmt, and now they are using a 3 year old version, and don't understand why it sometimes doesn't work. If the rustfmt crate was yanked (or replaced with one that generates a compile error explaining the situation), that wouldn't happen. If the rustfmt crate is a new version, you kinda have a different problem where "my rustfmt works different from this other person's and I don't know why".

It's probably not too important, but something to be careful of.

Is there not a concern that users try to install rustfmt and break their installation?

That was the concern for me in opening this issue, as this definitely happens including as recently as yesterday. I think in the short term even something as simple as publishing a 0.10.1 with a deprecation notice in the readme that says "Don't use this, use rustup" would be helpful (though I like the compile error idea better) while we figure out what we should do longer term.

I'm okay with renaming rustfmt-nightly to rustfmt. I would slightly caution against shipping a binary here.

I would like to eventually start a discussion about https://github.com/rust-lang/rust/issues/70651 for rustfmt, because the current situation with updating over rustc-ap crates is not great. If that's implemented then it's going to be really tricky to publish rustfmt to crates, and it's worth looking at how people use the crate and if something that uses the tool can instead be used.

Sorry if this is the wrong place to ask, but: I just found the rustfmt-nightly crate on crates.io and wanted to use it to see how different versions of rustfmt might format some code differently. I see that the last version published was 1.4.21, but the latest rustfmt is 1.4.30, and Rust stable 1.48 and 1.49 both shipped with rustfmt newer than the one on crates.io. Was it intentional that this crate stopped being updated? (I know that I can use rust toolchain to add the versions I want, but that will download and store a lot more than I need just to test different rustfmt versions.) Thanks!

Was it intentional that this crate stopped being updated? (I know that I can use rust toolchain to add the versions I want, but that will download and store a lot more than I need just to test different rustfmt versions.) Thanks!

Not intentional, I just don't have access to push to crates :smile: Have started enumerating the install options in the Changelog and you'll note that the crates.io option is still listed as pending for all the recent releases.

If/when I get access to update the crate I'm happy to go back and publish these pending versions and any new ones that come along.

If you just want to grab a rustfmt binary though for some testing, you might find the GH releases (which contain pre-built binaries for several platforms) easier than trying to get a corresponding nightly needed to grab a specific version from crates.io

Was this page helpful?
0 / 5 - 0 ratings