change --long-opts to use = when given a value?

[bukzor]

Some commands won't parse --long-opt val as a long option with a value.
I'd like to change this to use an = sign.

Of course this could be made configurable, but that makes things more complex.
I don't think the opposite problem happens; I don't believe there's any command that prefers the no-equal-sign syntax.

[bukzor]

For example:

$ git log -1 --stat 999 
fatal: ambiguous argument '999': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

$ git log -1 --stat=999 
commit 6e3a6b25d8b825e262a8b346e4a005fd10734958
Merge: c329460 788a116
Author: Mike Thornton <msthornton@gmail.com>
Date:   Mon Oct 13 13:53:03 2014 -0500

    Merge pull request #8 from bukzor/buck-repr-quotes

    leverage built-in repr to make proper string reprs

[six8]

Agreed it's a better defeat to have =. What about short ops with values? I've been thinking about how to do settings like telling clom which param format to use. Don't want to clutter the kwargs as it might clash with a command's option. Might have to do 'with_settings(opt_val_sep=" ")' or the like.

Maybe clom should have ext support that has preconfigured options for common commands. That could make it too complicated though.

On Jan 29, 2015, at 10:42 AM, Buck Golemon notifications@github.com wrote:

Some commands won't parse --long-opt val as a long option with a value.
I'd like to change this to use an = sign.

Of course this could be made configurable, but that makes things more complex.
I don't think the opposite problem happens; I don't believe there's any command that prefers the no-equal-sign syntax.

—
Reply to this email directly or view it on GitHub.

[bukzor]

Values for short opts varies a bit, but I think what's there now (-x 1) is the common denominator. -x1 can be interpreted as -x 1 or as -x -1, depending on the parser. -x=1 isn't a thing I've ever seen.

If it's needed I think .with_settings is the way to go, but I think we should wait till it proves needed. It might not be.

[six8]

Curl doesn't like the =:

$ curl -iv --max-redirs=0 http://google.com
curl: option --max-redirs=0: is unknown
curl: try 'curl --help' or 'curl --manual' for more information
$ curl -iv --max-redirs 0 http://google.com
* Rebuilt URL to: http://google.com/

So this certainly needs to be optional. It may be the best default though. Need to check out a few common commands and see which is more supported, = or .

[bukzor]

sadness

[bukzor]

Do we add a new .configure method?

[six8]

I guess we go with with_settings as it's less likely to clash with an actual command.

[bukzor]

I've noticed that clom has a problem that mock.Mock also has: if you
mis-remember / typo a method name, it does the Wrong Thing silently, which
is a very stinky smell. It would be best to separate the auto-magical
namespace from the well-known-methods namespace.

Do you have any ideas on that front? I think we'd have to decide which one
wins. If the auto-magic wins, x.clom puts us back to the well-known
methods. If methods win, .args puts us into the auto-magic namespace.

Actually I can make both branches relatively easily, we we can decide which is nicer (or neither) after looking at them.

[six8]

You could also forget the namespace. Ex:

>>> from clom import clom
>>> clom.git.log.with_opts('-l', stat=22)
'git log -l --stat 22'
>>> clom.git.log.with_optx('-l', stat=22)
'git log with_optx --stat 22 -l'

If we said "with_*" is a namespace, we could error. However if you typo'd "with" you'd still end up with it doing the wrong thing.