[darcs-users] [issue1550] general purpose command line parsing library (CmdArgs)

Eric Kow kowey at darcs.net
Wed Sep 16 19:33:23 UTC 2009

Hi Neil,

(I'm redirecting this to the users list)

On Wed, Sep 16, 2009 at 14:37:32 +0000, Neil Mitchell wrote:
> 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.

Sounds great :-)

> 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.

I'm afraid we don't have a mechanism for dealing with default values
now.  We get defaults hard-coded into the business logic which makes me
rather unhappy.  Getting this cleaned up is going to take some work, but
it definitely needs doing.

My ideal would be that somehow every choice in Darcs be explicitly
expressed in the core code and that defaults be handled just on a
surface layer.  You flip a switch and the default changes.  No need to
actually muck around with the internals.

How things work right now is that we have a giant sum type DarcsFlag
which contains all the settings.  To figure out how it needs to behave,
the core logic checks for the presence/absence of certain flags.  I
believe that what needs to happen as a first step is for this to be
broken up into smaller more limited types with fewer choices, eg.
Compression | NoCompression

This is discussed a bit in http://bugs.darcs.net/issue1157

Note also that we have a feature request to change our current
--foo, no-foo setup into a --foo={yes,no} one which you may be
interested in.  http://bugs.darcs.net/issue1291
One thing which may make sense to do is to assume that we have gone the
route of breaking up DarcsFlag as proposed.  For example, we already
have a data Compression = NoCompression | GzipCompression which may
simplify things.

> 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.

Because they may want to override a default setting of --look-for-adds
that they put either in their global or repo-specific defaults

> 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.

It's not well defined.  For example, see
 * http://bugs.darcs.net/issue1116
 * http://bugs.darcs.net/issue1158
as examples of where this bites us.

So I hope I'm not being off-putting by giving the impression that work
on our flags is basically going to involve overhauling everything.  It's
actually (for me) a second reason to be excited about CmdArgs.  I have a
feeling that if we attack this the right way, we can get much cleaner
darcs code out of it.  It's not just about outsourcing anymore.


Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20090916/305c7be0/attachment.pgp>

More information about the darcs-users mailing list