[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
_______________________________________________
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
