[thrdbndndn]

I'm sure click has its advantage if your CLI is particularly complex, but for me the built-in argparse is more than enough, it has almost all the common things you need.

By the way, argparse (and I assume click too) by default allows having positional arguments and switches in any order, i.e., both:

    mycli pospara0 --switch --option A
    mycli --switch --option A pospara0 

work. This seems like nothing but I've encountered many CLI utilities written in other languages (particularly, go and node.js) that force you to have switches at the beginning. and I really hate that.

I don't know if it's caused by their corresponding default/popular CLI library or what, someone could enlighten me.

(Of course, in some cases like things like FFMPEG, the order absolutely matters; but it's not the case for 99% of utilities.)

[omgmajk]

Agreed. I, and we (at work) use argparse and it works as intended. I don't know why I would ever switch at this point. Also I feel like arguments should not be ordered unless absolutely necessary, just feels like a head ache to me.

[deniscepko2]

Same here argparse does everything a cli tool would ever need. Looked at click lib and actually don't even find it more readable

[apple4ever]

> This seems like nothing but I've encountered many CLI utilities written in other languages (particularly, go and node.js) that force you to have switches at the beginning. and I really hate that.

Same here. Why I am force to remember or look up which order arguments should go in? There is no reason for that and they should be able to go in any order.

[raffraffraff]

I hate it when a cli forces ordering of args when there's no reason to! It's mitigated somewhat by decent tab-completion that only completed what is allowed.

[atoav]

blender is also one of those where order matters. »Oh, you want me to render after loading the file, then you should have told me«

[crabbone]

> I'm sure click has its advantage if your CLI is particularly complex

None whatsoever. Argsparse is better all around. Click is just a worthless piece of software that nobody should be using.

As for the order of options / arguments. I think, the reason is the historical implementations and use of getopt that would be used in a switch inside a loop, which (maybe unintentionally) made the order irrelevant. It's likely that other libraries implement parsers in the way that is sensitive to the order. Whether that's deliberate it's hard to tell. There are definitely advantages to this approach too, but it's hard to know whether authors sought out those advantages deliberately.

For instance, when options can take arguments (especially when they can take multiple arguments) they can be confused with sub-commands or the arguments to commands. Imposing ordering restrictions helps to resolve ambiguities as to what argument is being processed. On the other hand, you may claim that not imposing ordering on arguments prevents CLI authors from creating confusing interfaces where users can accidentally mix arguments to options with sub-commands or arguments to commands.