hi-rustin / cargo-information Goto Github PK
View Code? Open in Web Editor NEWhttps://github.com/rust-lang/cargo/issues/948
License: MIT License
https://github.com/rust-lang/cargo/issues/948
License: MIT License
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
default
is the only thing activatedIf the person knows an existing publisher, that might instill some confidence.
Reproduce:
cargo info <crate>
$ 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
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.
Currently we show all dependencies as name@req
. That is less meaningful for path and git dependencies. How should we handle these?
semver::VersionReq doesn't track default operators (anymore) so we always get a leading ^
. We should strip that for a cleaner look.
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
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.
Currently, we default to the highest version in the workspace. What if that isn't the direct dependency but is a transitive dependency?
Options
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.
Public dependencies aren't stable yet, so we don't have to block on having them done but we should track notes on ideas we have during development
This is track what work is needed and what we should include in the stabilization report
Remaining work
Prior Art
Deferred
--path
or --git
Out of scope
--ignore-rust-version
, --manifest-path
, etc)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:
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 }
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
}
From this comment, I think it makes sense to show the crates.io and version's docs links if the registry is crates.io.
I believe we already add the docs's link here:
cargo-information/src/ops/view.rs
Line 92 in 18959db
So we need to add the crates.io link to allow users to click it from the terminal.
Currently, we show the package name. Which is more meangful to the viewer?
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
Unsure how we should handle third-party registries.
So I run cargo info clap
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)
rustc --version
We could have --ignore-rust-version
support
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)
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These updates have been manually edited so Renovate will no longer make changes. To discard all commits and start over, click on a checkbox.
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
Cargo.toml
anstyle 1.0.6
anyhow 1.0.82
cargo 0.78.1
cargo-credential 0.4.4
cargo-util 0.2.10
clap 4.5.4
color-print 0.3.5
crates-io 0.40.0
pathdiff 0.2.1
semver 1.0.22
snapbox 0.5.9
trycmd 0.15.1
.github/workflows/rust.yml
actions/checkout v4
actions/cache v4
actions/checkout v4
actions/cache v4
actions/checkout v4
actions/cache v4
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.