MathiasPius / lapce-crates

Apache License 2.0
1 stars 0 forks source link

Should not check crates.io for dependencies with relative path #3

Open timboudreau opened 3 months ago

timboudreau commented 3 months ago

Using a workspace, which contains some crates that have the same name as crates from crates.io (it's hard to guess what is already used when creating a crate), the plugin marks dependencies as not being an up-to-date version when the metadata clearly points to a local path (and the version must match what is found there).

A simple solution would be, when encountering a line such as

config = { version = "0.1.0", path = "../config" }

to just ignore the line. A better solution would be, if a version is present, to flag it as an error if the version in, e.g., ../config/Cargo.toml does not match the dependency declaration.

See screen-shot.

Screenshot 2024-06-24 at 12 30 45 PM
MathiasPius commented 3 months ago

According to the cargo documentation, the version tag should indeed be checked against the local dependency if a path is specified: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-locations

It is possible to specify both a registry version and a git or path location. The git or path dependency will be used locally (in which case the version is checked against the local copy), and when published to a registry like crates.io, it will use the registry version. Other combinations are not allowed.

However, it also states that:

The version key always implies that the package is available in a registry, regardless of the presence of git or path keys.

So unless you are planning to somehow publish these crates whose names conflict with existing packages on crates.io, I think it would make more sense to simply remove the version tag altogether.