-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'cargo metadata' fails on read-only file system #10096
Comments
Can you say more about your use case about why the |
The rustc-src rustup component doesn't have the root |
AFAIK |
Hi all - I ran into this issue while loading stdlib from a read-only location (attempting to access it from Nix store). I dug into this a bit and we can trace it down to cargo/src/cargo/ops/resolve.rs Lines 206 to 208 in b816d82
Since we don't write the lock file if the workspace is already marked as ephemeral, can we make the assumption that a read-only file system is inherently "ephemeral" and mark the workspace as such when creating it? The only other place where we check for cargo/src/cargo/core/workspace.rs Lines 1029 to 1037 in b816d82
Perhaps the |
I don't think a read-only fs ahould be considered ephemeral. It can be compiled (or get metadata retrieved) twice in whoch case the same dependency versions should be used. I see rust-analyzer only reloading cargo metadata when |
That makes sense - thanks for the insight. |
I would say even more important than being idempotent is it being a read-only operation. It is merely querying some information and state from a crate. If that information depends on things like the crate registry, I am not surprised by multiple queries returning different results. (I would not expect |
Most cargo commands will mutate the lockfile by default - you need to specify |
Yeah but those will just fail in that case, so that is not really helpful either. I honestly don't think there is a good reason that a query like |
The problem is that the lockfile is outdated. It is the solution. Ignoring lockfile write errors is a hack IMO. |
I see no good reason why it has to be like that. It certainly does not match my mental model at all.
Populating a cache is (conceptually) not a side-effect (formally speaking: a memoized function is observably pure). So I don't mind it changing |
rustup-toolchain: also prepare toolchain for vscode This is a work-around for rust-lang/cargo#10096.
Not sure if that is related, but there are also cases where |
It seems that this can trigger unnecessary rebuilds if a |
Unfortunately it seems that even if a lockfile exists that has all the required information to make the This bug means that just copying the lockfile from |
This seems to have stalled and I need it to be fixed. Whats needed for progress? |
@GenericNerdyUsername generally a good first step is to summarize the existing discussion and the different angles. For example, this thread has people with a couple different perspectives
So not much so far. Now, putting on my cargo hat, the problem I see with the latter is user intention. Today, you can run Some potential ideas
|
the solution seems pretty clear to me, if the user wants idempotent behavior but readonly is implemented, they can just update the lockfile beforehand. If the user wants RO behavior but idempotent is whats implemented, they're screwed (afaict). |
Another potential way of addressing this is error recovery. We report all errors that happened along the way and we report the metadata result (with a bad exit code). However, if someone wants to only ignore read-only file systems but error for the rest (like bad toml syntax), it might be difficult. |
What would be the downsides of not writing to the lockfile, other than needing another command beforehand if you want consistent output? |
any change on this? |
Just my 5 cents: That being said, it looks like there was an attempt to make an alternative solution with introducing a new flag in #10716 which was previously rejected.
@epage do you know by any change, if let's say #5707 was implemented, this issue is a strong enough argument for adding a new flag? I'd imagine the team wouldn't want to add new flags on a whim, but this issue seem to be impactful enough (e.g. people are experiencing Jetbrains IDEs such as rust-rover not working on read-only installations of rust) I'd love to take on #5707 implementation (as it seems to not be too complicated, at least at the moment), but as a first-time committer would be happy to hear opinion of someone's experienced. |
you could implement the ro mechanism without adding another flag by adding a special case for |
I think as long lockfile is written in another directory, original toml path can be RO (assuming we adding a |
We discussed #5707 in today's Cargo team meeting and are good with it moving forward. I've marked it as "Accepted" and laid out some high level information. I would recommend checking out https://doc.crates.io/contrib/ for more details on processes (both PR processes and "how to add unstable features") |
FYI: lockfile path PR has been merged. We can now call |
Just FYI, it will be available in next one or two nightly release rust-lang/rust#129178. |
Awesome, thanks. :) I guess now the question is whether RA is interested in using this feature to support running RA in situations where the sysroot is in a read-only location. I reopened rust-lang/rust-analyzer#10792 for that. |
Problem
I first reported this with rust-analyzer at rust-lang/rust-analyzer#10792: when running
cargo metadata
on a read-only file system, it fails sayingHowever, the action RA is trying to perform is fundamentally a read-only operation (querying for information about the rustc compiler crates).
I don't think the currently available flags provide any way to make this work on a read-only file system either (I tried
--frozen
but as expected it refuses to download required crates from the network). Even if my toolchain was on a read-write file system I would not want RA'scargo metadata
to change toolchain files, after all.Proposed Solution
cargo metadata
should either handle read-only file systems by falling back to not creating/updating the lock file -- or (IMO the right fix) it should not even attempt to mutate the workspace when what it is doing is a read-only operation like just determining the metadata.Notes
No response
The text was updated successfully, but these errors were encountered: