Clier cli parser / Framework

I have created a cli parser and framework called Clier. I love the arg parsing api i've implemented. But the main focus of this library should be the framework command handling. I'm abit unsure about this api, especially about the flag resolving. Some feedback would be greatly apprechiated and share your opinions of it, since this is the first library i've written in rust!

Github: GitHub - vincent-thomas/clier

It has builtin, version and help commands

To give a feedback on the API it would be great to see some more interesting examples. To give some ideas, how would you write things to parse

Flag -p parsed multiple times, I expect to get a vector back

cargo check -p foo -p bar

I expect to get 15usize back and for parser to deal with cases like -j five by itself

make -j 15

I expect to get some numeric value for verbosity, and -vvv should parse the same as -v -v -v

cargo build -vvv

Variation on a previous one, -v increases verbosity, -q - decreases it, I expect to get 2 back.

foo -vvv -q

Mutually exclusive flags, I expect to get a enum value back and parser to complain when both/neither specified

cargo asm --intel --att

Value validation, I want to be able to specify possible range for values of -n, say from 1 to 100 and give user an error without doing by hand if users passes 101.

foo -n 10

Multi value arguments, I expect to get a tuple ("name", "42") or even ("name", 42) back:

foo --set name 42

Values with more types, I expect to get a Vec<PathBuf> back.

cat /etc/passswd /etc/group

As a side note - using std::env::args means you don't support non utf8 file names which are possible.

And a usual question - what can it do (better) than other existing libraries cannot do?

1 Like

It also seems to be mixing parser and parser code generator at once in the same crate - this means end user will have to pull serde and serde_json no matter what - that's not good, I'd separate this functionality into a separate crate.

It also depends on thiserror which might be useful in some cases, but for basic crates it saves you a bit of typing at expense of adding some heavy dependencies, - I'd drop it and write the instance by hand.

Thank you very much for your time. I do have some questions of your ideas. For example this

What i can do since i use hashmaps, is have every value be a vec, and then if it finds publicates it just pushes the value maybe?

Wouldn't i32 be better for this? Maybe i'm missing something.

This is virtually impossible in rust right, because of the strict type system right?

What i do have in place, i have a use_flag hook, that gets the value of a flag user specifies. I then have implemented many TryInto traits for i32s and Strings, which converts the value to users needs. This is abit clunky though.

I don't specifically like the api for required flags i have now. It works, but I would like approx the same api that clap has for flag validation with structs and macros, without the help messages, since i implement my own system for that. But i've only dibbled very lightly with macro_rules, so i don't think i know how to do that. Could you recommend some resources to learn derive and procedural macros for example?

Again thank you for your time

Do you think putting the cli tool for generating app code into a feature would be a good idea? If so, can i put an entire file under a feature?

What would you recomment to use otherwise?

This would be one way.

i32 allows for negative values, number of jobs shouldn't be negative so usize fits better. On the other hand for some problems it needs to be negative. As long as user gets to decide what type to get...

It is totally doable and I've seen this used in practice. If ("name", 42) is (String, usize) - strictly typed. It's just the parser needs to be able to return it.

std::env::args_os, but it gives you OsString back - dealing with that can be pain...

A good reference on macro_rules The Little Book of Rust Macros

Dunno, I'd go with a separate crate.

I'm not sure if they exists. In my case I went over a whole bunch of articles and through sources of a bunch of libraries.

Thank you very much for your responses. Thank you, already working on changes!

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.