Can all options in ~/.green be overridden on the command line?

[hindman]

I've got this in ~/.green:

verbose = 2
pattern = *_tests.py

And I'm not having any luck overriding those settings on the command line.

[CleanCut]

Yes, all options really should be override-able, as long as there is a way to pass it via command-line. See the documentation at the top of green/config.py and the implementation in mergeConfig at green/config.py:316.

I can't reproduce the problem, I can override them just fine.

Are you aware that verbose = 2 corresponds to -v? verbose = 1 is the default and each extra v increments the integer. There's no way (that I can remember) to explicitly specify verbose = 1 via the command-line, so if you set verbose = 2 in the config, you can currently only override it to be even more verbose. I have been meaning to overhaul output options, since there are a lot of things I have been wanting to configure with output that don't lend themselves to an increasing scale of verbosity (see #30).

Also, be aware that since g is a bash helper script that tries to make it so you can run green via any python version, it has problems with bash intercepting patterns. For example, if you do:

./g --pattern 'test*'

what will get run by bash is:

python -m green.cmdline --pattern test_*

which will be interpreted (by bash) to be

python -m green.cmdline --pattern test_versions

since test_versions is a file in the local directory.

Anyway, let me know if you really find a place where we're not overriding stuff. If there is a place, lets fix it.

[CleanCut]

I have marked this as a question. If you can find a reproducible bug, I'll switch it to bug instead.

[hindman]

I did some more experimenting. Here's how things are behaving on my box.

If I delete my ~/.green file, I can run the green test suite in the normal way:

$ green green/test/
...........................sss..........    # etc...
Ran 139 tests in 0.749s
OK (passes=135, skips=4)

But if I create this file:

$ cat ~/.green
pattern = *_tests.py
notermcolor = 1

And then try to run the tests with command-line options that should override those settings, I get the following non-colored output:

$ green green/test/ -p 'test*.py' -t
Ran 0 tests in 0.000s
No Tests Found

I wonder if there is a problem on line 360 of green.config.py. When I change default_args to new_args, the command line options successfully override the config file settings.

if args_value != getattr(default_args, name):   # change this line perhaps?
    setattr(new_args, name, args_value)

Regarding the g script, I believe you can prevent unwanted glob-expansion in the script by quoting $@. Here's an example script:

$ cat x
#! /bin/bash

python -c 'import sys; print sys.argv' $@
python -c 'import sys; print sys.argv' "$@"

If you run that script with globs in the arguments, the second variant will pass the glob-arguments through to the Python code.

$ ./x 're*' 'L*'
['-c', 'release.md', 'requirements-optional.txt', 'requirements.txt', 'LICENSE']
['-c', 're*', 'L*']

Thanks again for taking a look at all of this.

[CleanCut]

Ah, okay. The problem is in my logic for trying to detect whether a command-line argument was explicitly set. That if statement checking to see if the command-line argument value is different than the default value with the assumption that that will conclusively tell us whether or not the command-line argument was actually specified by the user.

In other words, if we ran

green

Then termcolor would be None AND the argument was NOT specified on the command-line. In this case, the logic "seems" to work, but it's just by chance. The command really wasn't specified on the command-line, therefore checking to see if the value from argparse was the same as the default seemed to validate that it wasn't supplied on the command-line.

But it's a lie! Because:

green -t

Provides the exact same conditions. But the logic that is supposed to detect whether the value came via command line falsely claims it didn't, since the value was actually provided, it just happened to be the same value as it would have been (via argparse) in the first place.

Anyway, I'm not sure if I'm making sense, but I'm aware of the actual problem and I'm trying to figure out a sane way to fix it.

edit: Okay, I think termcolor was a bad example, because it actually defaults to None and specifying it should cause it to be True, but there's a logic problem we've got to fix regardless.

[CleanCut]

I just released 1.8.1 which contains this fix.