tox-dev / tox

Command line driven CI frontend and development task automation tool.
https://tox.wiki
MIT License
3.66k stars 516 forks source link

RFC: generic configuration manipulation from the command line #634

Closed obestwalter closed 3 years ago

obestwalter commented 7 years ago

This came up in #631.

Maybe tox should just have an -o option to override any ini option, like pytest has? With that, you could do tox -o skip_missing_interpreters=false but also e.g. tox -o distdir=foo, and maybe even tox -o '[testenv:py35]basepython=python3.5'.

-- @The-Compiler

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

The-Compiler commented 7 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.

obestwalter commented 7 years ago

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.

RonnyPfannschmidt commented 7 years ago

as faras i can tell, implementing this right now as is would cement the config file format as ini files

obestwalter commented 7 years ago

@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-Compiler commented 7 years ago

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.

obestwalter commented 7 years ago

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

asottile commented 7 years ago

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)

asottile commented 7 years ago

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)

obestwalter commented 7 years ago

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 :)

gaborbernat commented 3 years ago

4.0 alpha now contains this via the -x or `--override`` flags.