Allow extending lists in --override

[stefanor]

What's the problem this feature will solve?

In Debian package building, we like to run automated test suites when they are available. Many projects use tox, so we try our best to support it.

One of the environment variables we export during many package builds (_PYTHON_HOST_PLATFORM) affects the installation tooling. If a wheel is built with one _PYTHON_HOST_PLATFORM, it won't install with a different / missing value. Tox filters environment variables that are passed to the build. So our wheel that we install into the virtualenv will inherit this environment variable. But when it tries to install the package, the environment variables are filtered, and it fails.

E.g.:

ERROR: foo-0.0.0-cp311-cp311-linux_amd64.whl is not a supported wheel on this platform.

The most obvious solution here is to add _PYTHON_HOST_PLATFORM to passenv. But that means editing the tox.ini/pyproject.toml/setup.cfg from the tool that's driving tox. That's far from ideal. So, I'd like to override it from the command line. But all I can do is blow away any existing passenv, I can't append to it. Most of the time that's good enough, but some packages need specific environment variables to be passed through tox.

In some ways tox isn't a great fit for Debian. tox works with virtualenvs and downloads things from PyPI where Debian maintains a self-contained distribution and requires no Internet access from package builds. So, we drive tox in some unusual ways, but it works. Currently this is --sitepackages and --installpkg / --skip-pkg-install (as appropriate). It's very convenient to be able to use the same tool that the upstream does, to run tests.

PS: Why do we export _PYTHON_HOST_PLATFORM? Because on some architectures it varies between otherwise-compatible machines. So, to make the builds (and debugging symbols) reproducible we set it to what we think the correct value for the platform is. This used to often be rather weird values, but after running into this bug, I made it be right most of the time, I think.

Describe the solution you'd like

Something like: --override testenv.passenv+=_PYTHON_HOST_PLATFORM

Alternative Solutions

I could possibly imagine doing this via a tox plugin. But I can't see an obvious way to have the plugin execute in package builds and not with any other use of tox.

Additional context

[gaborbernat]

PR welcome 👍

[gaborbernat]

In some ways tox isn't a great fit for Debian. tox works with virtualenvs and downloads things from PyPI where Debian maintains a self-contained distribution and requires no Internet access from package builds.

By default, but can be entirely swapped out. I recommend using https://pypi.org/project/tox-current-env, which is what Fedora also does.

[stefanor]

I recommend using https://pypi.org/project/tox-current-env, which is what Fedora also does.

That could make sense in our CI infrastructure. But not in package builds where the test suite expects the package-under-build to be installed. It won't be, at build time.