Rust 1.66 | Hacker News Reader

Rust 1.66

blog.rust-lang.org

59 pointsburntsushi6 comments

Of the changes that didn't make the blog post (but is buried in the release notes) is that cargo-publish will now block until the publish process is complete. This affects you if you are releasing a series of crates in a row or released one crate and then immediately tried to use it in another. Before, it would break and you had to retry. Now it will just work.

This was the original behavior but it was implemented server-side. Things were getting backed up, so they made server processing asynchronous which broke people's workflows. Tools like cargo-release compensated for that. With 1.66, we now have client-side blocking until the crate is published.

Speaking of cargo remove, see also cargo-edit [0] from which adding and removing originally came, as well as cargo-binstall [1] which installs binaries rather than compiling from source every time. The binaries are updatable with cargo-update [2].

The latter two can replace a package manager for Rust related utilities, as I often find that those in OS package repositories are often not as up to date as directly from cargo.

[0] https://github.com/killercup/cargo-edit

[1] https://github.com/cargo-bins/cargo-binstall

[2] https://github.com/nabijaczleweli/cargo-update

Moving cargo-edit into cargo has been a slow but fruitful process. Besides any of the technical work involved in getting this into cargo (e.g. making `toml_edit` production-ready), we had a long discussion about the exact UX (https://internals.rust-lang.org/t/feedback-on-cargo-add-befo...) even after its been sitting in `cargo-edit` for years.

`cargo-set-version` has a less clear path to being merged as there isn't as much visible demand for it (there isn't even a `cargo` issue for it).

`cargo upgrade` has the problem of trying to solve too many people's needs and is stuck in UX discussion limbo (https://internals.rust-lang.org/t/feedback-on-cargo-upgrade-...). I'm starting to formulate thoughts on which compromise I want to make to allow that to move forward again.

In addition to the plugins you mentioned, some more worth calling out:

- cargo-release

- cargo-deny

- cargo-semver-checks

- cargo-hack

- cargo-expand

- cargo-nextest

You can also see

- All the plugins at https://crates.io/categories/development-tools::cargo-plugin...

- What people have proposed be added: https://github.com/rust-lang/cargo/issues?q=is%3Aopen+is%3Ai...

> In Rust 1.62.0 we introduced cargo add, a command line utility to add dependencies to your project. Now you can use cargo remove to remove dependencies.

It's only little but I love this addition.

Really grateful for the work cassaundra did to get this in!

A part of the cargo-remove work that didn't make it into 1.66 is that cargo-remove will garbage collect references to the remove dependency. For example, if you remove the last reference to a `workspace.dependency`, it'll automatically remove the workspace entry for you! The original RFC for `workspace.dependency` declared having an unused entry an error but we didn't think it was worth the implementation cost / runtime overhead and now we can automatically clean it up!

Pretty small update this time. I guess they can't all be adding GAT-level features.

Reply on news.ycombinator.com