Seems unfair. Version 4 was almost 3 years ago and and I can't recall any issue in that time.

Major versions have good quality migration guides. If only all libraries were developed with such professionalism.

https://github.com/clap-rs/clap/blob/v4.5.0/CHANGELOG.md

I'll take this opportunity to plug lexopt [0] a "pathologically simple CLI opt parser" crate. While I haven't quite had the opportunity to use it, I certainly will the next time it comes up.

[0]: https://docs.rs/lexopt/latest/lexopt/

I want to like docopt, but that the only data types it supports are boolean and string—if you want anything else, you have to do another round of parsing and error checking—destroys a lot of the advantage of using a high-level library for handling command-line arguments.

Not sure if it's on par with Clap, but for Python I don't see enough people talk about SimpleParsing: https://github.com/lebrice/SimpleParsing

It has quirks once you try to do something more complex/advanced, but for most of the simple stuff it's very nice to use.

Docopt is great! http://docopt.org/

There's implementations for other languages, too.

TIL about structopt, thanks.

According to that link you posted, many of the other argument parsers don't even generate help, only one other offers multiple interfaces, and none of the others are noted as having color or suggested fixes.

These aren't exactly esoteric features, and you're not going to get them for free. I'm happy to pay in space and compile time for clap to gain those features.

This isn't a case of the commandline app needing to be facebook, but rather putting the exponential gains we've made in storage space to good use providing features which should be table stakes at this point.

You’re right that there are only trade-offs in engineering. But the key to evaluating trade-offs is evaluating impact, and how long my dependencies take to compile when I first check out a repo or whether it takes 1ms or 2ms to parse my command line (if we’re even talking about something above microseconds) have no discernible impact for approximately all use-cases. If you’re making some odd CLI tool that has to run on an microcontroller with 1MB of RAM or something, fine, agonize about whether your command line parser is parsimonious enough. Otherwise you’ve abjectly failed to evaluate one of the most important trade-offs in engineering: whether something is even worth your time to think about.

Hmm isn't optimizing to save 690KiB for an optimised release binary and getting incremental builds to be significantly less than 400ms actually much closer to the after-mentioned "every web site must be able to scale like Facebook” type logic" ?

I am wondering how much of this can be mitigated by carefully designing feature flags, and make default feature set small.

Rust invites serious disregard for resources and time. Sadly, many will accept that invitation. But some won't.

I can understand this, if we were talking about JavaScript CLIs that requires GBs of dependencies. But 690KiB for modern computing is a drop in the ocean. It is not something you should base or make a consideration of unless you were doing embedded programming.

690KiB is a far compromise if Clap provided, for example, better performance or better code readability and organization. The benchmarks you provided shows the performance is practically the same which is close to no library usage.

I did do a bit of CLI work (I try to maintain https://github.com/rust-starter/rust-starter) and will always pick up clap. It just happens that even for the simplest CLIs out there, things can get hairy really fast. A good type interface that let me define my args as types and have extras on the fly (ie: Shell completion code) is worth the less than 1MiB overhead.

That 690KB savings is 1/97000th of the RAM on the machine I develop and run most of my Rust software on.

If I ever encounter a single howto or blog post or Stack Overflow answer that tells me how to use Clap to do something 5 minutes more quickly than with an alternative, it’s paid for itself.

Amdahl’s Law says you can’t optimize a system by tweaking a single component and get more than that component’s total usage back. If Clap takes 1% of a program’s resources, optimizing that down to 0 will still use 99% of the original resources.

It’s just not worth it.

> I got a nickel every time I spent 15 minutes replacing a trivial use of clap with pico-args and thus reduced the binary size and compile time of some project by at least 80%, I would have at least three nickels.

Hahaha, awesome. Thanks for the pico-args recommendation.

It supports the bare minimum.

I sure would like deriving-style parsing and --help auto-generation.

I think deriving-style unavoidably causes build time and complexity.

But it could be done without the dependency explosion.

There's a list of options here:

https://github.com/rosetta-rs/argparse-rosetta-rs#rust-arg-p...

Among the ones you recommend, argh supports deriving, auto-generates --help and optimizes for code size. And its syntax is very comparable to clap, so migrating is very easy. gumdrop seems very similar in its feature set (specifying help strings a little differently), but I can't find a defining feature for it.

> Why would you default to the biggest, slowest option?

Because it's not very big, nor very slow. Why wouldn't you default to the most full-featured option when its performance and space usage is adequate for the overwhelming majority of cases?

argh is not meant to be used with Cargo, it doesn't even have the capability to display the version.

Convenience always win. If we want smaller more purposefully built dependencies then we need better tooling that makes those choices convenient.

Clap has also great dev ux, so I wouldn't put maintainability as an expense.

I hope you don't mind me plugging my thing here, but I had the 100% same problem and made aargvark (https://docs.rs/aargvark/latest/aargvark/). When I was using clap, every time I'd need to look up how to do X, or what combination of things I needed to put an enum here, or find out that this nesting of data types wasn't supported, etc.

It's still derive macro-based, but there's only one derive (`Aargvark`) rather than `Parser`, `Subcommand`, etc, and it can handle any data structure composition orthogonally (although crazy structures may result in fairly awkward command lines).

FYI, maybe for you and other readers. My key to really understanding clap's derive macro was to understand that the macros takes as argument every methods of clap's Command struct https://docs.rs/clap/latest/clap/struct.Command.html

Looking at this resolved most of my issues about discoverability.

I feel like there's a sweet spot for complexity that the derive macro hits pretty well. When things get more complex it can feel like a maze, but below that complexity it's pretty nice.

The argument / environment variable duality is a challenging one, especially when developing server software that should take security into account where you don't want to encourage users to put secrets into scripts. Do you end up with some items that can only be entered via one mechanism or another? Maybe that's where the fun of being a developer comes in is making those choices.

… I don't want every program to attempt to implement argument parsing; bespoke implementations will be lower quality than clap. Not reinventing an argument parser is an extremely reasonably dependency to take.

Clap, on the non-derive side, has approximately two dependencies: anstream/anstyle (for terminal coloring, another thing that sounds deceptively simple at first pass, if you think all the world is a VT100, but really isn't; this is a reasonable dep. for a CLI arg parser) and strsim (string similarity, again, a reasonable dep for a CLI arg parser…). And that's it¹ for clap's direct deps.

(¹I'm omitting clap_lex, as an "internal" dep.)

On the derive side, there's the usual proc-macro2/quote/syn trio, but those come up frequently in derive crates due to what they do, and other than that, there's just `heck`, which is again an obvious dependency in context.

… what is so quizzical to me about the "so many dependencies!" complaint is that when we do get examples like this, they're almost always on crates that bottle up genuinely tricky functionality (like what we see here) — exactly the sort of thing that a.) is hard to get right and b.) isn't relevant to the problem I want to solve. That's like "absolutely this is a dependency" central, to me…

Completely agree. I find it crazy that this is encouraged in the very first example in the official tutorial [1].

[1] https://doc.rust-lang.org/book/ch02-00-guessing-game-tutoria...

If all the code was crammed into the std library it'd be fine?

Functions need to build on top of simpler functions to be able to abstract problems and tackle them one at a time. There's innate complexity around and without trying to tame it into smaller functions/packages it seems you'll end up in a worse spot.

If you got a progress bar, website, and dependency tree for every

#include <argp.h>, <stdio.h>, <sstream>, or <curl.h>

it'd feel pretty crazy too. Imagine if `make` went out and pulled latest upstream changes for `pthreads` every time any one of your dependencies used it. C++ imagine it's pulling and building boost, or abseil.

C#? The entire mono/.net toolchain and system/ FFI libraries.

Imagine if we had "dot-h.io" that tracked how many separate C projects used argp. Laughable! Millions!

Every language has gobs of dependencies. So many dependencies it'd make you sick. Thousands upon thousands of lines of code, just to make something that runs on one target and says "Hello world" to the screen. Hell, some languages require you to run a runtime on your operating system that runs on real hardware _just to launch those thousands of lines of code_. And those are written using curl.h, pthreads.h, etc etc (or similar). Bananas!

At least those with package managers allow you to see it, audit it, update it seamlessly.

If it's too big, use "nostd"

NIHS?

Thanks for the feedback. Nested commands are definitely full of boilerplate and your crate looks interesting.

  No help generation
  Only flags, options, free arguments and subcommands are supported
  A properer parser would knew that --arg2 is a key and will return an error, since the value is missing.
  If such behavior is unacceptable to your application, then you have to use a more high-level arguments parsing library.

So 700 LOC gets us a mediocre argument parser with no features. What do you get for an additional 9300 LOC? A "properer" parser (dev and user experience+). Help generation (dev experience+). Multiple interfaces (dev experience+). Color terminal output (user experience+). Suggested completions (user experience+).

Is it worth it? I dunno that's a per-project choice. If you absolutely need the smallest footprint and compile times possible, probably you don't want to go with clap. You also probably don't want to go with Rust.

Honestly, if you're doing something so small, even pico-args is a lot more than you need. Just use lexopt, and you get a very simple match-based DSL for defining your arguments, that even neatly sidesteps the limitations provided in pico.