8 ms·

Rust CLI with Clap

97 points by rajman187 1y ago

tempodox 1y ago
Clap is the way to go. It makes command line argument parsing a breeze.
gametorch 1y ago
The compile time guarantees + declarative nature make Clap so amazing and foolproof. This is like heaven compared to imperative, arcane incantations like getopt.
woodruffw 1y ago
Nice write up. “Good” CLI semantics are pretty devilish, and overall I think clap does a pretty great job of picking the right (or at least most intuitive) behavior. (One edge case that consistently trips me up, which other argument parsers similarly struggle with: an environment variable fallback has the same “weight” as its option counterpart, so any CLI that makes use of grouping/exclusivity will eventually hit user confusions where the user passes `--exclusive` and gets a failure because of an unrelated environment variable.)
- tucson-josh 1y ago
  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.
ben0x539 1y ago
structopt/Clap's derive magic is one of the first things I miss when I go to write some more-or-less trivial program in a non-Rust language these days. Being able to define all the data for a command line argument in one place (how/where to store it, what the type/valid input is, the association between the name and a variable/field, the documentation for --help...) seems like table stakes but afaict almost every other argument parsing library makes me repeat myself to the point where it takes all the joy out of writing a simple program. (Python's docopt is also amazing, fwiw)
- ameliaquining 1y ago
  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.
- iloveyoudearly 1y ago
  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 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.
  - porridgeraisin 1y ago
    Nice. I had made something similar (but less featureful), funnily enough also for an ML training script usecase. Here it is in a gist: https://gist.github.com/porridgewithraisins/313a26ee3b827f7338df78c72ccbb247 https://gist.github.com/porridgewithraisins/313a26ee3b827f73... I love the ergonomics of this method, and I was going to improve it to support subcommands, etc, but now I think I will use the library you posted.
  - never_inline 1y ago
    People are used to the `click` way, where you can define args as function parameters. It's little more verbose but it helps click is a very established library which also provides many other things needed by CLI tools. There's also `typer` from the creator of `fastapi` which relies on type annotations. I have not had the opportunity to use it.
  - woile 1y ago
    In Python you can use pydantic to create a cli: https://docs.pydantic.dev/latest/concepts/pydantic_settings/#command-line-support https://docs.pydantic.dev/latest/concepts/pydantic_settings/...
- wonger_ 1y ago
ameliaquining 1y ago
Worth noting that you can do this in languages other than Rust. Python, for example, has https://github.com/fastapi/typer https://github.com/fastapi/typer. https://github.com/shadawck/awesome-cli-frameworks https://github.com/shadawck/awesome-cli-frameworks lists relevant libraries in many languages, though not all of them support clap-style structured parsing.
msgodel 1y ago
It really bothers me how much people use crates in Rust. "Minimalist" crates have tens of dependencies. It's like the node.js of systems languages. Touching it feels gross.
- deathanatos 1y ago
  … 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…
  - msgodel 1y ago
    This shouldn't even need terminal coloring, in fact that sounds annoying because it's going to have to behave differently if you pipe it to less (or it's going to do something dumb like the rust compiler itself and just reopen the tty.) This actually reminds me of my other issue with this kind of "oh we just get it for free" attitude that tends to result in overbuilding things that I also dislike in rust. No I think people would be better off with a bespoke option parser actually.
    - rendaw 1y ago
      Why is needing to behave differently when you pipe annoying? Are you saying it doesn't work? But also FWIW I don't think piping command help output is a common use case.
porphyra 1y ago
The macro magic in rust is amazing. It's so nice to just define a struct, slap a `#[derive(Parser)]` on it, and call it a day.
hamandcheese 1y ago
I like clap a lot, however I find that clap derive is not very easily discoverable. I always have to google for the right macro incantation to get what I want. Whereas editor completions from rust analyzer get me quite far without needing to leave my editor when I'm just using an ordinary library. I think this is more a criticism of rust-analyzer than clap itself, any macro-heavy library I have similar issues with. (Yes I know clap can be used without derive, but I'm willing to deal with the pain to parse directly into a struct)
- rendaw 1y ago
  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/ 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).
- tucson-josh 1y ago
  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.
- jrimbault 1y ago
  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 https://docs.rs/clap/latest/clap/struct.Command.html Looking at this resolved most of my issues about discoverability.
vikrantrathore 1y ago
I have used clap to build perspt (https://github.com/eonseed/perspt https://github.com/eonseed/perspt). The project has extensive documentation on how it was built, as we did it as a learning exercise.
mootoday 1y ago
That was a great intro to clap, thanks for writing it up! I've been building clap CLIs for a while and started to put together a template: https://github.com/mootoday/cli-template https://github.com/mootoday/cli-template. It also includes a crate I developed to reduce the boilerplate code for nested commands: https://crates.io/crates/clap-nested-commands https://crates.io/crates/clap-nested-commands
- tucson-josh 1y ago
  Thanks for the feedback. Nested commands are definitely full of boilerplate and your crate looks interesting.
FujiApple 1y ago
Something I’ve been working on recently is a command line tool [1] to bring clap declarative command line parsing to shell scripts. Unfinished WIP but largely functional. [1] https://github.com/fujiapple852/claptrap https://github.com/fujiapple852/claptrap
csnover 1y ago
In my opinion, clap is a textbook example of over-engineering for a single metric (UX) at the expense of all other considerations (compilation speed, runtime cost, binary size, auditability, and maintainability). It is an 18kloc command-line parser with an additional 125kloc of dependencies that takes nearly 6 seconds to compile (‘only’ 400ms for an incremental build) and which adds nearly 690KiB to an optimised release binary (‘only’ 430KiB if you strip out most of the sugar that only clap provides). There are many other command-line parsers to choose from that do all the key things that clap does, with half or less the build cost, and most of them with 30x less binary overhead[0]. argh is under 4kloc. gumdrop is under 2kloc. pico-args is under 700loc. What is the value of that extra 10kloc? A 10% better parser? I am not saying there is no room for a library like clap—it is, at least, a triumphant clown car of features that can handle practically any edge-case anyone ever thought of—but if 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. Just to try to pre-empt arguments like “disk space is cheap”, “compiler time is cheaper than human time”, etc.: there are no golden bullets in engineering, only trade-offs. Why would you default to the biggest, slowest option? This is the “every web site must be able to scale like Facebook” type logic. You don’t even have to do more work to use argh or gumdrop. If clap ends up having some magic feature that no other parser has that you absolutely need, you can switch, but I’ve yet to ever encounter such a thing. Its inertia and popularity carry it forward, but it is perhaps the last choice you should pick for a new project—not the first. [0] https://github.com/rosetta-rs/argparse-rosetta-rs https://github.com/rosetta-rs/argparse-rosetta-rs
- pepa65 1y ago
  argh is not meant to be used with Cargo, it doesn't even have the capability to display the version.
- WiSaGaN 1y ago
  I am wondering how much of this can be mitigated by carefully designing feature flags, and make default feature set small.
- ModernMech 1y ago
b0a04gl 1y ago
10kloc for command line parsing. TEN THOUSAND LINES. pico-args does it in 700 lines and probably handles 99% of real world use cases. compile times go to shit binary size bloats and for some edge case you'll never hit.most CLI tools need what three four flags max, maybe a subcommand or two. you don't need the swiss army knife of argument parsing for that. tried replacing clap with pico-args on three different projects last month. 80% reduction in compile time every single time. binary went from 8mb to 2mb on one of them.the "disk space is cheap" argument's acceptable partially but compile time isn't. developer experience isn't. startup time isn't. memory usage isn't
- ModernMech 1y ago
  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. Yeah, no thank you. If we're talking about 700 LOC, I'm just going to write it myself rather than take on a dependency that won't even describe itself as a proper enough parser. This argument parser doesn't even handle the tedium of generating a help message for the user, and doesn't really parse the arguments -- what's the purpose of using it to do the argument parsing then? 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.
- MrJohz 1y ago
  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.
fainpul 1y ago
PowerShell has everything related to argument parsing, helptext generation, tab completion, type coercion, validation etc. built-in with a declarative DSL. Many things work even directly OOTB, without requiring special annotations. It is by far the nicest way to create CLI tools I have ever seen. Every other shell or commandline parsing library I ever tried, feels extremely clunky in comparison. https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_functions_advanced_parameters?view=powershell-7.5 https://learn.microsoft.com/en-us/powershell/module/microsof...
mprovost 1y ago
I chose clap as the argument parsing crate for my book on Rust CLI programming and it's been my biggest regret. Folk sometimes complain that Rust itself is a moving target but I haven't found that to be the case at all. On the other hand, clap has gone through several, incompatible major releases over the past few years. Unfortunately, in order to keep this forward momentum, it also starts deprecating things which means that I had to pin it to a quickly outdated version. If I ever go back and update the earlier chapters I'd pick a simpler, slower-moving library. On the other hand, this situation is a great example of why keeping things like argument parsing out of the Rust standard library is such a good idea. It's much better to let the community gel around some crates which are able to iterate (and innovate) faster than something with strict backwards-compatibility requirements. Looking at the discussion here there's clearly not one way to solve this - there's no way that something as large and complex as clap has evolved into will ever become "standard".
- Fluorescence 1y ago
  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 https://github.com/clap-rs/clap/blob/v4.5.0/CHANGELOG.md
  - mprovost 1y ago
    Yes 4 has been out for a while but I was caught in the time when it went from v2 (2020) to v3 (2021) to v4 (2022). I made the mistake of rewriting all the chapters from using 2 to 3, which was quickly deprecated for 4.
- packetlost 1y ago
  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/ https://docs.rs/lexopt/latest/lexopt/

97 points by rajman187 1y ago

Clap is the way to go. It makes command line argument parsing a breeze.

The compile time guarantees + declarative nature make Clap so amazing and foolproof. This is like heaven compared to imperative, arcane incantations like getopt.

woodruffw 1y ago

Nice write up. “Good” CLI semantics are pretty devilish, and overall I think clap does a pretty great job of picking the right (or at least most intuitive) behavior. (One edge case that consistently trips me up, which other argument parsers similarly struggle with: an environment variable fallback has the same “weight” as its option counterpart, so any CLI that makes use of grouping/exclusivity will eventually hit user confusions where the user passes `--exclusive` and gets a failure because of an unrelated environment variable.)

tucson-josh 1y ago
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.

ben0x539 1y ago

structopt/Clap's derive magic is one of the first things I miss when I go to write some more-or-less trivial program in a non-Rust language these days. Being able to define all the data for a command line argument in one place (how/where to store it, what the type/valid input is, the association between the name and a variable/field, the documentation for --help...) seems like table stakes but afaict almost every other argument parsing library makes me repeat myself to the point where it takes all the joy out of writing a simple program. (Python's docopt is also amazing, fwiw)

ameliaquining 1y ago
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.
iloveyoudearly 1y ago
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 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.
- porridgeraisin 1y ago
  Nice. I had made something similar (but less featureful), funnily enough also for an ML training script usecase. Here it is in a gist: https://gist.github.com/porridgewithraisins/313a26ee3b827f7338df78c72ccbb247 https://gist.github.com/porridgewithraisins/313a26ee3b827f73... I love the ergonomics of this method, and I was going to improve it to support subcommands, etc, but now I think I will use the library you posted.
- never_inline 1y ago
  People are used to the `click` way, where you can define args as function parameters. It's little more verbose but it helps click is a very established library which also provides many other things needed by CLI tools. There's also `typer` from the creator of `fastapi` which relies on type annotations. I have not had the opportunity to use it.
- woile 1y ago
  In Python you can use pydantic to create a cli: https://docs.pydantic.dev/latest/concepts/pydantic_settings/#command-line-support https://docs.pydantic.dev/latest/concepts/pydantic_settings/...
wonger_ 1y ago

ameliaquining 1y ago

Worth noting that you can do this in languages other than Rust. Python, for example, has https://github.com/fastapi/typer https://github.com/fastapi/typer. https://github.com/shadawck/awesome-cli-frameworks https://github.com/shadawck/awesome-cli-frameworks lists relevant libraries in many languages, though not all of them support clap-style structured parsing.

msgodel 1y ago

It really bothers me how much people use crates in Rust. "Minimalist" crates have tens of dependencies. It's like the node.js of systems languages. Touching it feels gross.

deathanatos 1y ago
… 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…
- msgodel 1y ago
  This shouldn't even need terminal coloring, in fact that sounds annoying because it's going to have to behave differently if you pipe it to less (or it's going to do something dumb like the rust compiler itself and just reopen the tty.) This actually reminds me of my other issue with this kind of "oh we just get it for free" attitude that tends to result in overbuilding things that I also dislike in rust. No I think people would be better off with a bespoke option parser actually.
  - rendaw 1y ago
    Why is needing to behave differently when you pipe annoying? Are you saying it doesn't work? But also FWIW I don't think piping command help output is a common use case.

porphyra 1y ago

The macro magic in rust is amazing. It's so nice to just define a struct, slap a `#[derive(Parser)]` on it, and call it a day.

hamandcheese 1y ago

I like clap a lot, however I find that clap derive is not very easily discoverable. I always have to google for the right macro incantation to get what I want. Whereas editor completions from rust analyzer get me quite far without needing to leave my editor when I'm just using an ordinary library. I think this is more a criticism of rust-analyzer than clap itself, any macro-heavy library I have similar issues with. (Yes I know clap can be used without derive, but I'm willing to deal with the pain to parse directly into a struct)

rendaw 1y ago
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/ 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).
tucson-josh 1y ago
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.
jrimbault 1y ago
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 https://docs.rs/clap/latest/clap/struct.Command.html Looking at this resolved most of my issues about discoverability.

vikrantrathore 1y ago

I have used clap to build perspt (https://github.com/eonseed/perspt https://github.com/eonseed/perspt). The project has extensive documentation on how it was built, as we did it as a learning exercise.

mootoday 1y ago

That was a great intro to clap, thanks for writing it up! I've been building clap CLIs for a while and started to put together a template: https://github.com/mootoday/cli-template https://github.com/mootoday/cli-template. It also includes a crate I developed to reduce the boilerplate code for nested commands: https://crates.io/crates/clap-nested-commands https://crates.io/crates/clap-nested-commands

tucson-josh 1y ago
Thanks for the feedback. Nested commands are definitely full of boilerplate and your crate looks interesting.

FujiApple 1y ago

Something I’ve been working on recently is a command line tool [1] to bring clap declarative command line parsing to shell scripts. Unfinished WIP but largely functional. [1] https://github.com/fujiapple852/claptrap https://github.com/fujiapple852/claptrap

csnover 1y ago

In my opinion, clap is a textbook example of over-engineering for a single metric (UX) at the expense of all other considerations (compilation speed, runtime cost, binary size, auditability, and maintainability). It is an 18kloc command-line parser with an additional 125kloc of dependencies that takes nearly 6 seconds to compile (‘only’ 400ms for an incremental build) and which adds nearly 690KiB to an optimised release binary (‘only’ 430KiB if you strip out most of the sugar that only clap provides). There are many other command-line parsers to choose from that do all the key things that clap does, with half or less the build cost, and most of them with 30x less binary overhead[0]. argh is under 4kloc. gumdrop is under 2kloc. pico-args is under 700loc. What is the value of that extra 10kloc? A 10% better parser? I am not saying there is no room for a library like clap—it is, at least, a triumphant clown car of features that can handle practically any edge-case anyone ever thought of—but if 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. Just to try to pre-empt arguments like “disk space is cheap”, “compiler time is cheaper than human time”, etc.: there are no golden bullets in engineering, only trade-offs. Why would you default to the biggest, slowest option? This is the “every web site must be able to scale like Facebook” type logic. You don’t even have to do more work to use argh or gumdrop. If clap ends up having some magic feature that no other parser has that you absolutely need, you can switch, but I’ve yet to ever encounter such a thing. Its inertia and popularity carry it forward, but it is perhaps the last choice you should pick for a new project—not the first. [0] https://github.com/rosetta-rs/argparse-rosetta-rs https://github.com/rosetta-rs/argparse-rosetta-rs

pepa65 1y ago
argh is not meant to be used with Cargo, it doesn't even have the capability to display the version.
WiSaGaN 1y ago
I am wondering how much of this can be mitigated by carefully designing feature flags, and make default feature set small.
ModernMech 1y ago

b0a04gl 1y ago

10kloc for command line parsing. TEN THOUSAND LINES. pico-args does it in 700 lines and probably handles 99% of real world use cases. compile times go to shit binary size bloats and for some edge case you'll never hit.most CLI tools need what three four flags max, maybe a subcommand or two. you don't need the swiss army knife of argument parsing for that. tried replacing clap with pico-args on three different projects last month. 80% reduction in compile time every single time. binary went from 8mb to 2mb on one of them.the "disk space is cheap" argument's acceptable partially but compile time isn't. developer experience isn't. startup time isn't. memory usage isn't

ModernMech 1y ago
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. Yeah, no thank you. If we're talking about 700 LOC, I'm just going to write it myself rather than take on a dependency that won't even describe itself as a proper enough parser. This argument parser doesn't even handle the tedium of generating a help message for the user, and doesn't really parse the arguments -- what's the purpose of using it to do the argument parsing then? 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.
MrJohz 1y ago
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.

fainpul 1y ago

PowerShell has everything related to argument parsing, helptext generation, tab completion, type coercion, validation etc. built-in with a declarative DSL. Many things work even directly OOTB, without requiring special annotations. It is by far the nicest way to create CLI tools I have ever seen. Every other shell or commandline parsing library I ever tried, feels extremely clunky in comparison. https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_functions_advanced_parameters?view=powershell-7.5 https://learn.microsoft.com/en-us/powershell/module/microsof...

mprovost 1y ago

I chose clap as the argument parsing crate for my book on Rust CLI programming and it's been my biggest regret. Folk sometimes complain that Rust itself is a moving target but I haven't found that to be the case at all. On the other hand, clap has gone through several, incompatible major releases over the past few years. Unfortunately, in order to keep this forward momentum, it also starts deprecating things which means that I had to pin it to a quickly outdated version. If I ever go back and update the earlier chapters I'd pick a simpler, slower-moving library. On the other hand, this situation is a great example of why keeping things like argument parsing out of the Rust standard library is such a good idea. It's much better to let the community gel around some crates which are able to iterate (and innovate) faster than something with strict backwards-compatibility requirements. Looking at the discussion here there's clearly not one way to solve this - there's no way that something as large and complex as clap has evolved into will ever become "standard".

Fluorescence 1y ago
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 https://github.com/clap-rs/clap/blob/v4.5.0/CHANGELOG.md
- mprovost 1y ago
  Yes 4 has been out for a while but I was caught in the time when it went from v2 (2020) to v3 (2021) to v4 (2022). I made the mistake of rewriting all the chapters from using 2 to 3, which was quickly deprecated for 4.
packetlost 1y ago
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/ https://docs.rs/lexopt/latest/lexopt/