[Pitch][stdlib] Command Line Option Parsing & Help


(Russ Bishop) #1

I want to pitch a command line parsing addition to the standard library and get feedback before I polish up a full proposal.

Swift is being positioned to fill numerous functions, including as a local scripting language. I think that’s great but having tried to use it for that purpose there are a number of holes that need to be filled. Parsing command arguments (and printing help / doing shell autocompletion) is enough of a common task that I think it deserves to be part of the standard library… not to mention the huge PITA that it becomes to attempt to use a third-party library from a shell script.

I’m especially interested in Dimitri or Robert’s opinions on whether this kind of thing meets the standard library bar.

I’m looking toward some protocols that describe commands and their options, including short and long form (-/--), --opt=value, etc. Type-safe using enums that can convert from raw values, automatic printing of error & usage info when invalid options are passed. I’d also like to support loading localized descriptions for the help text from a bundle for i8n support (subject to what support exists in Swift’s Foundation).

If we can fill some of these holes it would make using swift scripts and command line utilities a much nicer experience.

Russ

Eventually I’d like to build up several components:

* Arguments - parse command line args, print command help, support shell auto-complete
* Terminal - Psuedo-terminal support, line discipline control, ANSI colors & other escape codes/commands, progress bars and other nice things for output
* TerminalEditor - a swift interface to ncurses, term box, or some similar cross-platform lib for doing command-line editing


(Will Field-Thompson) #2

I think it would be great to have something like this (at least the
"Arguments" component) as part of the standard distribution — maybe as a
corelib rather than as part of the standard library. Seeing as this is
certainly not in scope for phase 1 of Swift 4, maybe it would be better to
start this as an external library with the aim of having it brought into
corelibs at some point in the future?

Also probably worth taking a look at existing libraries like <
https://github.com/jatoben/CommandLine>, <
https://github.com/nomothetis/OptionKit>, and <
https://github.com/marcoconti83/targone> to see what other people have
tried.

Will

···

On Wed, Aug 17, 2016 at 4:20 AM Russ Bishop via swift-evolution < swift-evolution@swift.org> wrote:

I want to pitch a command line parsing addition to the standard library
and get feedback before I polish up a full proposal.

Swift is being positioned to fill numerous functions, including as a local
scripting language. I think that’s great but having tried to use it for
that purpose there are a number of holes that need to be filled. Parsing
command arguments (and printing help / doing shell autocompletion) is
enough of a common task that I think it deserves to be part of the standard
library… not to mention the huge PITA that it becomes to attempt to use a
third-party library from a shell script.

I’m especially interested in Dimitri or Robert’s opinions on whether this
kind of thing meets the standard library bar.

I’m looking toward some protocols that describe commands and their
options, including short and long form (-/--), --opt=value, etc. Type-safe
using enums that can convert from raw values, automatic printing of error &
usage info when invalid options are passed. I’d also like to support
loading localized descriptions for the help text from a bundle for i8n
support (subject to what support exists in Swift’s Foundation).

If we can fill some of these holes it would make using swift scripts and
command line utilities a much nicer experience.

Russ

Eventually I’d like to build up several components:

* Arguments - parse command line args, print command help, support shell
auto-complete
* Terminal - Psuedo-terminal support, line discipline control, ANSI colors
& other escape codes/commands, progress bars and other nice things for
output
* TerminalEditor - a swift interface to ncurses, term box, or some similar
cross-platform lib for doing command-line editing

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Félix Cloutier) #3

If we introduce a new API to parse command-line arguments now, we're committing to support it for a very long time. It seems to me that this is the kind of thing that could evolve with the language, so I'm not really in favor of fixing an implementation now.

Imagine this hypothetical scenario:

Swift 3 adds a program argument parser in the standard library;
Swift 4 implements an awesome feature that makes it possible to make a much better program argument parser;
Someone else implements that better argument parser that 99.9% of the Swift community prefers over the standard one;
We're stuck supporting the old and ugly parser as the standard library is part of the ABI, even though almost nobody uses it anymore.

To me, because of the not particularly low risk of deprecation, this should be left to third-party packages for now.

Félix

···

Le 17 août 2016 à 01:20:05, Russ Bishop via swift-evolution <swift-evolution@swift.org> a écrit :

I want to pitch a command line parsing addition to the standard library and get feedback before I polish up a full proposal.

Swift is being positioned to fill numerous functions, including as a local scripting language. I think that’s great but having tried to use it for that purpose there are a number of holes that need to be filled. Parsing command arguments (and printing help / doing shell autocompletion) is enough of a common task that I think it deserves to be part of the standard library… not to mention the huge PITA that it becomes to attempt to use a third-party library from a shell script.

I’m especially interested in Dimitri or Robert’s opinions on whether this kind of thing meets the standard library bar.

I’m looking toward some protocols that describe commands and their options, including short and long form (-/--), --opt=value, etc. Type-safe using enums that can convert from raw values, automatic printing of error & usage info when invalid options are passed. I’d also like to support loading localized descriptions for the help text from a bundle for i8n support (subject to what support exists in Swift’s Foundation).

If we can fill some of these holes it would make using swift scripts and command line utilities a much nicer experience.

Russ

Eventually I’d like to build up several components:

* Arguments - parse command line args, print command help, support shell auto-complete
* Terminal - Psuedo-terminal support, line discipline control, ANSI colors & other escape codes/commands, progress bars and other nice things for output
* TerminalEditor - a swift interface to ncurses, term box, or some similar cross-platform lib for doing command-line editing

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #4

I agree. I’d love to see this happen some day (and this is part of the rationale for moving Process.arguments to CommandLine.arguments), but it is out of scope for Swift4s1, and we don’t have a process for large scale new library functionality like this (yet).

When/if we do, I suspect it will highly prize libraries that already have a proven track record of wide use in the Swift community. As such, I’d recommend building this functionality as a SwiftPM package in the meantime, or extending one of the ones that already exist.

-Chris

···

On Aug 17, 2016, at 9:41 AM, Will Field-Thompson via swift-evolution <swift-evolution@swift.org> wrote:

I think it would be great to have something like this (at least the "Arguments" component) as part of the standard distribution — maybe as a corelib rather than as part of the standard library. Seeing as this is certainly not in scope for phase 1 of Swift 4, maybe it would be better to start this as an external library with the aim of having it brought into corelibs at some point in the future?