Closed cotts closed 3 years ago
No, I just realized that now, I just included -p py 27
... I will undo those other changes...
My linter made those changes.
@cotts @cuducos I'm a bit late to the party here and I'm fine with the change, but just as a note for the future, specifying -p py27
is probably not the "best practice" way to set the Python version of a virtualenv. The reason has a lot to do with why in Python 3 you'd just do:
python -m venv .venv
Where the command you run is your Python interpreter of choice and tell it to load the venv
module and run it (and every other argument is an argument to the venv
"main").
This has a huge benefit of specifying the base Python interpreter explictly. In a system where you can have a bunch of different versions / installations of Python (pyenv
, the version that came with the OS, different versions of Python 2.7.x and 3.x), just running virtualenv
as a command may end you up with an unexpected base Python version for your virtual environment.
This is probably much better as a universal approach for Python 2.7:
/path/to/your/preferred/python2/bin/python -m virtualenv venv
(and in Python 3.x replace virtualenv
with venv
of course).
This is explicit, and as we all know (import this
will tell you), "Explicit is better than Implicit".
I just included the flag
-p py27
inside the instructions to create the virtual env to ensure that the right python version will be used.