[Python-modules-team] Bug#752467: python-virtualenv: no command "virtualenv"

[Simon McVittie]

[Please try to use a Subject line that will remind other developers which
bug you're talking about when mails from it are seen out of context. I've
retrieved the title from the original bug report.]

On Thu, 22 Mar 2018 at 12:41:33 -0400, Marvin Renich wrote:
> I just ran into this issue.  I am installing OctoPrint from source on a
> BeagleBone Black, and OctoPrint uses python2, and I would rather not
> install python3 if I can avoid it.

Python 2 is no longer security-supported after 2020 (and that's about
halfway through the expected support lifetime of buster), so in the
buster timescale, Python 3 should really be preferred.

In a space-constrained environment, you can install python-virtualenv
and run "python -m virtualenv ARGS" as a substitute for "virtualenv ARGS".
Does that help?

> My (strong) opinion is that the correct solution should involve a single
> /usr/bin/virtualenv command that works correctly with both python2 and
> python3.

For commands where the user neither knows nor cares how the command
is implemented because it doesn't matter, like the tappy command from
src:tap.py, having a single command is absolutely fine.

For commands where the version of Python used for the implementation
matters, like python[3]-coverage and pyflakes[3], I'm not so sure about
this reasoning. virtualenv is somewhere between those extremes, because
it has a -p/--python option, but the default if that option is not given
is to use the same Python version used for virtualenv itself.

If I understand correctly, the script that you assert should exist
has these semantics when run without the -p/--python option:

    * Please set up a virtual environment to run Python code
    * After running this command, the virtual environment will be suitable
      for running either Python 2 code or Python 3 code but probably not
      both, and I can't know which

which don't seem amazingly useful? It would seem better for there to be
a predictable default, so that at least within Debian, virtualenv does
something consistent; and Python 2 is going to reach the end of its
security support before buster does, so for buster, that default should
probably be Python 3.

    smcv