packaging: add tests for old versions cleanup on update

[illume]

BPO	5342
Nosy	@tarekziade, @merwok
Dependencies	bpo-14270: Can't install a project in a specific directory

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/merwok'
closed_at = <Date 2014-03-12.08:28:15.286>
created_at = <Date 2009-02-21.22:43:49.055>
labels = ['easy', 'type-bug']
title = 'packaging: add tests for old versions cleanup on update'
updated_at = <Date 2014-03-12.08:28:15.285>
user = 'https://bugs.python.org/illume'

bugs.python.org fields:

activity = <Date 2014-03-12.08:28:15.285>
actor = 'eric.araujo'
assignee = 'eric.araujo'
closed = True
closed_date = <Date 2014-03-12.08:28:15.286>
closer = 'eric.araujo'
components = ['Distutils2']
creation = <Date 2009-02-21.22:43:49.055>
creator = 'illume'
dependencies = ['14270']
files = []
hgrepos = []
issue_num = 5342
keywords = ['easy']
message_count = 6.0
messages = ['82586', '82588', '139774', '160903', '200057', '213220']
nosy_count = 7.0
nosy_names = ['illume', 'tarek', 'eric.araujo', 'thomas.holmes', 'alexis', 'Sergio.Callegari', 'Alan.Cristhian']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue5342'
versions = ['3rd party', 'Python 3.3']

[illume]

A common problem is removing old files from the installed location.

eg.
version 1 installs.
site-packages/packagename/bla.so

version 2 installs.
site-packages/packagename/_bla.so
site-packages/packagename/bla.py

However, in version 2 if we install over the top of version 1, distutils
does not remove bla.so. Which causes the package to break because
bla.so will be used instead of bla.py

distutils should be able to be given a list of old files to make sure
are removed from the package.

It should work with the various installers... msi, dmg etc, as well as
when using setup.py install.

I've seen this cause breakage with numerous packages. The solution is
to hack some old file detection into each package, or tell users 'delete
the old install first'. Neither of which is really nice.

Specifying an old_files meta data should be able to help.

[tarekziade]

A uninstall command, based on the record of installed files, will be
proposed for bpo-4673.

It should adress your problem, since we will be able to add a new option
in the install command.

I am leaving this issue open so we can keep track of this need.

[merwok]

I’m renaming this to make the status clearer: it’s about adding tests.

[merwok]

Jonathan Fernandes started to work on this at the last Montreal sprint. The tests would use install_local_project, which is missing a parameter to control the destination directory (see bpo-14270).

[SergioCallegari]

Getting bitten by this with numpy/scipy installations

Having previous scipy installed,

pip install -I scipy

creates a broken scipy installation, because the previous one is not removed and gets overwritten. For instance, an old spectral.so file leftover hides the spectral.py file from the new installation causing broken behavior.

Similarly trying

pip uninstall scipy
pip install scipy

does the same, because the distutils uninstall does not uninistall anything, leaves the scipy directory there and all cheerful ends with a 'Successfully uninstalled scipy'.

This is *dangerous*. Mixing old and new code could lead to the weirdest behavior. In principle, one could even use this property to craft packages such that when two subsequent versions are installed one on top of the other malicious things happen even if individually each version is innoquous.