Utility programs: to lib or not to lib

1

When building new functionality that is almost exclusively used from a command line interface (think a small utility program), do you all build a binary crate, or a library crate with a bin.rs?

I've always been a bit unsure what to do, but recently I've started to think that a library crate is the better choice: building a library plus a binary to provide the user interface promotes good software design, reusability, and testability. I also thought that being able to publish something on crates.io was an advantage (for example, your code can benefit from crater testing), but this feels a little weird to me.

So I'm wondering what you all think? Do you tend toward, or prefer, binary crates or library crates?

3 Likes
2

I still enjoy the pattern of "main.rs that does options parsing and such,
and then calls into a lib.rs where everything is actually implemented".

10 Likes
3

My belief is that the things we want on the command line today are things we want to have programs be able to use tomorrow. I also believe that programs calling or parsing the output of cmdline tools is an anti-pattern that should be avoided.

Therefore I agree with you and would encourage the lib approach. Have a bin that does the cmdline parsing that then uses the lib. With Rust this should be hardly any more work than the bin-only approach.