PEP 453: Windows installer integration

[ncoghlan]

BPO	19550
Nosy	@loewis, @ncoghlan, @larryhastings, @ned-deily
Dependencies	bpo-19406: PEP 453: add the ensurepip module

^{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: ```python assignee = 'https://github.com/loewis' closed_at = created_at = labels = ['type-feature', 'OS-windows', 'release-blocker'] title = 'PEP 453: Windows installer integration' updated_at = user = 'https://github.com/ncoghlan' ``` bugs.python.org fields: ```python activity = actor = 'ncoghlan' assignee = 'loewis' closed = True closed_date = closer = 'loewis' components = ['Windows'] creation = creator = 'ncoghlan' dependencies = ['19406'] files = [] hgrepos = [] issue_num = 19550 keywords = [] message_count = 10.0 messages = ['202610', '202629', '202632', '202826', '202830', '203394', '203399', '203402', '203732', '203733'] nosy_count = 5.0 nosy_names = ['loewis', 'ncoghlan', 'larry', 'ned.deily', 'python-dev'] pr_nums = [] priority = 'release blocker' resolution = 'fixed' stage = 'needs patch' status = 'closed' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue19550' versions = ['Python 3.4'] ```

[ncoghlan]

Part of the PEP-453 implementation as tracked in bpo-19347.

This issue covers the Windows installer updates:

• new option to choose whether or not to invoke "python -m ensurepip --upgrade" on the just installed Python

• also add the result of calling 'sysconfig.get_path("scripts")' to PATH when PATH modification is enabled in the installer

[61337411-43fc-4a9c-b8d5-4060aede66d0]

IIUC, the current implementation strategy is to check the wheels into source control. If so, what's to be done in the installer (except for making sure that the wheels get bundled and installed into the msi, which it should do by default?)

[61337411-43fc-4a9c-b8d5-4060aede66d0]

I missed the original message. I'll try to come up with a patch.

[61337411-43fc-4a9c-b8d5-4060aede66d0]

I'm currently blocked on a discrepancy of this request and PEP-453.

You are asking me to run "ensurepip --upgrade", whereas the PEP asks for an option to install the bundled pip (i.e. a mere ensurepip). Which of these should be done?

[ncoghlan]

After a CPython installation with the option checked, the installed pip should be at least as recent as the bundled one: http://www.python.org/dev/peps/pep-0453/#invocation-from-the-cpython-installers

You're right the prompt may be better as something like "Install/upgrade pip?", since a previously installed pip may be upgraded when installing a CPython maintenance release.

[1762cc99-3127-4a62-9baf-30c3d0f51ef7]

New changeset e0c4a5b2b739 by Martin v. Löwis in branch 'default': Issue bpo-19550: Implement Windows installer changes of PEP-453 (ensurepip). http://hg.python.org/cpython/rev/e0c4a5b2b739

[61337411-43fc-4a9c-b8d5-4060aede66d0]

I have now committed the changes to the installer. A demo installer can be found at

http://prof.beuth-hochschule.de/fileadmin/user/mvon_loewis/python-3.4.16027.msi

I'm skeptical about the lack of proper deinstallation: per convention, uninstallation of software ought to be "clean" on windows, i.e. return the system to the state it had before the installation.

Uninstallation currently isn't clean when pip installation is selected. I know this is what the PEP says, but I'm still unhappy, and I know that users will dislike it. So as a compromise, I made the installation of pip non-default, meaning that users have to opt into installing something that doesn't properly uninstall.

[ncoghlan]

That sounds reasonable to me - thanks!

[ned-deily]

If it is acceptable for the "Remove" option to be somewhat unpredictable in the case where pip or setuptools was already installed and not by the installer, would "python -m pip uninstall --yes pip setuptools" work? If not, should a new issue be opened to find a solution?

[ncoghlan]

I think "Off by default" is a reasonable solution for the beta (and even 3.4 final), but a separate issue explaining *why* it's off by default would be good. I can then ping the pip folks to ask for suggestions - if they come up with something workable, we may be able to have it turned on by default in 3.4 final.