impossible to use install_command if you need newer pip

[ssbarnea]

It seems that the current implementation of install_command introduces a conflict that seems impossible to resolve when system pip version is older, mainly because it is impossible to tell tox to upgrade pip before installing requirements.

Imagine that you have this command:

install_command = pip install -cupper-constraints.txt {opts} {packages}

This may fail if the pip version is older and does not support -c parameter but at the same time we cannot upgrade pip inside the virtualenv before running the command.

If I try to force upgrading pip by adding it to the top of dependencies, I still get the failure, because the -c param does not exist. If I remove the param, I loose the functionality needed for the rest of packages.

Somehow, this makes the entire install_command impossible to use. Do we have a workaround for this issue, one that does not require upgrade system pip which would be against tox principle of not having to touch the system.

Considering that doing the installation manually, using commands = works, this indicates a tox bug.

[BenjamenMeyer]

1. Question: Does a multi-line install command resolve this?

install_command = 
     pip install --upgrade pip
     pip install -cupper-constraints.txt {opts} {packages}

2. One thing I've run into is system tox not being new enough, so I've ended up making a custom bash script (https://github.com/BenjamenMeyer/traveling-salesman/blob/master/bash/tox) that creates its own virtualenv within which it then executes a newer version of tox. That may also solve your use-case here - at least as a work around until a proper solution can be found.

Another solution (more specific to your description) might be to have a flag to auto-upgrade pip:

[testenv]
autoupgrade_pip = true

Which tox could then use to update pip automatically before doing anything else when creating the virtualenv.

[ssbarnea]

I do find both ideas good. Maybe the autoupgrade pip one can be make a little bit more generic for upgrading all implicit packages, which I think is composed out of virtualenv, pip and setuptools.

If this can param can also be mentioned at main tox section, even better (at least for me).

[dchudz]

@ssbarnea I'm having a similar issue - can I ask what you ended up doing as a workaround? Just skip_install=True and putting all installations in the commands = section?

[gaborbernat]

So I think this falls under new feature requirements, we should support a requires field which gets evaluated after virtual environment creation, similar to how https://www.python.org/dev/peps/pep-0517/ has it for build requires.

[gaborbernat]

#791 reports how now we always have latest pip. Will close in favour of that request.

[ssbarnea]

@gaborbernat I am using tox 3.7.0 (and virtualenv 15.0) and I am sure that it does not use latest pip. I still see pip reporting that version 9.0.1 is older than 19.0.3.

I am still looking for a reliable way to assure a minimal pip version before installing deps = ....

[gaborbernat]

@ssbarnea #791 will allow such feature... for now the only way you can control version of pip is by controlling the version of virtualenv installed and then setting the VIRTUALENV_NO_DOWNLOAD env var. One could say https://tox.readthedocs.io/en/latest/config.html#conf-requires virtualenv >= 16.4.0, this would enforce the latest pip. For now this would need to be manually provided by the user, however, as I write this I'm also working on #998 which will automate this away.

tox configuration specification — tox 3.7.1.dev18 documentation