Repository navigation
"make altinstall && make install" behaviour differs from "make install" #63892
Description
| BPO | 19693 |
|---|---|
| Nosy | @ncoghlan, @larryhastings, @ned-deily, @dstufft |
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 = None
closed_at = None
created_at = <Date 2013-11-22.14:39:14.624>
labels = ['type-bug', 'library']
title = '"make altinstall && make install" behaviour differs from "make install"'
updated_at = <Date 2014-11-20.17:36:02.240>
user = 'https://github.com/ncoghlan'bugs.python.org fields:
activity = <Date 2014-11-20.17:36:02.240>
actor = 'dstufft'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2013-11-22.14:39:14.624>
creator = 'ncoghlan'
dependencies = []
files = []
hgrepos = []
issue_num = 19693
keywords = []
message_count = 6.0
messages = ['203771', '205790', '205794', '226555', '226565', '231444']
nosy_count = 4.0
nosy_names = ['ncoghlan', 'larry', 'ned.deily', 'dstufft']
pr_nums = []
priority = 'high'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue19693'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']
Activity
ncoghlan commentedon Nov 22, 2013
From issue bpo-19553:
Requirement already up-to-date: setuptools in /py/dev/3x/root/uxd/lib/python3.4/site-packages
Requirement already up-to-date: pip in /py/dev/3x/root/uxd/lib/python3.4/site-packages
We may need some magic on the pip side when ENSUREPIP_OPTIONS is set to make this behave consistently.
dstufft commentedon Dec 10, 2013
Making this happen is a non trivial change to pip. Is this *required* for PEP-453?
The problem is the pip dependency is already being seen as fulfilled so it's not reinstalling pip again with the new options picked. Likely the actual answer is a command in pip to regenerate the scripts but that will require some engineering.
ncoghlan commentedon Dec 10, 2013
Fixing in pip 1.6/CPython 3.4.1 would be fine by me - that's why I only created it as "high" rather than "release blocker"
ned-deily commentedon Sep 8, 2014
Ping. Also this will be presumably be an issue for the approved 2.7.x backport of ensurepip.
ncoghlan commentedon Sep 8, 2014
No change for 3.x (unless something changed on the pip side that I'm not
aware of).
For 2.7, the Makefile changes, at least for the install and altinstall
targets, were deliberately excluded from the backport PEP.
dstufft commentedon Nov 20, 2014
So here's a thought:
pip does have a CLI flag --force-reinstall which will uninstall and then reinstall whatever is being installed. If we modified things so that ensurepip supported this flag (or always used it with --upgrade) then it would fix this issue. The downside here is that only works with --upgrade.