Hi Laura, On 11/29/2015 07:12 AM, Laura Creighton wrote: > pyenv is going away. python -m venv is the preferred way to get a venv > > https://bugs.python.org/issue25154 > > Of course if you try it, you may get: > > Error: Command '['<directory>/bin/python3.4', '-Im', 'ensurepip', > '--upgrade', '--default-pip']' returned non-zero exit status 1 > > which turns out to mean: > > Your Python isn't configured with ensure-pip!
AFAIK "isn't configured with ensurepip" is a thing which is only done to Python by some downstream distributors (e.g. Linux packagers). If they remove ensurepip, it should be their responsibility to also fix the venv module accordingly (at least enough to provide a useful error message). So I believe that's a bug that should be filed against whoever is distributing the Python you're using. > Right now, I personally don't know why there is a venv at all. Because virtualenv is an ugly hack which is difficult to maintain (I should know, I used to maintain it). In order to work at all, virtualenv maintains its own patched copy of several stdlib modules (based originally on Python 2.4(?) and modified since then) and uses them instead of the version distributed with whatever version of Python you are using. Some other stdlib modules it monkeypatches. As you might expect, this regularly causes problems when new Python versions are released, requiring even more hacks piled atop the previous ones. It's a real testament to the dedication of the current virtualenv maintainers (thank you, PyPA!) that it even works at all. The built-in venv module in Python 3.3+ fixes that by building a minimal level of support for virtual environments directly into the Python interpreter and stdlib, removing the need for (monkey)patching. Of course that interpreter support isn't available in Pythons prior to 3.3, which is why virtualenv remains much more popular today. (Also, the first version of venv in Python 3.3 didn't automatically install pip into the envs, which made them less useful, because at that point pip was a purely third-party project. That's been fixed with ensurepip in Python 3.4+). I very much hope that some day in the future, when all new Python projects are in Python 3, almost everyone will use venv, and virtualenv will be relevant only to those maintaining legacy Python 2 projects. There has been some work towards writing a transitional version of virtualenv that looks the same to users, but (under the hood) uses the old code only for 2.x and uses venv for Python 3. > Despite > the similarity of names, it doesn't seem to be about doing what virtualenv > does. I don't know what you mean by this. Venv is intended to do _exactly_ what virtualenv does, only better. Unless by "what virtualenv does" you mean "also support Python 2." > I think it is only meant to be used by people who want to install > packages but not site-wide, but I am not sure about that. I don't know what you mean by this either. Isn't the ability to "install packages but not site-wide" precisely what virtualenv (and venv) give you? > I don't think > there are any plans to give venv the functionality of virtualenv, What functionality do you mean? > so > presumably there are people who like it just fine the way it is now. > They must have very different needs than I do. I don't know, since you never said what it is about venv that doesn't meet your needs :-) Carl
signature.asc
Description: OpenPGP digital signature
-- https://mail.python.org/mailman/listinfo/python-list
