Part of the PEP 453 implementation as tracked in issue 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

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?)

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

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?

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.

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

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.

That sounds reasonable to me - thanks!

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?

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.