Closed dholroyd closed 1 week ago
You would use --manifest-path
for that.
Normally, this tool is used to get the features of a crate from crates.io, so the syntax cargo whatfeatures tokio
can be translated to the current crate by doing cargo whatfeatures .
(or cargo whatfeatures ../some/crate/
But since you tried it, is the cwd
a valid crate? Does cargo metadata --format-version=1
return some json? (cargo metadata
also has a --manifest-path
)
Also, what version of cargo are you using?
Also, I see the problem. manifest-path
takes a directory, not a Cargo.toml
path. Such as the root path for the crate/workspace.
There is some logic internally for finding Cargo.toml
based on this path, so I can add more logic to check to see if its a [Cc]argo.toml
explicitly and resolve correctly.
I pushed a new version, v0.9.12, that'll allow you to pass Cargo.toml
to --manifest-path
as intended.
It actually had logic for it. I use cargo_metadata
(which is a library for cargo metadata
) and it recently changed how "empty" paths were resolved. I was passing it ""
(for ./Cargo.toml
) which lead to an error, instead, if its empty, I tell it to use the pwd. (it wants the root directory, not the manifest file. --manifest-path in cargo terms is the root of the crate)
Some history: originally, cargo metadata was unstable when I created this 'plugin' and I had my own parsing logic, then when it was stabilized I switched to that because its less likely to break.
I intend on doing a soft rewrite of this sometime in the future, it was originally a 1-off "I need this now" type of project that kept growing. I want to add in logging and better command-line parsing. Currently, the command-line parsing is a majority of the frontend (70% or so of the code). With the addition of themes, its been a bit of a hassle so I want to also provide an optional configuration file.
(The old 'default' --theme colorful doesn't render properly on light terminals, so I switched to a basic palette-based theme.)
I want the user to be able to pick their own colors (and ascii-art). Internally it has supported this from day 1 but it was never exposed. Its still mostly unexposed.
0.9.12 addresses the error messages I was seeing, and exchanges them for An empty tree was returned by cargo-metdata
.
Experimenting with cargo metadata
directly:
$ cargo metadata --format-version=1
(produces json output)
$ cargo metadata --format-version=1 --manifest-path .
error: the manifest-path must be a path to a Cargo.toml file
$ cargo metadata --format-version=1 --manifest-path Cargo.toml
(produces json output)
$ cargo metadata --format-version=1 --manifest-path $PWD
error: the manifest-path must be a path to a Cargo.toml file
(Tangentially, I have now fixed the problem I was trying to debug by running whatfeatures in the first place; I had patched an intermediate dependency to have reqwest = { .. default-features=false, .. }
in one of the workspace members, but it still had a dependency on reqwest
in the workspace root - adding default-features=false
there too got things working.)
You can also use cargo tree
for that use case: https://doc.rust-lang.org/cargo/commands/cargo-tree.html notably with the -e and -f flags
(My goal was to try and work out why a transitive dependency of my local crate is pulling openssl via reqwests when I thought I had features/default-features configured to use rustls.)
First attempt after reading the help text, run in my project directory,
So I thought that maybe it needs to be more clear that this is a local path, and so made sure the value is fully qualified,
I got the same results as above adding the
--manifest-path
option.