cargo install in a workspace gives confusing errors #7599

Firstyear · 2019-11-17T23:45:47Z

Problem

Running cargo install in a workspace gives a confusing error:

error: found a virtual manifest at `/Users/william/development/rsidm/Cargo.toml` instead of a package manifest

Attempting to use a manifest (which is what the common google searches tell you to do) also errors:

 cargo install --manifest-path kanidm_tools/Cargo.toml
error: Found argument '--manifest-path' which wasn't expected, or isn't valid in this context

This is because all the current online uses seem to be cargo build not cargo install (is anyone installing anything?).

As well, the other suggested option is --all: which also fails:

cargo install --all
error: Found argument '--all' which wasn't expected, or isn't valid in this context
	Did you mean --all-features?

Steps

create a workspace with multiple members.
in the workspace run "cargo install"

Possible Solution(s)
cargo install in a workspace could

give a better or constructive error such as "did you mean to use --path"?
make --all mean something
just work by default (install all binaries of the workspace)

Notes

The text was updated successfully, but these errors were encountered:

ehuss · 2019-12-03T16:15:57Z

Somewhat of a duplicate of #4101 and #7124, but I'll leave this open since it is clearly written. 😄

Unfortunately, `cargo install` does not support workspaces yet: rust-lang/cargo#7599 Alternatively, we use `cargo build`, which will respect the Cargo.lock configuration. It however, does require a bit more hoop jumping to determine which binaries were built and install them. Introudce _install_workspace_artifacts() to install the built executables into the correct paths. Testing has covered executables and libraries, though dynamic linking is not quite yet supported by the rust plugin (at least in my testing, it will have unmnet dependencies on libstd-<id>.so). We can address that feature gap in the future, but likely doesn't affect snap users because they are probably using the standard linking process which doesn't require libstd (likely due to static linking of those dependencies). `cargo build` has an unstable flag option for `--out-dir` which may simplifiy the install process, but is currently unavailable for stable use: https://doc.rust-lang.org/cargo/reference/unstable.html#out-dir Add/update tests for coverage. Signed-off-by: Chris Patterson <chris.patterson@canonical.com>

Unfortunately, `cargo install` does not support workspaces yet: rust-lang/cargo#7599 Alternatively, we use `cargo build`, which will respect the Cargo.lock configuration. It however, does require a bit more hoop jumping to determine which binaries were built and install them. Introudce _install_workspace_artifacts() to install the built executables into the correct paths. Testing has covered executables and libraries, though dynamic linking is not quite yet supported by the rust plugin (at least in my testing, it will have unmnet dependencies on libstd-<id>.so). We can address that feature gap in the future, but likely doesn't affect snap users because they are probably using the standard linking process which doesn't require libstd (likely due to static linking of those dependencies). `cargo build` has an unstable flag option for `--out-dir` which may simplifiy the install process, but is currently unavailable for stable use: https://doc.rust-lang.org/cargo/reference/unstable.html#out-dir Add/update unit tests for coverage and add a spead test. Signed-off-by: Chris Patterson <chris.patterson@canonical.com>

If a plugin detects an error prior to attempting to build a part's source, it can raise SnapcraftPluginAssertionError() with a brief reason and optional details. SnapcraftEnvironmentError() was also a viable choice, but it's slated to be nuked and as it is too generic. This seems like a fair middle ground that can be re-used across the the plugins when they make an assertion that fails to check out at runtime. Unfortunately, `cargo install` does not support workspaces yet: rust-lang/cargo#7599 Alternatively, we use `cargo build`, which will respect the Cargo.lock configuration. It however, does require a bit more hoop jumping to determine which binaries were built and install them. Introudce _install_workspace_artifacts() to install the built executables into the correct paths. Testing has covered executables and libraries, though dynamic linking is not quite yet supported by the rust plugin (at least in my testing, it will have unmnet dependencies on libstd-<id>.so). We can address that feature gap in the future, but likely doesn't affect snap users because they are probably using the standard linking process which doesn't require libstd (likely due to static linking of those dependencies). `cargo build` has an unstable flag option for `--out-dir` which may simplifiy the install process, but is currently unavailable for stable use: https://doc.rust-lang.org/cargo/reference/unstable.html#out-dir Add/update unit tests for coverage and add a spead test. Signed-off-by: Chris Patterson <chris.patterson@canonical.com>

denglitong · 2020-05-31T12:55:51Z

now cargo install --path <binary_crate> works, it's great! my rustc version is rustc 1.43.1 (8d69840ab 2020-05-04), thanks your nice job!

plwalsh · 2021-04-07T22:40:31Z

Any recent updates on this issue or plans of addressing it? I also ran into the confusion of trying to run cargo install from the root of my workspace and not understanding the error message. But it definitely would be nice if it behaved the same as cargo build from the workspace root behaves, where it acts upon all packages in the workspace.

PrismaPhonic · 2021-05-03T21:52:34Z

^^ re-up, agreed. Why would cargo build work but not cargo install? This seems like a bug.

ralyodio · 2022-04-29T12:14:20Z

i get this error too...what is solution please?

ralyodio · 2022-04-29T12:15:31Z

I tried cargo build and got this error: error: linking with cc failed: exit status: 1

The `%{cargo_install}` macro is expanded adding a `--path .` paramenter at the end. With virtual workspaces we need to specify a different `path` per binary crate, but this cannot be done if there is already one `path` parameter. This patch removes the `--path .` parameter, so an user can now use: %{cargo_install} --path binary-crate Related with: rust-lang/cargo#7599 Signed-off-by: Alberto Planas <aplanas@suse.com>

The `%{cargo_install}` macro is expanded adding a `--path .` paramenter at the end. With virtual workspaces we need to specify a different `path` per binary crate, but this cannot be done if there is already one `path` parameter. This patch adds a path parameter (-p) in the cargo_install macro, that if it is not present will default to the current "--path ." one. Now an user can specify a different path parameter: %{cargo_install -p binary-crate} --no-default-features Related with: rust-lang/cargo#7599 Signed-off-by: Alberto Planas <aplanas@suse.com>

corneliusroemer · 2023-05-17T11:58:26Z

TLDR fix: specify the path to the executable package with --path <binary-package-path>, in my case:

cargo install --path packages_rs/nextclade-cli

Fixed this error:

$ cargo install                            
error: found a virtual manifest at `/Users/corneliusromer/code/nextclade/Cargo.toml` instead of a package manifest

For a repo with this structure where the current work directory is the root:

.
├── Cargo.toml
└── packages_rs
   ├── nextclade
      └── Cargo.toml
   ├── nextclade-cli
      └── Cargo.toml
   └── nextclade-web
      └── Cargo.toml

I totally agree that the error message should be more helpful. The bad error message is surprising given Rust's usually very helpful errors.

epage · 2023-11-03T03:05:01Z

#7194 is somewhat similar in that part of the problem is that path sources (both cargo install and dependencies) are non-recursive and we try to load that Cargo.toml itself.

Firstyear added the C-bug Category: bug label Nov 17, 2019

ehuss added A-workspaces Area: workspaces Command-install labels Dec 3, 2019

mash-graz mentioned this issue Dec 28, 2020

'cargo install' doesn't work because of "virtual manifest" denoland/deno#8899

Closed

aplanas mentioned this issue Jan 16, 2023

marcos.cargo: drop path from install Firstyear/cargo-packaging#3

Merged

Jarmos-san mentioned this issue Jul 30, 2023

Added Pre-Commit hook support Kampfkarren/selene#541

Closed

epage added the S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. label Nov 3, 2023

mreid-tt mentioned this issue Nov 27, 2023

Upgrading Firefox Sync Server to Syncstorage-rs SynoCommunity/spksrc#5939

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cargo install in a workspace gives confusing errors #7599

cargo install in a workspace gives confusing errors #7599

Firstyear commented Nov 17, 2019

ehuss commented Dec 3, 2019

denglitong commented May 31, 2020

plwalsh commented Apr 7, 2021

PrismaPhonic commented May 3, 2021

ralyodio commented Apr 29, 2022

ralyodio commented Apr 29, 2022

corneliusroemer commented May 17, 2023 •

edited

Loading

epage commented Nov 3, 2023

cargo install in a workspace gives confusing errors #7599

cargo install in a workspace gives confusing errors #7599

Comments

Firstyear commented Nov 17, 2019

ehuss commented Dec 3, 2019

denglitong commented May 31, 2020

plwalsh commented Apr 7, 2021

PrismaPhonic commented May 3, 2021

ralyodio commented Apr 29, 2022

ralyodio commented Apr 29, 2022

corneliusroemer commented May 17, 2023 • edited Loading

epage commented Nov 3, 2023

corneliusroemer commented May 17, 2023 •

edited

Loading