Bug#884352: virtualenvwrapper: Python interpreter inside virtualenv breaks after system python upgrade
On Tue, Sep 25, 2018 at 01:12:51AM +0500, Andrey Rahmatullin wrote: > 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. bin:virtualenv depends on python-virtualenv and python3-virtualenv so might be a good pick, alternatively src:python-virtualenv. As for the value? See below \/ > > > > 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". If the resolution of this bug depends on [1] (see below), then bin:python3-virtualenv would be most correct and the bug could be marked as forwarded. For maximal correctness I suspect the bug should be cloned and -1 reassigned to python-virtualenv, and -2 reassigned to python3-virtualenv (and marked forwarded with the URL you provided). > > 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. src:python-virtualenv is Python Team maintained and as a member of that team don't you have the authority to reassign this bug to a team package. Alternatively Jan could ACK the severity downgrade for this bug. Cheers, Nicholas signature.asc Description: PGP signature
Bug#884352: virtualenvwrapper: Python interpreter inside virtualenv breaks after system python upgrade
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
Bug#884352: virtualenvwrapper: Python interpreter inside virtualenv breaks after system python upgrade
Hello, This bug came to my attention because elpy -> pyvenv-el -> virtualenvwrapper. On Sat, Sep 22, 2018 at 12:18:33PM +0500, Andrey Rahmatullin wrote: > On Thu, Dec 14, 2017 at 01:33:18PM +0100, Krzysztof Słychań 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? > > 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. 2) Copy the libraries instead of symlinking them. 3) Downgrade the severity of this bug to non-RC, because this is a known and expected issue when using virtualenvs. 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. Cheers, Nicholas signature.asc Description: PGP signature
Bug#884352: virtualenvwrapper: Python interpreter inside virtualenv breaks after system python upgrade
On Thu, Dec 14, 2017 at 01:33:18PM +0100, Krzysztof Słychań 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. > 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". -- WBR, wRAR signature.asc Description: PGP signature
