Closed obestwalter closed 3 years ago
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 edit
tox.ini
accordingly, do my contributions, and then make sure to not accidentally commit thetox.ini
changes 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.
This came up in #631.
-- @The-Compiler
pytest --help
: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:
-- @asottile