www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - argparse version 1.0.0

reply Andrey Zherikov <andrey.zherikov gmail.com> writes:
Hi everyone,

I'm glad to announce first major version of 
[argparse](https://code.dlang.org/packages/argparse) - a library 
for creating command line interface. It took some time to figure 
out public API of this library and I believe it's mature enough 
for the major version.

If you don't know what argparse does, here is not complete list 
of features (see full list in 
[readme](https://github.com/andrey-zherikov/argparse#readme)):
- Positional arguments, short and long options
- Argument groups
- Subcommands
- Help text generation
- Shell completion
Jun 09
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 9 June 2022 at 19:08:16 UTC, Andrey Zherikov wrote:
 Hi everyone,

 I'm glad to announce first major version of 
 [argparse](https://code.dlang.org/packages/argparse) - a 
 library for creating command line interface. It took some time 
 to figure out public API of this library and I believe it's 
 mature enough for the major version.
Congratulations on the release. Though there's a good number of libraries for this task in D already, this solution looks very complete. I was wondering if you ran into any strong reasons for describing the arguments as a struct, rather than, well, function arguments. I have had good success so far with the latter, which has the benefit of being succinct: https://github.com/CyberShadow/btdu/blob/116d190079ca77d61383eb738defa4318d5a1e5f/source/btdu/main.d#L59
Jun 10
parent reply Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Friday, 10 June 2022 at 09:20:24 UTC, Vladimir Panteleev wrote:
 Congratulations on the release. Though there's a good number of 
 libraries for this task in D already, this solution looks very 
 complete.
I looked at them when I started this project and they didn't provide complete set of features I was looking for. That was the main reason to start this work.
 I was wondering if you ran into any strong reasons for 
 describing the arguments as a struct, rather than, well, 
 function arguments. I have had good success so far with the 
 latter, which has the benefit of being succinct:

 https://github.com/CyberShadow/btdu/blob/116d190079ca77d61383eb738defa4318d5a1e5f/source/btdu/main.d#L59
This is an interesting approach. I think they are equivalent for simple cases but how would you model subcommands with common arguments for all of them?
Jun 10
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Friday, 10 June 2022 at 14:14:27 UTC, Andrey Zherikov wrote:
 On Friday, 10 June 2022 at 09:20:24 UTC, Vladimir Panteleev 
 wrote:
 Congratulations on the release. Though there's a good number 
 of libraries for this task in D already, this solution looks 
 very complete.
I looked at them when I started this project and they didn't provide complete set of features I was looking for. That was the main reason to start this work.
I invoke https://xkcd.com/927/ ! :)
 I was wondering if you ran into any strong reasons for 
 describing the arguments as a struct, rather than, well, 
 function arguments. I have had good success so far with the 
 latter, which has the benefit of being succinct:

 https://github.com/CyberShadow/btdu/blob/116d190079ca77d61383eb738defa4318d5a1e5f/source/btdu/main.d#L59
This is an interesting approach. I think they are equivalent for simple cases but how would you model subcommands with common arguments for all of them?
Glad you asked! I use an approach similar to the one here, with commands in a struct. The common arguments are parsed before invoking the command. https://github.com/CyberShadow/steamkeyactivator/blob/144d322ecee65f4f536e5fd4141837e51d61a27a/activator.d#L142 When only some commands need to share some arguments, you can put them in a tuple. https://github.com/CyberShadow/Digger/blob/7c7dd167aea2214d594bab932ea4e41e5f0a357a/digger.d#L34
Jun 10
parent reply Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Friday, 10 June 2022 at 14:20:15 UTC, Vladimir Panteleev wrote:
 I invoke https://xkcd.com/927/ ! :)
:-D I tried to improve one of the existing libs but it didn't go well enough.
 Glad you asked! I use an approach similar to the one here, with 
 commands in a struct. The common arguments are parsed before 
 invoking the command.

 https://github.com/CyberShadow/steamkeyactivator/blob/144d322ecee65f4f536e5fd4141837e51d61a27a/activator.d#L142

 When only some commands need to share some arguments, you can 
 put them in a tuple.

 https://github.com/CyberShadow/Digger/blob/7c7dd167aea2214d594bab932ea4e41e5f0a357a/digger.d#L34
Now you have both approaches: parsing into struct with members and parsing into function arguments. Why do we need two if one is enough?
Jun 10
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Friday, 10 June 2022 at 15:57:40 UTC, Andrey Zherikov wrote:
 On Friday, 10 June 2022 at 14:20:15 UTC, Vladimir Panteleev 
 wrote:
 I invoke https://xkcd.com/927/ ! :)
:-D I tried to improve one of the existing libs but it didn't go well enough.
Assuming you're talking about your time with JCLI then yeah, sorry. If it's any consolation, there's yet another person trying to use the library that I'm currently disapointing ;^)
Jun 11
parent reply Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Saturday, 11 June 2022 at 08:04:14 UTC, SealabJaster wrote:
 If it's any consolation, there's yet another person trying to 
 use the library that I'm currently disapointing ;^)
Are you disappointed with jcli? Why? It's pretty good.
Jun 11
parent Jordan Wilson <wilsonjord gmail.com> writes:
On Saturday, 11 June 2022 at 14:28:02 UTC, Andrey Zherikov wrote:
 On Saturday, 11 June 2022 at 08:04:14 UTC, SealabJaster wrote:
 If it's any consolation, there's yet another person trying to 
 use the library that I'm currently disapointing ;^)
Are you disappointed with jcli? Why? It's pretty good.
I believe SealabJaster was using a bit of self-deprecating humor; I don't believe he himself is disappointed in his library (well, no more than the usual amount of regret and loathing any sensible library writer has in their work...) Jordan
Jun 11