Skip to content

"Caused By" error on missing relative dependency could be clearer #14924

@spease

Description

@spease

Problem

When attempting to cargo install an application from a git repo on another computer

cargo install --git "ssh://spease@host/home/spease/projects/backuplib" backup-check

it failed with a series of "failed to load manifest errors". The issue was that an underlying dependency was outside the project tree as I had to modify a third-party library and the PR never got accepted or rejected, so I never updated the dependency to a permanent value. However even though this was simple, I didn't immediately catch this due to the displayed error.

error: failed to load manifest for workspace member `/Users/spease/.cargo/git/checkouts/backuplib-a3cf582f8b68cb05/681a95d/backup-check`
referenced by workspace at `/Users/spease/.cargo/git/checkouts/backuplib-a3cf582f8b68cb05/681a95d/Cargo.toml`

Caused by:
  failed to load manifest for dependency `backuplib`

Caused by:
  failed to load manifest for dependency `twox-hash`

Caused by:
  failed to read `/Users/spease/.cargo/git/checkouts/backuplib-a3cf582f8b68cb05/twox-hash/Cargo.toml`

Caused by:
  No such file or directory (os error 2)

Because each item was separated by "Caused by:", I interpreted it as a list of errors rather than a cause-and-effect / inverted stack trace. So I started working down the list, when I needed to go from the bottom and work up.

I also interpreted "Failed to load" as meaning that the path specified for the dependency was missing, when in actuality it just seems to mean that an error was encountered.

Finally, the path specified for the dependency that was outside the project tree used a generated path that was clearly on the local machine (macOS home folder vs Linux home folder), so in scanning the rest of the "caused by" it didn't immediately stand out as a broken relative path that wasn't able to be copied over due to being outside the project folder.

Steps

No response

Possible Solution(s)

For something like this, I think the following error message structure would be much clearer:

Error:
    `No such file or directory (os error 2)` when opening path `../../twox-hash` for dependency `twox-hash` needed by `backuplib`

Absolute path:
    /Users/spease/.cargo/git/checkouts/backuplib-a3cf582f8b68cb05/twox-hash/Cargo.toml

Needed by:
    /Users/spease/.cargo/git/checkouts/backuplib-a3cf582f8b68cb05/681a95d/backuplib/Cargo.toml
    /Users/spease/.cargo/git/checkouts/backuplib-a3cf582f8b68cb05/681a95d/backup-check/Cargo.toml

In workspace:
    /Users/spease/.cargo/git/checkouts/backuplib-a3cf582f8b68cb05/681a95d/Cargo.toml

Notes

It looks to me like relative path notation when doing a remote checkout can end up capturing something outside of the generated folder for that workspace. That doesn't seem great.

Version

cargo 1.80.0 (376290515 2024-07-16)
release: 1.80.0
commit-hash: 37629051518c3df9ac2c1744589362a02ecafa99
commit-date: 2024-07-16
host: aarch64-apple-darwin
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.7.1 (sys:0.4.72+curl-8.6.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 15.1.1 [64-bit]

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Error and warning messages generated by Cargo itself.A-manifestArea: Cargo.toml issuesC-bugCategory: bugS-needs-designStatus: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions