This came up in #631.
Maybe tox should just have an
-ooption to override any ini option, like pytest has? With that, you could dotox -o skip_missing_interpreters=falsebut also e.g.tox -o distdir=foo, and maybe eventox -o '[testenv:py35]basepython=python3.5'.
pytest --help:
-o [OVERRIDE_INI [OVERRIDE_INI ...]],
--override-ini=[OVERRIDE_INI [OVERRIDE_INI ...]]
override config option with option=value style, e.g. `-o xfail_strict=True`.
I think this would be a great direction and would render all needs for specific command line overrides obsolete.
Further interesting snippets from that discussion:
Ooh that sounds like the best _option_.
If we wanted to make it generic perhaps something like this?
-o tox.skip_missing_interpreters=True--option testenv:py35.basepython=python3.5
Or with brackets?
-o [tox]skip_missing_interpreters=True-o [testenv:py35]basepython=True
-- @asottile
As mentioned there I'd prefer brackets because:
The syntax with brackets I proposed was inspired by the interpolation syntax in tox.ini where you'd use
{[testenv:py35]basepython}as well, so I think it'd make sense to keep that syntax.
I'm fine with both though.
The opposite approach would be: don't do this at all and instead focus on improving the documentation to show clearly that all these things (and more) can be accomplished with environment variables and substitutions in tox.ini.
I personally would prefer this approach because we don't have to write even one single line of code for that.
as faras i can tell, implementing this right now as is would cement the config file format as ini files
@RonnyPfannschmidt that is another important point keeping #600 in mind. If this would be implemented at all then the syntax should be config file agnostic.
The nice thing about having -o is that I don't need to modify the tox.ini at all.
For example, if I want to contribute to some project, and it does something in its tox.ini I disagree with (say, set a basepython which is different on my system). However, I want to use tox to run the tests locally because it makes my life easier.
Right now, I need to edit tox.ini accordingly, do my contributions, and then make sure to not accidentally commit the tox.ini changes I made. With an -o, I can simply override it one-time at the commandline.
The nice thing about having -o is that I don't need to modify the tox.ini at all.
[...]
Right now, I need to edittox.iniaccordingly, do my contributions, and then make sure to not accidentally commit thetox.inichanges I made. With an-o, I can simply override it one-time at the commandline.
True. From that POV it might actually be worth the effort.
Instead of -o option option option, I'd suggest -o option -o option -o option as this will allow non ambiguous parsing (in my experience nargs='+' on options just doesn't work well as it then has to be the last thing on the command line)
Ideally this should also deprecate the other cli options such as --skip-missing-interpreters as well (these can probably be reimplemented using this new option interface)
Ideally this should also deprecate the other cli options such as --skip-missing-interpret
I think so too. These can go in 3.0 then :)
4.0 alpha now contains this via the -x or `--override`` flags.