On Mon, Sep 24, 2018 at 03:46:09PM -0400, Nicholas D Steeves wrote: > > > after upgrading system-wide Python installation (in my case from 3.5.3 to > > > 3.5.4), > > > virtualenvs may break due to the outdated interpreter > > > (somevirtualenv/bin/python3) inside the venv, trying to work with a newer > > > stdlib. > > This is in no way specific to virtualenvwrapper which is just a wrapper. > > Hi Andrey! If this is the case would you please reassign this bug to > virtualenv? I don't see any real value in reassigning this bug and I don't want to find out the correct binary package name.
> > > The problem is that mkvirtualenv copies rather than symlinks the python > > > interpreter binary, but symlinks the modules from standard library (e.g. > > > /usr/lib/python3.5). > > This is done by virtualenv, not mkvirtualenv, and it was always that way, > > and it's quite well known that the breakages happen and how to fix them > > (by running virtualenv again). It is done because otherwise Python would > > not find some files using relative paths. > > > > See also https://github.com/pypa/virtualenv/pull/1171 and note "only for > > Python 3.3 and higher". > > As a beginner to Python it seems to me that the current behaviour > (copied interpreter and symlinked modules) is incorrect and that there > are three correct solutions: > > 1) As proposed in that PR, symlink the interpreter. This will fix itself when the PR is merged, not sooner. > 2) Copy the libraries instead of symlinking them. Can't comment on this. > 3) Downgrade the severity of this bug to non-RC, because this is a > known and expected issue when using virtualenvs. Sure, but this is up to the maintainer. > I imagine that the current behaviour is useful because more > vulnerabilities are found in libraries than in interpreters, and so it > is beneficial for them to automatically follow system-wide security > updates. Of course apt isn't aware of all possible locations of > venvs, so [2] would be bad, unless there was NEWS on each security > update to "update all your virtualenvs". In terms of annoyance > factor, the [2] option (plus running virtualenv again) seems more > annoying (but more secure) than using pip install --upgrade inside the > venv. Can't comment on this. -- WBR, wRAR
signature.asc
Description: PGP signature
