cargo

Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros. This is because building in debug mode also compiles proc macros in debug mode, so while the macro itself compiles quickly (because it's an unoptimized build), it ends up running slowly (because it's an unoptimized build). I know this from observing a ~90s difference between debug and release builds, of a large (mostly auto-generated) crate that had a couple of thousand `#[derive(serde::*)]`s. [1] This doesn't affect most users, because first-party macros like `#[derive(Debug)]` etc are not slow because they're part of rustc and are thus optimized regardless of the profile, and even with third-party macros it is unlikely that they have thousands of invocations. Even

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:

Seriously. I think Rust has a lot going for it, but I will say this: the type inference in Rust combined with its expressive type system can make sophisticated programs very hard to follow. My experience was with extensively reading the cargo codebase; trying to figure out what the resulting type of an expression that maps/filters/collects over other complex expressions is a chore. For example, I find it very hard to figure out what the type of public_dependencies is in this declaration: https://github.com/rust-lang/cargo/blob/8fbc8459d59f3acecdb6... This is the same kind of thing that makes JavaScript challenging to read. It requires a lot of discipline on the author’s part to make it clear what is going on, and even the best of us lack discipline at scale.

This seems like a good contribution. It would great if one of these "lists of blessed crates" itself becomes blessed and sticks around! This list seems like it was created by somebody with "good taste", and I enjoy the amount of description. https://lib.rs has some basic features to make it faster to sniff test various crates. Eg, I like being able to see a summary of the authors, and things like "maintained by RustCrypto team" just looking at the summary. My suspicion is that some concept of graph centrality (perhaps via authors?), and perhaps counting applications which aren't usually distributed via cargo (this contributing to crates.io downloads), could both yield a better popularity metric. But the trend stuff is pretty reasonable already. Some related efforts at documenting pseudo-official crates (in contrast to gigantic "awesome" l

For those unaware, some ask "why" - No need to look up the version (though some IDEs do it for you) - Auto-completion - It shows you what features the crate has and whether they are activated, making it easier to discover features you need to enable or what you can remove to improve compile times - Make it easier to document how to add a set of dependencies needed for a project (e.g. "Run `cargo add serde serde_json -F serde/derive`") - The opportunity for more QoL improvements, see https://github.com/rust-lang/cargo/issues?q=is%3Aopen+is%3Ai... It is impressive the amount of work it took to get this ready. I took over the effort almost a year ago and at times was working full time on it (thanks to my employer). Just my part included - a near rewrite of the format-preserving toml parser (toml_edit) - a major revamp of the UI - a major r

This is what I was used to at a prior day job (another one just didn't keep a version in source). When I took over cargo-release [0], this was also the default though not anymore. Benefits of keeping the last version - Easier to detect when a change occurred since the last release - (Rust specific) It makes it harder to patch a registry dependency with a git dependency because the versions will never align [1]. This is why the default changed in cargo-release. - The "next version" is just speculation. Will the next release bump the pre-release version, patch, minor, or major? A downside to keeping either last version or next version is if someone builds from master, the bug report could be confusing unless you include the git hash (and whether the repo was dirty). I've seen some advocate for not keeping a version in source at all [2].

She gave the reason in the piece, and linked to the ticket she filed: https://github.com/rust-lang/cargo/issues/10352

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

I might be misreading this on an iphone screen but as i follow the logic here: https://github.com/rust-lang/cargo/blob/a77ed9ba87bfeaf3c275... A cargo build ends up there calling into the resolver’s resolve_ws_with_opts() which would refresh the lockfile. Not resolve_with_previous() which would use the lock file as-is. The only reason this sticks in my mind is i ran into an issue building bat after i made some changes, i obviously assumed it was my changes so went through the process of debugging and backing out my changes until finally i was back to a virgin branch and still failing - passing —frozen —locked fixed it.

> I don't think there's any clear argument you can make on first principles for which of those is actually the case. I don't understand why someone would try to argue from first principles here, it just seems like such a bizarre approach. Anyway, it's not just a security issue. Malicious packages and security fixes are only part of the picture. Other issues: - Despite a team's promise to use semantic versioning, point releases & "bugfix" releases will break downstream users - Other systems for determining the versions to use are much more unpredictable and hard to understand than estimated (look at Dart and Cargo) https://github.com/dart-lang/pub/blob/master/doc/solver.md https://github.com/rust-lang/cargo/blob/1ef1e0a12723ce9548d7...

PR to stabilize -Ztimings as --timings: https://github.com/rust-lang/cargo/pull/10245