hi-rustin/cargo-information

https://github.com/rust-lang/cargo/issues/948

I am always open to new opportunities(except for web3 and blockchain). I'm particularly interested in relocating to other countries, especially Europe, Canada, or the United States. If you are interested in working with me, please feel free to contact me.

My name is Rustin Liu and I’m a passionate software engineer who specializes in distributed systems and dev tools.

As a software engineer at PingCAP, my main focus is on enhancing TiDB, which is an open-source distributed SQL database. I am also a core maintainer of TiCDC, which is a Change Data Capture (CDC) system for TiDB.

I am also a big believer in open source. I contribute to the Rust community, where I am working on two areas:

• Package management
  • Cargo - Cargo downloads your Rust package’s dependencies, compiles your packages, makes distributable packages.
  • crates.io - The Rust package registry.
• Async Runtime
  • console - A debugger for async rust!
  • tokio-console-web - A web-based debugger for async rust!

I used to be a maintainer of Rustup, which is a toolchain manager for Rust.

Programming languages I primarily code in:

• Rust
  • 
  • 
  • 
  • 
  • 
  • 
  • 
    • Build my own operating system
    • Leetcode solutions in Rust
• Golang
  • 
  • 
  • 
• TypeScript/JavaScript
  • 
  • 
  • 

Languages I speak:

• English (Professional working proficiency)
• Chinese (Native proficiency)

You can contact me by clicking badges above or below badges, or e-mailing me directly. My email address is on my GitHub profile.

cargo-information's Issues

Support full version requirements

Dear maintainer,

As a potentially-orthogonal continuation to #98, it would be nice as well if the version specification was extended to accept fully-capable SemVer version requirements, i.e. something that semver::VersionReq parses. It would be used in the same context: determining the latest version that cargo install would actually install.

Currently, only Cargo's package specs are used and they are a bit lightweight: only rough selections may be used. Furthermore, from what I can see in src/ops/info.rs and src/ops/view.rs, the filtering is done entirely offline and on all available versions, so this shouldn't be too big of a change either, right?

Cheers,
Paul.

Path to merging into cargo

This is track what work is needed and what we should include in the stabilization report

Remaining work

• Feedback on Pre-RFC
• Evaluate #20
• Evaluate #22
• Evaluate #23
• Evaluate #26
• Evaluate #29
• Stabilization report
• Merge

Prior Art

Deferred

• Evaluating specifying non-registry packages to look at via --path or --git

Out of scope

• Flags for changing the heuristics for selecting the package version to show (--ignore-rust-version, --manifest-path, etc)

Drop `^` from version requirements

semver::VersionReq doesn't track default operators (anymore) so we always get a leading ^. We should strip that for a cleaner look.

How should we handle the difference in dependency name vs package name?

Currently, we show the package name. Which is more meangful to the viewer?

Report package owners?

If the person knows an existing publisher, that might instill some confidence.

What dependency fields might be relevant to indicate?

As of #18, we dim optional dependencies.

What else might we want to show, and how?

• public?

What version should we default to within a workspace?

Currently, we default to the highest version in the workspace. What if that isn't the direct dependency but is a transitive dependency?

Options

• Pick highest
• Prioritize the parent directories package
• Prioritize if its a direct dependency of any workspace member

How to handle non-registry dependencies?

Currently we show all dependencies as name@req. That is less meaningful for path and git dependencies. How should we handle these?

Allow version selection with PackageIdSpec's

If I run cargo info clap in a project, it picks the highest version in use. What if I want to look at the latest version, or an earlier MSRV-compatible version?

We should accept PackageIdSpecs so you can do cargo info [email protected] and it picks the latest version.

When the requested package isn't in the lockfile, filter for an MSRV compatible version

This way we show what will be more likely to be relevant to the reader.

If the inferred manifest does not have an MSRV, we can fallback to rustc --version (cargo::util has something for this)

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update rust crate snapbox to 0.5.7

Detected dependencies

cargo

Cargo.toml

• anstyle 1.0.6
• anyhow 1.0.80
• cargo 0.77.0
• cargo-credential 0.4.2
• cargo-util 0.2.9
• clap 4.5.1
• color-print 0.3.5
• crates-io 0.39.2
• pathdiff 0.2.1
• semver 1.0.22
• snapbox 0.5.6
• trycmd 0.15.0

github-actions

.github/workflows/rust.yml

• actions/checkout v4
• actions/cache v4
• actions/checkout v4
• actions/cache v4
• actions/checkout v4
• actions/cache v4

---

• Check this box to trigger a request for Renovate to run again on this repository

Report crates.io metrics?

cargo-info includes a lot of different metrics exposed via the crates.io API (so separate from the Index and Cargo.toml)

Looking at the list, some that might be useful include

• recent download count (popularity)
• last updated (give a feel for how active development is)

Unsure how we should handle third-party registries.

Display latest version compatible with input spec

Dear maintainer,

Whenever using cargo info <pkg>@<spec> where <spec> does not select the latest version, the command displays the latest version available on the used registry. This is a fine feature that should be kept, but in addition, it would be nice if it could also display the latest available version that matches the given spec. This would enable me to easily detect whether a currently-installed package is in the latest version available that matches a configured spec or not, to then know whether it needs an update or not.

For example, if <pkg> has 0.1.0, 0.1.1 and 0.2.0 available, then cargo info <pkg>@0.1 should display version: 0.1.0 (latest compatible 0.1.1) (latest 0.2.0) or even just version: 0.1.1 (latest 0.2.0), but that might too drastic of a change -- I'll let you judge on that.

From what I can see in src/ops/info.rs and src/ops/view.rs, all versions of a package are retrieved from the registry and then filtered offline to only keep the ones compatible, so adding this should not be too big of a change, right?

Cheers,
Paul.

How should we render features?

Currently, its:

features:
    name = [activation1, activation2, ...]

We could render this as a tree:

features:
  parent1
    child1
  parent2
    child1*

If we track activations, we could do a hybrid where explicit activations (see rust-lang/cargo#10681) are always roots and inactive features are processed like a normal tree

features:
  default
    default-dep1
    default-dep2
  other
  default-dep2*
  disabled1
  disabled2    

The question then is how to handle activations

• Currently, default is the only thing activated
• For rust-lang/cargo#10681 , we'd need to choose a package (from parent directory?) to identify activations from the dependency entry
• Alternatively, we could check the feature resolution and just show whatever is default activated for the workspace (ie what cargo-metadata would treat as activated)

Should we default to a rust-version compatible package when one isn't in a workspace?

So I run cargo info clap

• In a workspace but I'm not using it yet
• Out of a workspace

It might be useful for us to default to an MSRV compatible version.

Some choices (which we might pick different answers in and out of a workspace)

• Check the MSRV of the parent directories package
• Check the lowest MSRV of all workspace members
• Check rustc --version

We could have --ignore-rust-version support

`cargo info` with offline should give better error message

Right now:

error: could not find `vlq-bij` in registry `https://github.com/rust-lang/crates.io-index`

Expected:

error: attempting to make an HTTP request, but --offline was specified

URL package not works

Tested locally and it still doesn't work:
normal case without customized registry:

cargo info https://github.com/rust-lang/crates.io-index/clap
    Updating crates.io index
error: could not find `https://github.com/rust-lang/crates.io-index/clap` in registry `https://github.com/rust-lang/crates.io-index`

I printed the two URLs:

1. spec URL: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("github.com")), port: None, path: "/rust-lang/crates.io-index/clap", query: None, fragment: None }
2. source id URL: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("github.com")), port: None, path: "/rust-lang/crates.io-index", query: None, fragment: None }

As you can see the paths are different, so it won't match. I think this is a bug from cargo library: https://github.com/rust-lang/cargo/blob/9e9349d3f7a4ef687992b2f248bbe4fc5bfea09f/src/cargo/core/package_id_spec.rs#L146

    /// Tries to convert a valid `Url` to a `PackageIdSpec`.
    fn from_url(mut url: Url) -> CargoResult<PackageIdSpec> {
        if url.query().is_some() {
            bail!("cannot have a query string in a pkgid: {}", url)
        }
        let frag = url.fragment().map(|s| s.to_owned());
        url.set_fragment(None);
        let (name, version) = {
            let mut path = url
                .path_segments()
                .ok_or_else(|| anyhow::format_err!("pkgid urls must have a path: {}", url))?;
            let path_name = path.next_back().ok_or_else(|| {
                anyhow::format_err!(
                    "pkgid urls must have at least one path \
                     component: {}",
                    url
                )
            })?;
            match frag {
                Some(fragment) => match fragment.split_once([':', '@']) {
                    Some((name, part)) => {
                        let version = part.parse::<PartialVersion>()?;
                        (String::from(name), Some(version))
                    }
                    None => {
                        if fragment.chars().next().unwrap().is_alphabetic() {
                            (String::from(fragment.as_str()), None)
                        } else {
                            let version = fragment.parse::<PartialVersion>()?;
                            (String::from(path_name), Some(version))
                        }
                    }
                },
                None => (String::from(path_name), None),
            }
        };
        Ok(PackageIdSpec {
            name,
            version,
            url: Some(url),
        })
    }

We used the original URL as the package spec URL. In the matches function, we use it to match the source ID URL directly.

  /// Checks whether the given `PackageId` matches the `PackageIdSpec`.
    pub fn matches(&self, package_id: PackageId) -> bool {
        if self.name() != package_id.name().as_str() {
            return false;
        }

        if let Some(ref v) = self.version {
            if !v.matches(package_id.version()) {
                return false;
            }
        }

        if let Some(u) = &self.url {
            if u != package_id.source_id().url() {
                return false;
            }
        }

        true
    }

Panic when you query a local crate with unpublished version under its package root

Reproduce:

1. clone a published crate
2. bump a version
3. cargo info <crate>
4. Bang!

$ RUST_BACKTRACE=1 cargo info my-unpublished-crate
thread 'main' panicked at /home/weihanglo/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cargo-0.75.1/src/cargo/sources/registry/mod.rs:463:9:
assertion failed: source_id.is_remote_registry()
stack backtrace:
   0: rust_begin_unwind
             at /rustc/1a06ac5b5d7c9331e8de1aa1fd7e9d3533034b44/library/std/src/panicking.rs:645:5
   1: core::panicking::panic_fmt
             at /rustc/1a06ac5b5d7c9331e8de1aa1fd7e9d3533034b44/library/core/src/panicking.rs:72:14
   2: core::panicking::panic
             at /rustc/1a06ac5b5d7c9331e8de1aa1fd7e9d3533034b44/library/core/src/panicking.rs:127:5
   3: cargo::sources::registry::RegistrySource::remote
   4: cargo_information::ops::info::info
   5: cargo_info::command::info::exec
   6: cargo_info::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

version: 299e38e8787f43642b11d6e7bf687efa2c973aae