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.

classification
Title: No single .msi available for 3.5 release
Type: Stage:
Components: Installation, Windows Versions: Python 3.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: steve.dower Nosy List: chrullrich, loewis, paul.moore, skrah, steve.dower, terry.reedy, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2015-09-15 11:09 by chrullrich, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (3)
msg250756 - (view) Author: Christian Ullrich (chrullrich) * Date: 2015-09-15 11:09
The item "A new installer for Windows has replaced the old MSI" appears on the "What's new" page as an "improvement". It is not. I disagree strongly with the decision to abandon MSI packages for Windows distribution in 3.5. This decision should be reversed immediately, if not sooner.

The .msi package format was introduced well over ten years ago. Since that day, there has been *no* excuse at all to distribute software for Windows in any other form (except "a simple ZIP will do").

The MSI file format's main advantage over ad-hoc executable installers or wrappers is in automated installation. There are several ways to deploy software in a corporate network, such as SCCM/SMS and GPO. While the former can deal with .exe packages, using MSIs is much simpler. In an MSI, the Feature table offers clear information about how to install only part of a product (ADDLOCAL=x,y,z either works as intended or fails cleanly). An .exe wrapper does not provide this information in an obvious way, instead, the user has to rely on external documentation to discover the installable features.

Python's Windows packages have been exemplary for years. This change needlessly gives up this reputation.

As far as the Universal CRT is concerned, for which there are no redist MSIs available, it should be clear that Python is not responsible for installing it, as it is a system component now. If ucrtbase.dll/KB2999226 is not present on the target system, the Python installation should simply abort and inform the user about the missing prerequisite.

(Also, as Microsoft is pushing it into the market at seemingly any cost, the market share of Windows 10 with included UCRT is likely to increase quickly, making the wrapper ever more unnecessary. Servers are, of course, another story.)

Finally, just in case there were any plans on display for the last several months: I do not usually venture into basements to check for leopards. Python's Windows packaging was perfectly fine, and there was no reason to assume that this would change, rather the opposite, in fact.
msg250870 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-09-17 00:39
I will let Steve Dower explain or link to explanations for the change.  But there were reasons.

All of the approximately 10 pre-releases for 3.5.0 have been in the new .exe format.  See https://www.python.org/downloads/release/python-350a1/ , which offered python-3.5.0a1-amd64.exe last Feb 8.
msg251348 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-09-22 21:47
The decision cannot reasonably be reversed now - this sort of passionate feedback was really needed during the alphas to have any impact. I'm sorry you didn't feel the need to participate in Python's development, as this extra feedback would have been useful.

For most users who are installing Python for themselves, the bundle launcher provides a much better experience. As well as CRT detection, it also allows true per-user installation as well as decoupling tasks such as precompiling .pyc files from installing components and enabling the web installers. There is also a more reliable upgrade mechanism that retains previous settings and the launcher is now correctly reference counted (though there will be conflicts with the 2.7 and 3.4 installer...).

After discussions at PyCon US in April, I chose to make the per-user installation the default as it best fits the user segment we (as a development team) are most concerned about. Administrators who are deploying across a network do now need to work harder than before, which we considered a fair tradeoff for non-admin users to be able to install and use Python.

If you much prefer MSIs, you can pass the /layout option to the wrapper and obtain the raw MSIs and install them individually (passing "TARGETPATH=location" as a property). However, I think the documentation for the launcher options (https://docs.python.org/3.5/using/windows.html) is much better than anything we had in the past (I had nothing to do with the old installer, but had to regularly decompile it to diagnose installation issues).

So thankyou for the feedback, but on balance between administrators and individual users we've decided to help save individual users from having to read documentation, at the expense of needing administrators to refer to the instructions to do automated installation.
History
Date User Action Args
2022-04-11 14:58:21adminsetgithub: 69311
2015-09-22 21:47:58steve.dowersetstatus: open -> closed
resolution: not a bug
messages: + msg251348
2015-09-21 14:14:24skrahsetnosy: + loewis, skrah
2015-09-17 00:39:19terry.reedysetnosy: + terry.reedy
messages: + msg250870
2015-09-15 14:16:31zach.waresetassignee: steve.dower

components: + Windows
nosy: + paul.moore, tim.golden, zach.ware, steve.dower
2015-09-15 11:09:25chrullrichcreate