Semver compare my crate with a crate in `$HOME/.cargo/registry`

[FirelightFlagboy]

Steps to reproduce the bug with the above code

1. Create a new project foobar & move into it:

   cargo new foobar
   cd foobar
   

2. Add the crate sample to the new project foobar:

   cargo add sample
   

3. Create a new project named sample

   cd ../
   cargo new --lib sample
   cd sample
   

4. Run semver-checks in the new project sample

   cargo semver-checks check-release
   

Actual Behaviour

When I perform the check-release, it result in the following error:

--- failure trait_missing: pub trait removed or renamed ---

Description:
A publicly-visible trait cannot be imported by its prior path. A `pub use` may have been removed, or the trait itself may have been renamed or removed entirely.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
       impl: https://github.com/obi1kenobi/cargo-semver-check/tree/v0.20.0/src/lints/trait_missing.ron

Failed in:
  trait sample::Sample, previously in file $HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/sample-0.1.0/src/lib.rs:14
       Final [   0.005s] semver requires new major version: 1 major and 0 minor checks failed

From what I understand it compare my crate sample with the previous added crate sample from the other project foobar.

PS: I don't known if it's important but both crates sample have the same version 0.1.0

Expected Behaviour

Not compare my crate with a crate of the same name present in the registry

Generated System Information

Software version

cargo-semver-checks 0.20.0

Operating system

Linux 6.2.12-zen1-1-zen

Command-line

$HOME/.cargo/bin/cargo-semver-checks semver-checks --bugreport 

cargo version

> cargo -V 
cargo 1.68.2 (6feb7c9cf 2023-03-26)

Compile time information

• Profile: release
• Target triple: x86_64-unknown-linux-gnu
• Family: unix
• OS: linux
• Architecture: x86_64
• Pointer width: 64
• Endian: little
• CPU features: fxsr,sse,sse2
• Host: x86_64-unknown-linux-gnu

Build Configuration

N/A

Additional Context

No response

[obi1kenobi]

Hey, thanks for opening the issue. I'm a bit confused about the specifics here, so please help me understand the context here.

To semver-check a crate, cargo-semver-checks needs a "baseline" version to compare the current code against. The baseline is what the breaking changes it finds are breaking compared to.

There are a variety of command-line options that allow specifying the baseline explicitly, and you've probably already found them in the output of cargo semver-checks check-release --help. If no baseline is specified, cargo-semver-checks defaults to using the largest prior version of the crate by that name that is available on crates.io.

You mentioned your expectation was:

Not compare my crate with a crate of the same name present in the registry

What do you feel should have happened instead?

[FirelightFlagboy]

Hello @obi1kenobi,

I'm a little ashamed that I didn't do cargo server-checks check-release --help before :sweat_smile:.

It's my first time trying cargo-semver-checks even tho I check the README, I miss the part about does-the-crate-im-checking-have-to-be-published-on-cratesio.

What do you feel should have happened instead ?

For my case, I would have liked that semver-checks directly use baseline-rev or ask me to be more precise on the method to compare the project.

Maybe semver-checks could have used the repository url on top of the crate name / version to known if they're the same crate :thinking:

To provide more context:

I'm working on a project where I have config files to be read/written to, for that I use a dedicated crate and I wanted to known when a have a breaking change on the configuration file formats by trying out cargo-semver-checks.

That crate is not made to be publish on crates.io so having it being compared against one on crates.io is problematic :sweat_smile:.

[obi1kenobi]

Maybe semver-checks could have used the repository url on top of the crate name / version to known if they're the same crate

This is an interesting idea. It would require a nontrivial amount of work at the moment, but good future work.

---

When you looked through the README, how did you go about looking for things to check out?

Is there something we can do to tweak the README structure to make that section easier to find for the next person who has this kind of use case?

Were there some keywords that could have helped you find what you were looking for?

[FirelightFlagboy]

Hi,

When I've looked through the README, I was already getting the errors.

I first see the quickstart then move on the FAQ. I've read the first item the scroll down and my eyes was catched by Does `cargo-semver-checks` have false positives that made me skip the relevant section Does the crate I'm checking have to be published on crates.io?.

Maybe adding a short note below the code snippet of the quickstart would improve that, maybe something like

> `cargo-semver-checks` will compare your crate with the one publish to <crates.io>.
> If you haven't published it take a look at [Does the crate I'm checking have to be published on crates.io?](https://github.com/obi1kenobi/cargo-semver-checks#does-the-crate-im-checking-have-to-be-published-on-cratesio)