Docopt library

[brendanzab]

This would make creating command line interfaces much easier: http://docopt.org/

[z0w0]

I feel like this should be a third party library and not in the std/core library. Considering that all of the implementations are installed using language-based package managers, that seems the norm.

[bstrie]

I agree with z0w0 that such a thing is beyond the scope of libcore (maybe not libstd). However, this sort of thing relies upon compile-time transformations, which requires a syntax extension, which currently must be defined in the compiler. If nothing else this is a plea for an API for externally-defined syntax extensions.

[bblum]

nominating for far-future; it doesn't look like there would be any backward-compatibility issues or anything.

[graydon]

just a bug, removing milestone/nomination.

[emberian]

docopt looks awesome! since loadable syntax extensions are coming, this could probably work out really well.

[emberian]

So I'm marking this E-easy and E-mentor, offering myself as the mentor. I'll post an update once #11151 lands. This isn't trivial, but it shouldn't be too hard, either. It involves parsing the input and generating the correct AST to implement the parsing / structures of the input. We could also add some lightweight typing to docopt.

This is not suitable for a complete beginner.

[emberian]

Loadable syntax have extended (#11151)

[Kimundi]

I'm still kinda toying around with this, but sadly I don't have much time at the moment.
Now that we have loadable syntax extensions, this can however just be a independent library, so maybe this could be closed now?

[bytbox]

Is there room for a more-convenient (but less elaborate) alternative to getopts in extra::? I'm often frustrated by how verbose code that uses getopts can get, and I think something similar to go's "flag" package (but based on getopts for consistency) would be nice.

[joseph-norman]

DocOpt is a fantastic third party library that I've used in Python to great advantage. However like everyone else I believe it should be just that. A third party library. imo it doesn't really belong in libcore.

[dcbishop]

I would love to see this in Rust. Sure it shouldn't be in core but there are other libs included as part of rust, there is 'extern crate getopt' already and I don't really see that being more appropriate.

The main issue is it would probably need a regex library if you follow the Python implementation, otherwise maybe a tokenizer implementation.

[brendanzab]

I think a tokeniser based solution would be more 'rustic'. It would be a difficult port though.

[BurntSushi]

I am working on a docopt port to Rust since the current one seems dead.

@bjz's instincts were right. This project was an order of magnitude more difficult than I thought it would be. The difficulty wasn't related to Rust in any way, but in interpreting the upstream spec (hint: there isn't one).

My project has the hard parts done: parsing usage patterns, matching argv and storing the relevant values. Now I just need to clean up my code, write tests and come up with a nice public interface, probably by using a macro.

Also, my port implements a proper backtracking search, so patterns like cp FILE... DIR already work. (They don't work with the current Python implementation.)

[brendanzab]

The difficulty wasn't related to Rust in any way, but in interpreting the upstream spec (hint: there isn't one).

They seriously have no grammar specification? o_o

[BurntSushi]

@bjz They want one: docopt/docopt#20

There are a lot of weird corner cases that aren't specified though. Are flags allowed more than one synonym? If a flag is repeated in one usage pattern, does that mean its value should always be a count/list even in other patterns where it isn't repeated? Things like that. I had to look at how the reference implementation worked to infer such things.