I think we need a tracker entry for this until it finds its own home.

I want to see somebody design a proper library for dealing with command line
arguments in which consist of a command such as "whatsnew" or "record" (and
subcommands, "show repo") and arguments for that command/subcommand.

Features we would need/want
 * commands (darcs whatsnew) and subcommands (darcs show repository)
 * disambiguation (darcs wh)
 * hidden commands (darcs transfer mode)
 * basic vs advanced commands
 * default arguments
 * etc (note that we probably can't realistically rely on the library to do
everything, but the more we can reasonably outsource the better)

For now we can use this as a place-holder for all the features we'd like to see
in this.  Once somebody decides to take more action and give this idea its own
home, we can close this ticket as a duplicate or re-purpose it for adopting that
library.

Hi Neil, I've taken the liberty of adding you to this darcs bug because of your
recent CmdArgs announcement.  CmdArgs sounds like exactly the thing we've been
looking for: http://community.haskell.org/~ndm/cmdargs/

So if anybody wants to implement this, I suggest investigating CmdArgs and
working with Neil so see what Darcs wishlist items we can implement for it.

One more piece of code we can shake off!

> Hi Neil, I've taken the liberty of adding you to this darcs bug because  
> of your
> recent CmdArgs announcement. CmdArgs sounds like exactly the thing we've  
> been
> looking for: http://community.haskell.org/~ndm/cmdargs/

Agreed, thanks for adding me.

The status of each item on the checklist is:
* commands work fine, subcommands aren't supported, but are pretty easy to  
add
* disambiguation works fine
* hidden commands aren't supported, but are really easy to add
* basic vs advanced commands - not sure what you mean here?
* default arguments work fine
* etc, it has a pretty good selection of etc :-)

If someone from the darcs side wants to work with me on this, that would be  
great. I think it would be great to use CmdArgs in darcs, and am happy to  
improve the library as necessary.

Thanks, Neil

Attachments

• unnamed

On Mon, Sep 14, 2009 at 15:23:46 +0000, ndmitchell@gmail.com wrote:
> * basic vs advanced commands - not sure what you mean here?

Huh, I think I meant basic vs advanced *options*.  In a recent darcs, if
you do darcs help, you get separate help for the key options and for the
extra ones for power users.  To support this, our commands have separate
lists of options, both basic and advanced.

I think the easiest thing is for me to tackle the improvements to the
command line argument library, and a structure for darcs options, then
for some darcs person to pick up my work after and merge it with the
rest of darcs. It will take a fair while for me to improve cmdargs
(since I'm on honeymoon for 3 weeks soon), so I'll let everyone know
when it's ready.

I did have a few questions though:

1) For boolean options, like summary/no-summary in whatsnew, how does
darcs choose a default value? In the flag help it doesn't say what the
default one is. If neither is specified does it pick the value out of
a preferences set? Does it have some other behaviour? This seems to be
a common pattern.

2) Why would anyone specify "--dont-look-for-adds" given it's the
default? Is this just a no-op there for symmetry? Or so you can
specify --look-for-adds --no-look-for-adds and restore the default
behaviour.

3) For many things such as repodir/umask it seems you are only
expecting one value. If the user specifies multiple values what
happens? Is it an error, or do you only keep the last value.

Other than these issues, the encoding of darcs into cmdargs seems to
be fairly simple.

Forwarding this message from Neil for tracking purposes:

--------------------- Neil said ----------------------------------
I've started writing cmdargs for darcs, using the features that I
intend to add to cmdargs v0.2 - i.e. it won't work, but I expect it
will work pretty much as written. My version is at:
http://community.haskell.org/~ndm/darcs/cmdargs/Darcs.hs

I think it's pretty compact, and looks quite nice. It handles all the
features you need, and is fairly declarative. If anyone wants to take
a quite look and let me know how it looks to darcs programmers that
would be great. Otherwise, in about a months time, I'll implement the
features in cmdargs and pass over a fully-formed darcs command line
processor.

Now that I'm Unicodizing metadata handling, I stumble upon the handling of 
command line arguments. On POSIX systems, filenames are just bytes, but patch 
names etc. are text. We need to be able to pass both via the command line.

It seems the most elegant to me to code this into the command line handling 
library. For a given option, you'd specify whether it takes a binary or a text 
argument. In the first case, the library gives you byte values (like getArgs 
returns), in the other case it returns teh byte values interpreted to text 
using the locale.

Bye,
Reinier

Another desired feature:

- ability to distinguish between layers of user defaults and overrides (eg.
command line flags trump _darcs/prefs/defaults which in turn trump
$HOME/.darcs/defaults)

This may not be entirely relevant, but we'd have to study the code to make sure
that we still preserve this property

There appears to be a consensus that in the case of mutually exclusive flags (eg
--quiet --verbose), we should accept all flags [because of shell aliases, etc]
and treat the last one as having effect.

* http://lists.osuosl.org/pipermail/darcs-users/2009-October/021768.html

Hi

I've been on honeymoon for the last 3 weeks, so apologies for getting
to this conversation a bit late!

Reinier: Regarding binary vs text issues, it's a good idea that the
command line argument library should handle this. I'm guessing the
difference should be specified in the types? i.e. have String for
things you want converting, and a newtype over String/ByteString for
things that are just lists of bytes.

Eric: The use of Set is basically just records but without the default
management. Since the default management is probably quite handy to
isolate, I still think records are the way to go. GenI seems a
particularly complex command line method, so I think I'll avoid making
cmdargs powerful enough to handle it for now :-)

I will make a point of talking to Duncan about command line arguments
whenever I next bump in to him - I'm sure Cabal has some interesting
ideas that are very worth stealing.

Regarding the performance implications, I'd be shocked if the command
line argument processing ever shows up in a profile. With using a
record to look up values the use of command line arguments throughout
the program should be as small as it can possibly be - although I
doubt it would be that large anyway.

Uniformly using the last flag as the one that takes effect is trivial
to do systematically, and I'll make it the default for cmdargs. I
agree that shell aliases probably make this the only sensible choice.

Thanks, Neil

2009/10/6 Eric Kow <bugs@darcs.net>:
>
> Eric Kow <kowey@darcs.net> added the comment:
>
> There appears to be a consensus that in the case of mutually exclusive flags (eg
> --quiet --verbose), we should accept all flags [because of shell aliases, etc]
> and treat the last one as having effect.
>
> * http://lists.osuosl.org/pipermail/darcs-users/2009-October/021768.html
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue1550>
> __________________________________
>