cargo waits on package cache lock when my crate has 0 dependencies

[matthiaskrgr]

Problem

It seems that cargo is waiting for the lock on the package cache during cargo check, even if I have 0 dependencies stated in my Cargo.toml and we could theoretically build right away.

Steps

1. cargo new myproj
2. run cargo update on a large repo (i.e. servo)
3. at the same time cargo check in myproj => Blocking waiting for file lock on package cache although myproj has 0 dependencies.

Possible Solution(s)

Skip looking into the cache entirely if we don't have any dependencies specified in Cargo.toml?

Notes

No response

Version

cargo 1.70.0-nightly (0e474cfd7 2023-03-31)
release: 1.70.0-nightly
commit-hash: 0e474cfd7b16b018cf46e95da3f6a5b2f1f6a9e7
commit-date: 2023-03-31
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 8.0.1-DEV (sys:0.4.61+curl-8.0.1 vendored ssl:OpenSSL/1.1.1q)
os: Manjaro 22.1.0 (Talos) [64-bit

[weihanglo]

I feel like it is a niche use case, and a bit error-prone to implement this, since the acquisition of package cache lock occurs in multiple different places. It's also not easy to understand where a lock is needed by just looking into the piece of code here. That said, it is a nice-to-have optimization, just not that urgent.

[epage]

The cargo-script workflow could put more of an emphasis the overhead for cargo run with warm caches and without any dependencies.

[matthiaskrgr]

Hm, my current usecase is that I grab a random rs file, copy it into into main.rs of a dummy crate I created with cargo new (so no deps) and then run cargo miri run/test on it. All this can happen on several files at a time, in parallel. https://github.com/matthiaskrgr/icemaker/blob/master/src/run_commands.rs#L704 Luckily the locking of the cargo home does not seem to be that much of a bottle neck though..

I'm not sure if the cargo-script workflow can do anything for miri right now :sweat_smile:

[matthiaskrgr]

oh what is funny is that when I do

CARGO_HOME=. cargo check

on a dummy crate that has 0 deps, cargo is actually smart enough to NOT create a new cargo home dir and fetch registry index etc, as there are 0 required dependencies.

but when a cargo home is already established, we lock it, to then find out that we have 0 deps, and then unlock it again, I guess? 🧐

anyway, slightly amused at the idea that giving each process its own CARGO_HOME is potentially faster than than having a shared one :)

[epage]

I ran

$ cargo new cargo-11924
$ cd cargo-11924
$ CARGO_HOME=foo cargo check
$ ls -a foo
.  ..  build  .global-cache  .package-cache  .package-cache-mutate

so it doesn't seem like the behavior is different than non-existent CARGO_HOMEs. Yes, it didn't fetch anything but it won't fetch anything with an existing CARGO_HOME also.