Support for Python 3.2 broken

Issue #323 on hold
Andrii Yurchuk created an issue

I just came across a problem with tox and Python 3.2 that is described here: https://github.com/travis-ci/travis-ci/issues/5485 I am running tox by the ShiningPanda Jenkins plugin which installs tox like this:

[py32] $ /var/lib/jenkins/shiningpanda/jobs/f517a249/tools/bin/python -c "import pip; pip.main();" install --upgrade tox
Collecting tox
  Using cached tox-2.3.1-py2.py3-none-any.whl
Collecting virtualenv>=1.11.2 (from tox)
  Using cached virtualenv-15.0.1-py2.py3-none-any.whl
Collecting py>=1.4.17 (from tox)
  Using cached py-1.4.31-py2.py3-none-any.whl
Collecting pluggy<0.4.0,>=0.3.0 (from tox)
  Using cached pluggy-0.3.1-py2.py3-none-any.whl

This installs virtualenv version 15.0.1 which comes from the tox's setup.py Looks like changing that to virtualenv<14.0.0 would fix the problem.

Comments (6)

  1. Florian Bruhin

    I don't think it should be tox' job to handle this.

    Virtualenv dropped support for Python 3.2, tox works fine with an older virtualenv, but I think it's not tox' job to ensure an older (3.2-compatible) virtualenv is installed.

    Alternatively, why not run tox with a newer python?

  2. John Vandenberg

    The current version of tox has a list of dependencies which isnt helpful on Python 3.2.

    Surprisingly, the classifiers focus on Python 3 support and don't single out Python 2 support.

    classifiers=[
                ...
                'Programming Language :: Python',
                'Programming Language :: Python :: 3'],
    

    Given the decision by virtualenv, IMO the current tox should explicitly drop support for Python 3.2, or include a environment marker extra that specifies virtualenv<14 for Python 3.2 only (setup.py already has a similar version specific dependency, and a very nice has_environment_marker_support() for that), with the existing non-specific virtualenv dependency for other versions of Python.

  3. Danilo J. S. Bellini

    I think tox might help with that job, and that would be useful to many people. I propose 2 new options for tox.ini that would solve this and many other problems.

    A lot of people are abandoning Python 3.2 because of its prefix-less-only unicode strings, but I'd argue the same kind of incompatibility might appear in the future, and tox virtual environments should work with as many Python versions as possible, even if tox itself isn't compatible with them.

    By now, tox only works with Python 3.2 if the interpreter that runs tox has the tools (pip/setuptools/wheel/virtualenv) in compatible (old) versions. One can do that by hand:

    virtualenv -p python3.2 ~/venv32 --no-pip --no-setuptools --no-wheel
    source ~/venv32/bin/activate
    curl https://bootstrap.pypa.io/3.2/get-pip.py | python3.2
    pip install tox 'virtualenv<14'
    tox
    

    This alternative way to run tox inside a virtual environment is required to run tests with Python 3.2 without downgrading the related packages, but I think it might be simpler. Can't tox add a way to use that custom get-pip in Python 3.2 virtual environments? Something like (supposing curl is in the white-list externals):

    [testenv:py32]
    envcreate_command = virtualenv -p {basepython} {envdir} --no-pip --no-setuptools --no-wheel
    prepare_commands =
      curl https://bootstrap.pypa.io/3.2/get-pip.py | python
    

    That prepare_commands would be called with tox --notest, and happens in the virtual environment. That would be useful in a lot of other contexts like segregating the install step in CIs (which might show "error" for installation errors instead "failure"), or running the "non-pip" install steps just once for a faster way of repeating tests locally (the user would need to call tox -r manually to update the environment, but tox might also watch for updates in that parameter). That would also be a way to install easy_install.

    The envcreate_command is based on the install_command option, and that's an idea about controlling the command used for virtual environment generation (the step whereby this issue happens). Anyone who doesn't install packages or wishes to use another install command instead of pip probably doesn't need to have it installed. Still not enough for radically different environments (e.g. using docker containers), but that's perhaps that's a step in that direction.

  4. Log in to comment