Re: [boost] [program_options] Proposal: self-contained, header-only port of Boost Program Options library

On Tue, Sep 17, 2019 at 12:02 AM Vicram Rajagopalan via Boost < boost@lists.boost.org> wrote:

On Thu, Sep 12, 2019 at 11:01 AM Zach Laine via Boost wrote:

...

I agree with a lot of the points raised above about the problematic nature of Boost.ProgramOptions. I also think Lyra looks interesting.

Regarding Lyra, I took a look at the Github repo a few weeks ago, but as far as I could tell, it hasn't gained much traction. That was just my impression from the low number of stars, watches, issues, and pull requests. Are there any particular reasons that y'all recommend Lyra in particular?

I only just heard about it in this thread.

Granted, development/maintenance does seem to be active, which is a good sign in my book.

...

If you're interesting in solving problems in this space, rather than doing a straight port, here are some things I would find very helpful, not all of which Lyra provides:

I suppose what I'd really like to see is a de-facto standard; right now, it doesn't seem that one exists. Given that Boost.ProgramOptions is not a particularly good example to follow, the best use of my time may be to contribute to a healthy project. cxxopts is one that caught my eye, as it seems more well-known than most other similar projects. Does anyone have any impressions of cxxopts (or others)?

IMO, what made libfmt (which became C++20's std::format) a success is that it took an existing and popular API for string formatting (from Python) and implemented it efficiently. If you were to do the same thing with Python's argparse, I think the result would be similar. I say this because all the libraries above, and probably others besides, are each taking a particular point of view, API-wise, that has not necessarily caught on. Perhaps one of them will, I don't know. I *do* know that the argparse API has been stable for years, and covers every scenario for handling command line arguments that I have seen. Zach