I'm looking again at updating tox to the latest upstream 1.7.1. Along the way, I'd like to make /usr/bin/tox a Python 3 script.
This requires that virtualenv be importable, e.g. `$python -m virtualenv`. It is today in Python 2 since /usr/bin/virtualenv is a Python 2 script and we only build it for one version of Python. I want to change that too, so that at least we build the virtualenv modules for both Python 2 and 3. I'd like to switch /usr/bin/virtualenv to be Python 3 as well, and I'd like to tackle the vendorizing issue similar to how we fixed it with ensurepip, since we have all the wheels we need now. This means however that I need to rejigger the binary packages in the python-virtualenv source package. Right now, python-virtualenv contains both the modules and /usr/bin/virtualenv. I need to at least add a python3-virtualenv package to contain the Python 3 modules. But it doesn't make sense to have a /usr/bin/virtualenv with both a Python 2 and Python 3 shebang line, and thus it doesn't make sense to put Python 3 /usr/bin/virtualenv in the python-virtualenv binary package. However, I still want to make it obvious and easy which package someone needs to install to get the command line script. My thinking is that I would add a `virtualenv` binary package which would contain just the /usr/bin script (with a Python3 shebang) and any other common files as makes sense (e.g. the manpage). `virtualenv` would Replaces/Breaks `python-virtualenv` and Depends on python3-virtualenv. I thought about using a python-virtualenv-common for that but since this will be the most likely installed package for end users, I thought `apt-get install virtualenv` looked nicer. Thoughts? -Barry
signature.asc
Description: PGP signature
