kbknapp
Refactor project into lib and CLI
I've been writing a few xtasks recently and I want to statically include cargo-outdated in my xtasks binary.
Are there any reasons why cargo outdated should not have a lib.rs and API?
cargo-edit allows for linking as a lib, so it's possible.
The benefits of statically linking cargo-outdated into an xtask binary are:
- Provide more detailed data from the lib API.
- Allow the user to provide dependencies such as
cargo_metadata::Metadata. - Avoid other team members having to install various cargo plugins.
The use case that triggered this request is:
I want to make an xtask that lists outdated dependencies and interactively allows the user to update the version in Cargo.toml.
This can already be solved as the json output includes the crate_name and I can go search for the crate by name in the current dir. Or I could include add cargo_file_path to the json output to avoid searching my project workspace for something cargo-outdated already knows.
What I would like is to simply be able to:
- Call cargo-outdated through an API
- Give it the crate metadata
- Specify some options (the API equivalent of
--root-deps-only) - Get back detailed information about the dependencies, including the path to the packages Cargo.toml.
Maybe just return the
cargo_metadata::Package?
