Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust CLI with Clap

tucson-josh.com

Post reply on HN
Print view View original

21–30 of 92 posts

Re: Rust CLI with Clap

#21

Post by rendaw »

msgodel wrote: post #17
rendaw wrote: post #16

Earlier quoted context omitted.

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.

It's useful if your terminal emulator isn't very good and the scrollback buffer doesn't work. This can happen for any number of reasons. Or maybe I don't feel like using the mouse, or I want to do something like grep it. There are an unlimited number of reasons I might want that, that's how interfaces like these work.

Are you saying your terminal emulator can't match on text with ansi color modifiers when searching?

Re: Rust CLI with Clap

#22

Post by pksunkara »

msgodel wrote: post #10
deathanatos wrote: post #9

Earlier quoted context omitted.

… 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…

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…

Actually,

1. `color` feature and thus the `anstream` dep is optional.

2. Even if you use it, it handles all the behaviour correctly regarding the piping and no color support, which is why it is a dependency in the first place.

Source: I am clap maintainer

Re: Rust CLI with Clap

#23

Post by msgodel »

hamandcheese wrote: post #20
dietr1ch wrote: post #14

Earlier quoted context omitted.

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.

Not OP, but more code in stdlib does indeed sound better. I'm not against abstraction and re-use. What I don't like is that for every given thing I want to do, there are multiple crates that offer the same functionality, and it can be really fatiguing trying to vet them. And it is truly a rarity to find a crate that is past the 1.0 version milestone. Compare to golang for example. You can get quite far in go without…

Yeah I was a little surprised to discover the standard library doesn't even include regex. That's kind of extreme. Even most C environments have that.

Re: Rust CLI with Clap

#24

Post by msgodel »

rendaw wrote: post #21
msgodel wrote: post #17

Earlier quoted context omitted.

It's useful if your terminal emulator isn't very good and the scrollback buffer doesn't work. This can happen for any number of reasons. Or maybe I don't feel like using the mouse, or I want to do something like grep it. There are an unlimited number of reasons I might want that, that's how interfaces like these work.

Are you saying your terminal emulator can't match on text with ansi color modifiers when searching?

Are you going to demand it when you write your program? That seems like a regression from most CLIs with bespoke option parsers I've used.

Re: Rust CLI with Clap

#25

Post by mootoday »

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.

It also includes a crate I developed to reduce the boilerplate code for nested commands: https://crates.io/crates/clap-nested-commands

Re: Rust CLI with Clap

#26

Post by tucson-josh »

mootoday wrote: post #25

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 . It also includes a crate I developed to reduce the boilerplate code for nested commands: https://crates.io/crates/clap-nested-commands

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

Re: Rust CLI with Clap

#27

Post by sebtron »

msgodel wrote: post #7

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.

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...

Re: Rust CLI with Clap

#28

Post by tucson-josh »

hamandcheese wrote: post #15

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. (…

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.

Re: Rust CLI with Clap

#29

Post by tucson-josh »

woodruffw wrote: post #3

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 us…

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.
Post reply on HN