Skip to content
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

Workspace path is not fully resolved #7686

Closed
jfrimmel opened this issue Dec 8, 2019 · 3 comments
Closed

Workspace path is not fully resolved #7686

jfrimmel opened this issue Dec 8, 2019 · 3 comments
Labels
A-workspaces Area: workspaces C-bug Category: bug S-needs-mentor Status: Issue or feature is accepted, but needs a team member to commit to helping and reviewing.

Comments

@jfrimmel
Copy link

jfrimmel commented Dec 8, 2019

Setup

I have the following (potentially strange) setup:

$project
├── a
│  ├── Cargo.toml
│  └── src
│     └── main.rs
├── b
│  ├── Cargo.toml
│  └── src
│     └── main.rs
├── c
│  ├── Cargo.toml
│  └── src
│     └── main.rs
└── Cargo.toml # containing `workspace.members = ["a", "b", "c"]`

Problem

If I'm executing cargo install --path ../c in directory b the following error occurs:

error: package `/home/jfrimmel/git/$project/a/Cargo.toml` is a member of the wrong workspace
expected: /home/jfrimmel/git/$project/b/../Cargo.toml
actual:   /home/jfrimmel/git/$project/Cargo.toml

It seems like the paths are not canonicalized before comparison.

Reproducation

~ $ mkdir mwe
~ $ cd mwe/
~/mwe $ cargo new a
     Created binary (application) `a` package
~/mwe $ cargo new b
     Created binary (application) `b` package
~/mwe $ cargo new c
     Created binary (application) `c` package
~/mwe $ cat <<EOF > Cargo.toml
[workspace]
members = ["a", "b", "c"]
EOF
~/mwe $ cd b
~/mwe/b $ cargo install --path ../c --force
error: package `/home/jfrimmel/mwe/a/Cargo.toml` is a member of the wrong workspace
expected: /home/jfrimmel/mwe/b/../Cargo.toml
actual:   /home/jfrimmel/mwe/Cargo.toml
~/mwe/b $ 

Metadata

$ cargo --version
cargo 1.41.0-nightly (8280633db 2019-11-11)
@jfrimmel jfrimmel added the C-bug Category: bug label Dec 8, 2019
@jfrimmel
Copy link
Author

jfrimmel commented Dec 8, 2019

The relevant code part:

for member in self.members.clone() {
let root = self.find_root(&member)?;
if root == self.root_manifest {
continue;
}
match root {
Some(root) => {
failure::bail!(
"package `{}` is a member of the wrong workspace\n\
expected: {}\n\
actual: {}",
member.display(),
self.root_manifest.as_ref().unwrap().display(),
root.display()
);
}

Maybe just some calls to fs::canonicalize() have to be added.

@ehuss ehuss added the A-workspaces Area: workspaces label Dec 8, 2019
@epage epage added the S-needs-mentor Status: Issue or feature is accepted, but needs a team member to commit to helping and reviewing. label Nov 3, 2023
@epage
Copy link
Contributor

epage commented Nov 3, 2023

In cargo, we don't use std::fs::canonicalize but some path helpers from cargo utils.

@weihanglo
Copy link
Member

This should be resolved by #10335 in Rust 1.60.0. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-workspaces Area: workspaces C-bug Category: bug S-needs-mentor Status: Issue or feature is accepted, but needs a team member to commit to helping and reviewing.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants