Sarge
Sarge is a small, opinionated arguments parser. It uses clever techniques to make parsing arguments as quick and painless as possible. It has zero dependencies, reducing cruft and therefore build times. Here are some differences with the industry standard, clap:
- No dependencies
- Leads to small size:
232KiBcompared to clap's5.4MiB(shallow clone of git repository |du -h) - Leads to fast builds:
0.64sto clap's19.97s, clean build (times on my old laptop over cellular)
- Leads to small size:
- No proc macros
- Provides a powerful regular macro through the default feature
macros
- Provides a powerful regular macro through the default feature
- Provides a cleaner builder-like interface
- Isn't a jack-of-all-trades
- Doesn't support weird syntaxes
- All struct-style arguments have to have a long form
- Focuses on sensible defaults to minimize effort for everyone involved
- Doesn't provide help messages, completions, etc.
- Doesn't support nested arguments
- Isn't run by committee
- Not out of disdain, but there's only one maintainer, so...
- Isn't a giant project
- Those can be great, but can also be overkill
- Has first-class support for custom argument types
One or more of the above might be a deal-breaker. That's okay! I made sarge so that there was a good, light alternative to clap. Use whichever one suits your use-case. I personally use sarge for all my projects, because they're all small; this forces me to be active in maintaining it.
Features
- Zero dependencies (yes, this is my favorite feature)
- First-class "builder" pattern, but better
- Used to be the only option, so it's been fleshed out
- Non-proc macro for building a CLI interface
- Supports environment variables
- Custom argument kinds
- Simply impl a trait and it works like a builtin
- Thread safety when using the builder
- N/A when using the struct macro
- The following builtin argument types:
booli8/i16/i32/i64u8/u16/u32/u64f32/f64StringVec<T>whereT: ArgumentType
Grocery list
- Better unit testing
- There are tests for everything, but they aren't top-priority yet
- More maintainers
- Better code styling
- Probably remove
clippy::pedanticand get more fine-grained
- Probably remove
- Better, fuller docs
- They're usable, but (like tests) aren't top-priority
Contributing
The above mostly stem from two things: a single maintainer, and a lack of interest. If you use sarge, please star it on GitHub, or even better, leave issues! It tells me that others are interested in the project, and pushes me to be more rigorous and develop it more.
As for the single maintainer, I am happy to accept pull requests. Just make
sure it passes cargo fmt, cargo clippy and cargo test. Some features may
be out of scope for sarge; the goal isn't infinite customizability, so if a
feature significantly complicates anything, it might not be accepted.
Examples
Here's a giant example using all the bells and whistles; note that if you
disable the macros feature, this won't compile:
use *;
// This is a normal, non-proc macro. That means sarge is still
// zero-dependency! The syntax may seem a little strange at first, but it
// should help greatly when defining your CLI interface.
sarge!
// Some utility macros to make this example less verbose.
Environment Variables
Sarge also supports using environment variables as arguments. This is automatically
done when you call parse, or you can use parse_env to pass the variables yourself.
It takes an Iterator<Item = (String, String)> as a reciever, the same type
std::env::args() returns.
Here's a quick example:
use *;
Custom Types
Using the ArgumentType trait, you can implement your own types. Here's an
example (taken from src/test/custom_type.rs):
use Infallible;
use ;
;