-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wildcard version warnings generated git dependencies with fixed commit #488
Comments
This was fixed in #487 |
I'm still getting the same error with cargo-deny |
Sorry, thought this was fixed, I guess I need another edge case when git dependencies are direct like that instead of a patch on top of a version, which is the only way I use them. |
I believe I'm seeing this error, or a related one. I have a private package that is importing some other private packages from GitLab. Even with
There's no indication of why |
I took a look, and the code producing that error message doesn't actually check whether the allow-wildcard-paths option affected the result, just that you had it enabled. The actual reason for the failure is that whether or not the package is private, the git dependency doesn't count as a path dependency, and doesn't have any version requirements, so the wildcard ban always rejects it and can't be configured otherwise. I created a PR #599 which changes the behavior to treat |
@kpreid That looks like exactly what I hoped for from that option! Thanks! |
…ildcard-paths`. (#599) Fixes #488, making it possible to ban wildcards without also banning git-only dependencies. This may not be a perfect fit for some use cases — arguably `git` dependencies are less implicitly-versioned than `path` dependencies since `path` dependencies are typically always the same revision of the same repo, but `git` dependencies might be `cargo update`d to totally different code. But I can't think of an alternative that's equal-or-better in correctness short of introducing even more configuration. (I suspect that the whole idea of counting path-only or git-only deps as wildcard versions *ever* is wrong, because [the Cargo documentation says](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies) that “…the version key always implies that the package is available in a registry. version, git, and path keys are considered [separate locations](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-locations) for resolving the dependency” — which implies that a dep *without* `version` is different from a dep with a wildcard version. However, figuring out Cargo's behavior there and how cargo-deny should treat it feels like a rabbit hole I don't want to go down just to fix #488. I left a TODO comment suggesting further consideration.)
Describe the bug
When specifying a git dependency with a
rev
(i.e., fixed commit hash) entry, the version wildcard warning is triggered.However, because of the commit hash, an exact version has been specified.
To Reproduce
Steps to reproduce the behavior:
Add a git dependency with a commit specified, e.g.:
Ban wildcard dependencies in
deny.toml
:Run
cargo deny check
. A wildcard error is triggered for the git dependency.In our case, it looks like this (with two git dependencies):
Expected behavior
The wildcard warning is only triggered for git dependencies if the commit hash is not fixed, i.e. when the
rev
attribute is missing.Device:
0.13.5
The text was updated successfully, but these errors were encountered: