so i updated this to work with nested arguments which is what i really
wanted to use it for in the first place. i almost always end up
creating a map of config settings and this makes it easy for me to
override things from the CL.
regarding the getopt stuff, i kind of agree but dont particularly like
getopt and parsing the raw args into pairs seemed pretty easy so i
wasnt so bothered about reinventing that wheel...
Example:
(clargon args
(required ["-p" "--port"] #(Integer. %))
(optional ["--host" :default "localhost"])
(optional ["--verbose" :default true])
(optional ["--log-directory" :default "/some/path"])
(group "--server"
(optional ["-n" "--name"])
(optional ["-p" "--port"] #(Integer. %))
(group "--paths"
(optional ["--inbound" :default "/tmp/inbound"])
(optional ["--outbound" :default "/tmp/outbound"]))))
with args of:
'("-p" "8080"
"--no-verbose"
"--log-directory" "/tmp"
"--server--name" "localhost"
"--server--port" "9090"
"--server--paths--inbound" "/dev/null")
will produce a clojure map with the names picked out for you as keywords:
{:port 8080
:host "localhost"
:verbose false
:log-directory "/tmp"
:server {:name "localhost"
:port 9090
:paths {:inbound "/dev/null"
:outbound "/tmp/outbound"}}}
On Sat, Dec 11, 2010 at 12:20 PM, Alan <a...@malloys.org> wrote:
> I confess I didn't notice the type-conversion stuff in clargon; my
> view is now basically the same as Miekel's: it's great to have these
> new features, but they should be on top of getopt, which parses
> excellently. In fact, I think I'll fork clargon and see if I can tweak
> it that way.
>
> On Dec 11, 1:32 am, Meikel Brandmeyer <m...@kotka.de> wrote:
>> Hi,
>>
>> Am 11.12.2010 um 09:53 schrieb Saul Hazledine:
>>
>> > I saw this and thought the opposite! I think it is a good thing that
>> > somebody has done a higher level argument parsing library.
>>
>> > As far as I know, getopt doesn't support type conversion, help text or
>> > field validation. Generally, higher level languages have better
>> > argument parsing libraries than the getopt style, Python for instance:
>> >http://docs.python.org/library/optparse.html
>>
>> This is completely orthogonal. Adding type conversion, help text or field
>> validation does not require the underlying parser to be re-implemented. One
>> can use getopt, commons-cli, with-command-line or jopt-simple and add things
>> on top for real added value.
>>
>> That said: I have no opinion about the posted code, because I haven't looked
>> at it, yet. Generally, I would prefer the above approach: use something
>> existing and add functionality on top. But then, I'm also guilty of
>> implementing a cli parser in Clojure myself.
>>
>> Sincerely
>> Meikel
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
