[Discussion] About the CLI interface

[Telokis]

After taking a look at SW, I noticed that you use single-dash for options. (-compiler)
I also noticed it works if I double the dash (--compiler) which I always do since I'm used to it.

I guess you based this on the Windows way of handling options? I'm used to

• Double dash for long/full options names (--compiler, --configuration)
• Single dash for single char options (-c, -d)
• Single dash can combine multiple single char options (-cr equivalent to -c -r)

Regarding this point, I just wanted to make sure the behavior you are using is a Windows convention or if you designed it yourself. (I think it may be more common for developers to use the Unix standard I just described, though)

---

Another thing I wanted to mention is regarding the notion of "command" in the CLI.
For me there are three components for a CLI:

• Options (specified with dash(es))
• Commands and possibly subcommands (specified by a specific word like build
• Positional arguments which are like options without a name

Reading your answer for #16, I noticed you made -list-programs behave like a command would.
I think it is a bit strange/counter-intuitive since options are meant to alter the behavior of commands/programs while this one does an action by itself.
I'd argue it is better to promote it to a command: sw list-programs.

The following options seem to have this issue:

• -list-predefined-targets
• -self-upgrade
• -list-programs

It may not be very useful feedback but it made me think for a bit so I thought I could share my thoughts with you.

[egorpugin]

first part

CLI is an issue. I did not find anything suitable for my needs yet. I even tried to investigate it myself. See https://github.com/egorpugin/primitives/tree/master/src/experimental/cl

Current implementation is from clang. It allows -single-dash long options. It may be reconsidered later.

Windows convention

It is /option1 /option2 :) Currently we have a mix of unix/clang cli interface.

---

second part

about your points

Because I did not accept final CLI options implementation or library, there will be such mess like now.

I'd argue it is better to promote it to a command: sw list-programs.

I'm against it. Command list MUST be populated rarely and not for small commands like this. Better to leave it -like-single-option for now.

[Telokis]

I'm against it. Command list MUST be populated rarely and not for small commands like this. Better to leave it -like-single-option for now.

I disagree from an user experience point of view, it seems odd to use an option without a command while others will print No command was issued.
Perhaps there could be a compromise like sw list compilers adding only one list command capable of listing different things depending on its subcommand.

PS: I just noticed that it is list-programs instead of list-compilers which would be clearer since the option is -compiler

[egorpugin]

list-compilers is too specific. I've left 'list-programs' for some space.

[egorpugin]

sw list ... is in use for packages.

[egorpugin]

I disagree from an user experience point of view, it seems odd to use an option without a command while others will print No command was issued.

it's like sw -help. :)

[Telokis]

list-compilers is too specific. I've left 'list-programs' for some space.

It's because the option is then called -compiler. There doesn't seem to be an obvious link between -list-programs and -compiler even though they are closely related.

sw list ... is in use for packages.

My bad but it was just an example.

I disagree from an user experience point of view, it seems odd to use an option without a command while others will print No command was issued.

it's like sw -help. :)

I guess you've got a point, there. (Even though I find this convention a bit strange but who am I to judge?)

[egorpugin]

One more note here. From very end sw user POV it may be more convenient to use future sw-gui application. https://github.com/SoftwareNetwork/sw/tree/master/src/sw/client/gui

[egorpugin]

There's a simple stub there currently. Gui is definitely is not on my plate at the moment.

[egorpugin]

https://github.com/CLIUtils/CLI11

Could be a decent option. Unix-style, no short-long options (like -help). I admit --help is more friendly to me also.

[Telokis]

Seems like a very nice interface!
I think it's a good fit, I'm already thinking about throwing Boost.program_options in favor of this!