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

[Marvin Renich]

* Simon McVittie <smcv at debian.org> [180322 13:21]:
> [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.]

Oops, sorry!  I did see this and intended to fix it, but forgot.

> 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.

I agree.

> 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?

Well, yes, except for lack of documentation.  Being an experienced
programmer, but relatively new to Python, I did not think of (and would
not have thought of) this until after downloading the virtualenv_*.deb
file and dissecting it.  Once I had done that, several one-time
solutions were evident.

In fact, I believe that even if I were an experienced Python programmer,
I would need to look at /usr/bin/virtualenv to know that is it simply a
cover for invoking the module with arguments.

> > 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.

Sure.

> 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.

Okay, I see your point.  However this only makes a difference if you
have both versions of Python installed.  It is more like:

    * Please set up a virtual environment to run Python code
    * If only one version of Python is installed, use that.
    * If more than one version is installed, in the absence of a
      command-line option to indicate otherwise (-p in this case),
      always use the preferred version (python3).

This seems perfectly useful and useable to me.

In fact, the current situation, where virtualenv depends on, and only
uses, the python3 module, is broken.  If my apt configuration installed
recommeds by default, installing python-virtualenv would have installed
python3 and python3-virtualenv.  virtualenv would have then set up a
python3 environment for OctoPrint (without me realizing it), and
OctoPrint would be broken and I would have had a much harder time
figuring out what was wrong.

The current Python naming convention, IIUC, is to use python for the
python2 interpreter, python3 for the python3 interpreter, and use
python-* and python3-* for package names for modules for the respective
versions.  I see that the python[3]-coverage and pyflakes[3] packages
(according to the pkg description) include version-specific commands.
It seems to me that maybe the correct solution for virtualenv is to have
separate virtualenv and virtualenv3 packages for the respective
versions, or simply remove virtualenv as a separate package and have the
py[3]-virtenv packages provide differently-named virtualenv commands.

The more I think about it, the more I like the latter solution.  What
was the reasoning for splitting the command into its own package?  With
the pyflakes and py-coverage precedents, it doesn't seem like users
should expect virtualenv to create a python3 environment by default, but
might reasonably expect there to be a virtualenv3 command that does.

Is it planned to include python2 in buster, in spite of the impending
end of support?  Certainly, if buster will ship with python2, the
virtualenv and python[3]-virtualenv packages should work the way users
ought to be able to expect from the naming conventions.

I think the fact that virtualenv in stretch currently creates a python3
environment when a user who specifically chooses to install
python-virtualenv is expecting a python2 environment by default is a bug
whose fix should make it into a stretch point release.

Mike Hommey:  As an aside, upgrades do install Recommends that were not
previously installed, according to a simple test with an existing VM
here.  You do need to comment out Apt::Install-Recommends "false" if you
have chosen the non-default value.

...Marvin