museun / cargo-whatfeatures

a simple cargo plugin to get a list of features for a specific crate
Apache License 2.0
73 stars 1 forks source link

Problems trying out 0.9.11 #79

Closed dholroyd closed 1 week ago

dholroyd commented 1 week ago

(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.)

$ cargo whatfeatures --version
cargo-whatfeatures 0.9.11

First attempt after reading the help text, run in my project directory,

$ cargo whatfeatures Cargo.toml 
ERROR: failed to start `cargo metadata`: No such file or directory (os error 2)

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,

$ cargo whatfeatures $PWD/Cargo.toml 
thread 'main' panicked at /home/david/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cargo-whatfeatures-0.9.11/src/printer/workspace.rs:51:31:
called `Option::unwrap()` on a `None` value

I got the same results as above adding the --manifest-path option.

museun commented 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?

museun commented 1 week ago

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.

museun commented 1 week ago

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.

dholroyd commented 1 week ago

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.)

museun commented 1 week ago

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