This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steve.dower
Recipients Jurko.Gospodnetić, loewis, paul.moore, steve.dower, tim.golden
Date 2014-03-11.22:17:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1394576238.4.0.986758488378.issue20883@psf.upfronthosting.co.za>
In-reply-to
Content
UAC is still required for the installer - unfortunately MSI just doesn't support having a single package that can do both elevated and unelevated installs. Still, you can install once per-user and then copy the PythonXY folder onto another machine, which does not work as easily with the all-users install. I actually have a collection of zipped Python installs and an automated test that extracts each one in turn.

I'm not sure what constitutes a "complete" patch, but I've attached a patch for msi.py (though I have no idea how it works and can't test it locally) and launcher.c to look at the new keys. If there are tests for these I don't see where they are, but I'm happy to extend them.

I don't think backwards compatibility is a concern here. Older versions of Python will continue to incorrectly handle side-by-side per-user installations with the py.exe launcher and any other tools that use the registry to find installations. Existing tools that are not modified will find Python 3.5 installations with identical mechanics to previously, while those that also look for the InstallPath32 and *64 keys will find both installations if they are there. Even if the changes are backported as a bugfix, nothing changes for tools that are not aware of the new keys.
History
Date User Action Args
2014-03-11 22:17:18steve.dowersetrecipients: + steve.dower, loewis, paul.moore, tim.golden, Jurko.Gospodnetić
2014-03-11 22:17:18steve.dowersetmessageid: <1394576238.4.0.986758488378.issue20883@psf.upfronthosting.co.za>
2014-03-11 22:17:18steve.dowerlinkissue20883 messages
2014-03-11 22:17:18steve.dowercreate