implement basic check flag

[azdle]

This implements a very basic version of a check flag. If any dependencies that should move to the workspace are found, they are printed to stderr and the command exits with a FAILURE ExitCode.

If any dependencies are found in a workspace member, but that have an existing workspace dependency that can be directly used (that is if the workspace Cargo.toml doesn't need to be modified) nothing is printed, but the command still exits with FAILURE.

Ideally the check flag would work like cargo fmt --check where a diff is shown, but that would require extensive refactoring.

---

Not sure if you'll be okay with ^ limitations. If not I may be able to find some time in the future to try making proper diffs possible, not sure.

Also, I've added ExitCode as the return from auto_inherit in lib.rs. That's more of a command specific thing, but I thought it would be good to differentiate between "failed to run the command" and "the command ran successfully, but indicated failure". I can make it something else if you find using std::process::ExitCode for that too gross.

resolves #2

[hdoordt]

Hi @azdle, sorry about the delay!

I had a look at your changes, and it looks good in general. I think we can live without the diff for now. About this part in your description, though:

If any dependencies are found in a workspace member, but that have an existing workspace dependency that can be directly used (that is if the workspace Cargo.toml doesn't need to be modified) nothing is printed, but the command still exits with FAILURE.

Would you mind updating the code such that an informative error gets printed in these cases?

[hdoordt]

I rebased on main just now

[azdle]

If any dependencies are found in a workspace member, but that have an existing workspace dependency that can be directly used (that is if the workspace Cargo.toml doesn't need to be modified) nothing is printed, but the command still exits with FAILURE.

Would you mind updating the code such that an informative error gets printed in these cases?

That's part of what would require pretty extensive refactoring. The thing I could do is have separate error messages for "crate shouldn't have this" and "workspace should have this" if you're okay with split/duplicated error messages.

I've pushed up a commit with that option.

I also pushed up a couple test cases to show what I mean:

$ cd new-child-dep/
$ cargo run --manifest-path ~/downloads/cargo-autoinherit/Cargo.toml -- autoinherit --check
   Compiling cargo-autoinherit v0.1.5 (~/downloads/cargo-autoinherit)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.87s
     Running `~/downloads/cargo-autoinherit/target/debug/cargo-autoinherit autoinherit --check`
`regex` should be declared as a workspace dependency.
`regex` should inherit from a workspace dependency.
$ cd ../uninherited-existing-child-dep/
$ cargo run --manifest-path ~/downloads/cargo-autoinherit/Cargo.toml -- autoinherit --check
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running `~/downloads/cargo-autoinherit/target/debug/cargo-autoinherit autoinherit --check`
`regex` should inherit from a workspace dependency.

AFAIK, there's currently no one place where it's possible to decide if something needs to be changed in both the workspace toml and the crate toml.

---

I think a better way to do all of this would be to separate planning what needs to be changed for all files from actually modifying all the files. So that at some point you have a list of all the changes that need to be made and you can decide if you just print them out or actually make the change. (I think this would also make it a lot easier to implement #16. It should also make it easier to make proper diffs or at least have crate names in the error messages.)

I've got a bit of time on my hands at the moment, would you be interested in a refactor PR that does that instead of this PR?

[hdoordt]

@azdle

would you be interested in a refactor PR that does that instead of this PR?

I think it's a good idea to separate the planning from the actual modification. I think the best way to go about this is by setting up some sort of small proof-of-concept that we can then iterate on.

@LukeMathWalker What do you think?

[hdoordt]

Rebased on main again