tox4: plugin migration guidelines

[ssbarnea]

Lets try to use this thread for documenting how to port plugins to tox4.

One first question is around old tox_configure hook implementation which no longer exists.

[gaborbernat]

Can you detail exactly what's your use case/plugin functionality you want to migrate. Plugins interface is TBD at the moment, but the thought here is we now have a new paradigm so don't expect a 1 to 1 migration.

[ssbarnea]

I found this while writing one of the most basic plugins possible at https://github.com/ssbarnea/tox-bindep/blob/main/src/tox_bindep/hooks.py#L13

Basically I need to run some checks before the virtualenv is initialized, when I have access to tox own venv. This works fine with tox3 but I do not know how to make it work with tox4.

[gaborbernat]

Thanks, I'll have a think over this over the next week or so and get back to you when I've collected my thoughts.

[f3flight]

Hey folks, pretty much the same issue - I'm trying to migrate to tox 4 but I was using tox_configure in a custom internal plugin, which expected a fully populated config structure with env configs as well, and it would:

1. scan all envs and based on their basepython values, determine which python versions are required
2. replace all generic basepythonX.Y paths with custom paths, depending on version of python
3. find the highest python version used across version-specific envs (like py39 py310 etc)
4. replace basepython for all non-versioned envs with highest python version (i.e. use highest version for code quality and similar envs)

In tox_configure, I'd scan through config object and mutate some data inside. How do I do this now in tox 4?

[f3flight]

User's project may require an arbitrary version of Python to work. The code or dependencies may be incompatible with other Python versions. We cannot enforce on the user the version we use to provide tox as a zipapp. And we don't want our toolchain to depend on the version of Python a given user needs, which would require supporting toolchain bootstrapping for all python versions, or releasing multiple toolchain zipapps (tox37 tox38 pdm37 pdm38 etc).

[gaborbernat]

User's project may require an arbitrary version of Python to work. The code or dependencies may be incompatible with other Python versions.

IMHO such envs should explicitely define the base python for these envs accordingly rather than depend on such arbitrary dynamic version discovery. Not specifying the base python is saying I don't care about the python version, any will do.

[f3flight]

I get your point, but at the same time I see specifying pyXY env(s) as explicit indication of supported python version, so I don't think the user needs to tell which version to use by default again separately via basepython setting.

[gaborbernat]

That would make the version of environments depend on other environments which in my POV is not a great place 🤔 Also applications don't tend to use pyxy format 😊 so this only works for libraries.

[gaborbernat]

I see specifying pyXY env(s) as explicit indication of supported python version, so I don't think the user needs to tell which version to use by default again separately via basepython setting.

I guess this is where we disagree at core. I strongly believe otherwise, hence the tool is not designed to allow this behaviour (easily).

[ZenulAbidin]

I ported a plugin from using tox_configure in tox3 to tox_add_env_config in tox4. It checks for specific environment variables and some extra config options.

Tox doesn't seem to be complaining about that, so that's one avenue to explore.