Cargo VS cargo-outdated

Anybody knows when cargo-add will be distributed in stable cargo? Seems merged already.

In this case the libary is cargo

We might not need to reserve all typos. Soon cargo add will be in the stable release and we are hoping to have crates.io start suggesting it along with or in place of the Cargo.toml snippet. cargo-add could check for typos when you add a dependency. We could even check for registry squatting. If all else fails, we can check for security advisories when adding a crate.

There is no specific reason for a program that uses the XDG dirs on other unices to not use them on macOS, other than some idea that it's "alien".

You can have ~/.config/. Nothing in macOS prevents you from having it. And so, some programs do. The worst thing that happens is that, instead of having one directoy ~/.foo you now have one directory ~/.config/foo and nothing else in ~/.config. But as soon as you add the second thing that uses ~/.config, you now have two directories in there instead of a second dotdirectory in ~.

It's just that for a bunch of them the XDG path is only used if it exists - e.g. emacs predates the spec, so it uses ~/.emacs.d (and a few others) first.

Cargo doesn't use the XDG paths at all, apparently - https://github.com/rust-lang/cargo/issues/1734. However it also needs a directory for binaries (~/.cargo/bin) and ~/.local/bin isn't actually in the spec at the moment (https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/14).

Can I suggest using rustup (https://rustup.rs/) to manage the rust tool chain and cargo (installed by rustup, but https://github.com/rust-lang/cargo) to manage builds and packages? It makes it much easier to handle projects especially with dependencies. The book (https://doc.rust-lang.org/stable/book/title-page.html) outlines how to use it and some stuff for advancing with rust

The package in question was updated to v3.0 three weeks ago, at the same time as heron itself. Even when I explicitly define the dependency pointing at the git repo (which should find the package subdirectory):

I believe this is the relevant tracking issue

Use Cargo.toml instead of package.json. You’ll want to add them manually (instead of using a command like yarn add)

I'd add cargo-outdated for checking for outdated dependencies. cargo-tree is also useful, but that's built into cargo itself for some time already.

Some combination of cargo-outdated and cargo-msrv could probably do this in a slightly more manual fashion.

So it merges functionality of cargo-outdated and cargo-audit?