On Wed 22 Jan 2014 at 02:21:51PM +0100, Alf Kristian Støyle wrote: > Would be nice to be able to specify that an option "must be specified > in every invocation" though. I think it would lead to better error > messages, e.g. if several "mandatory" options are forgotten, they will > be shown at once. That is a bit of a hassle when doing it yourself. > > Haven't looked too hard at the source though, but any chance of > contributing a patch to something like that? > > E.g. > [["-p" "--port PORT" "Port number" > :mandatory true]]
I think the nicest thing about the original design of tools.cli is that
it is conceptually a transformation of a default map of values into
another map of values. Kind of like:
(reduce option-rules default-map ARGV) ; => new-map
From this POV, it makes more sense to me to assert the shape and value
of `new-map` than to validate the membership of `ARGV`. I hope this
makes sense.
That said, there is definitely plenty of room for a more convenient
framework on top of tools.cli. The recent reboot of the library was
primarily aimed at increasing the flexibility of the argument tokenizer
(e.g. supporting GNU option conventions) and that of summary generation.
I purposefully made no attempts at adding anything fancier than that
since the API change was already jarring.
Also, in my experience with CLI libraries in other languages,
programmers simply cannot agree on a single way to structure command
line programs. Therefore, it my hope that `parse-opts` can at least
serve as a common base between such libraries and for Clojurists
interested in rolling their own.¹
If a clear favorite does emerge in the future, then that will be a great
candidate for inclusion in tools.cli before an eventual 1.0 release.
Cheers,
guns
¹ What is unfortunate is that many libraries ship with their own
ad-hoc parsers that use regular expressions or simple word matching.
`parse-opts` tokenizes input before parsing so things like clumped
options (`-abc`) are properly handled.
pgp3eImZv75sZ.pgp
Description: PGP signature
