Proposal: Split crate into three to enable other use cases

[blacktemplar]

Hi, I find this project very cool. I found it because I was thinking about a totally different use case that would work with very similar tooling.

My idea was a tool that removes trait bounds and checks if the code still compiles without them (unfortunately clippy or the compiler cannot detect it at the moment for various reasons).

To achieve something like this it would be super cool if we could split this crate into a core library that is purely concerned about editing source files and checking the result. I envision a trait for finding mutations/mutants and users of the core library can provide one or more implementations of this trait (one would be the stuff done currently in cargo-mutants, the other use case is mine for removing trait bounds). The library exposes a way to collect such mutations given the trait implementation(s) and then provides a way to run checkers on them (in parallel). I would make the library unaware of the concrete checkers (either a trait, or simply the command line command via an argv vec and envs). Then besides this core library there would be the mutant generator used for cargo-mutants (that implements the trait from the core library) and a cli crate that combines everything and handles logging + output files etc...)

I am wondering what the maintainers of cargo-mutants think about this idea. If I start doing a push in this direction would you consider accepting such a split and making the core library available on crates.io to be used by other crates?

I could even envision making the cli reusable by having something like a plugin-system into which a user can just plug in the mutant generators they want to use and it will run them.

[sourcefrog]

Hi, I'm open to it but I don't think I want patches doing major refactors at this time. Splitting into multiple crates may be a good idea but it's probably not strictly necessary to start experimenting with this. You should already be able to link to cargo-mutants as a library, and unused code will just be discarded at link time. If there are interfaces that need to be more flexible or that need to be made public to support different uses we can certainly look into it. Martin

…

On Sun, May 17, 2026 at 4:41 AM blacktemplar ***@***.***> wrote: Hi, I find this project very cool. I found it because I was thinking about a totally different use case that would work with very similar tooling. My idea was a tool that removes trait bounds and checks if the code still compiles without them (unfortunately clippy or the compiler cannot detect it at the moment for various reasons <rust-lang/rust-clippy#9316>). To achieve something like this it would be super cool if we could split this crate into a core library that is purely concerned about editing source files and checking the result. I envision a trait for finding mutations/mutants and users of the core library can provide one or more implementations of this trait (one would be the stuff done currently in cargo-mutants, the other use case is mine for removing trait bounds). The library exposes a way to collect such mutations given the trait implementation(s) and then provides a way to run checkers on them (in parallel). I would make the library unaware of the concrete checkers (either a trait, or simply the command line command via an argv vec and envs). Then besides this core library there would be the mutant generator used for cargo-mutants (that implements the trait from the core library) and a cli crate that combines everything and handles logging + output files etc...) I am wondering what the maintainers of cargo-mutants think about this idea. If I start doing a push in this direction would you consider accepting such a split and making the core library available on crates.io to be used by other crates? I could even envision making the cli reusable by having something like a plugin-system into which a user can just plug in the mutant generators they want to use and it will run them. — Reply to this email directly, view it on GitHub <#615>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACUR4YYJAFGGES3EANGTS343GQPDAVCNFSM6AAAAACZBK4ZIGVHI2DSMVQWIX3LMV43GRDJONRXK43TNFXW4OZRGAYDQMBUGQ3Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>