issues, advisories, alternatives #443
Replies: 2 comments
-
I think I see why you would think so - from a PoV of someone using proofs before using a crate, browsing something like Without these extra fields reviews will look easier indeed, but they are actually harder to use programatically. If you have 200 deps in your projects, and as you update dependencies and version things change, there's no way you're going to be actively reading all reviews for them. You run rather set I think it's reasonable that some frontends and implementation can just ignore, not ask not show this data to make it simpler. A log of data in proofs is explicitly optional. |
Beta Was this translation helpful? Give feedback.
-
In my experience so far, I am convinced that every developer must take the human responsability of checking every crate in the dependency tree. Yes, it is easily 200 crates for a project. It is impossible to review all the source code. But the trust can be achieved also by trusting the publisher/author/owner or by trusting other crev reviews. |
Beta Was this translation helpful? Give feedback.
-
More I look into cargo-crev Rust Reviews and more I see that there is no need for: issues, advisories, alternatives.
What do you think? Is it necessary to have this data in a special format?
Or they can just be mentioned inside the comment text?
Without them, the reviews look much easier to understand and start using.
Beta Was this translation helpful? Give feedback.
All reactions