auto provision requires environment

[gaborbernat]

Although the requires has been implemented using it in practice is not the nicest. Especially when having projects that have different requires subset. It's up to the users to create environments to satisfy those requirements which is PITA. I propose instead we go meta, and create it for them automatically to keep the expectation that you only need to install tox to run tests for a tox powered project:

• no requires section -> just use the system main tox 👍
• requires specified -> create a virtual environment under {toxworkdir}/.meta-tox and install the specified requirements; then delegate invocations to tox within that virtual environment.

@asottile @obestwalter please feed in your thoughts about this.

@RonnyPfannschmidt @nicoddemus what do you think? I believe this would make #828 a usable path to go down: these env providing plugins could be automatically provisioned, and they would be exactly specified -> e.g. tox-pytest-static == 1.1.0.

[RonnyPfannschmidt]

sounds like a good idea

a tox integration of pre-commit and basic pytest-plugin might be nice starting points

[gaborbernat]

the pytest has quite a few moving parts with it so not sure it would be the best fit 🤔

[RonnyPfannschmidt]

@gaborbernat "basic" would mean something that can invoke pytest plainly with posargs, nothing else

[ssbarnea]

This would be brilliant to have! Just name it .meta as we don't want to repeast ourselves (.tox is the folder name) and I bet nobody is already using a hidden directory like ".meta".

This also solves another problem: we no longer need to upgrade tox on the operatiing system to support newer features, tox could install a newer tox inside .meta and use it.

[obestwalter]

Sounds like a good direction to explore. I also like the idea of being able to have a different version of tox in that .tox/.meta which would solve the problem of having an up to-date system tox (in the very long run, as that version would still need to make it first to the distros/packages lagging years behind).

[nicoddemus]

Agreed, sounds like a good idea

[gaborbernat]

I've started work on this (will also restructure the long session.py into a module, as part of this, as the provision also needs some part - e.g. the reporter) - https://github.com/gaborbernat/tox/tree/provision/src/tox/session.

[obestwalter]

I know that we have no official programmatical API (yet?), but I think we should add a thin compatibility layer here and add a deprecation warning for tox 4.

I know for example, that PyCharm uses the session and the config, to implement their tox integration: https://github.com/JetBrains/intellij-community/blob/master/python/helpers/pycharm/_jb_tox_runner.py

[gaborbernat]

Yeah, will try as much as possible.