Martin v. Löwis wrote: > Am 04.01.15 00:34, schrieb Steve Dower: >> so I'm keen to hear whatever feedback people have. > > One issue that I always wanted to address is patch releases. There are two > aspects I dislike about the current implementation > > a) an upgrade install first uninstalls the previous installation (removing all > files), and then reinstalls all "new" files. In many patch releases, a lot > of > .py files remain unmodified, so it should speed up the upgrade if they > would not > need to be replaced. > b) Installer supports patch files (.msp); I always wanted to provide them in > the > hope that this would reduce the download size. IIUC, it would require > stable > component IDs for components to be upgraded, which I could not manage to > provide. > > So, do you have any plans on dealing with a or b?
So the stable component IDs is dealt with - WiX will auto-generate them based on the relative install path of each file and a user-provided ID (to distinguish between the 32-bit and 64-bit installs, for example. This ID is currently generated from the hash of a user provided URI, which is also used to generate upgrade codes and a few fixed component IDs). Installing patches is something we can defer until 3.5.1, but I am interested in looking into it. My main concern is that it may hurt fresh installs (for example, 3.5.5 is actually 3.5.0.msi+.1.msp+.2.msp+.3.msp+.4.msp+.5.msp) and I'm not sure that true slipstreams are supported/recommended because it will affect future patches (different product codes, IIRC). So fresh installs of later versions may have a significantly increased download size. Because of the split into multiple MSIs, it's also possible to independently version some parts of it. I suspect this will only apply to the py.exe launcher, but if that is unchanged between 3.5.0 and 3.5.1 then we can leave its version at 3.5.0 and it won't be redownloaded/installed. Not a huge saving, but it's a possibility. I expect most MSIs will change in some way between versions, so an MSP is the only good way to improve upgrades (the main benefit of the MSI split here is we will always install the latest 32-bit launcher, and if you install 3.5 32-bit and 64-bit and eventually 3.6 32-bit and 64-bit you'll only have one launcher installed). Another possible problem is that MSI uses file version information to determine whether to update files. .py files don't have version information, so MSI to MSI updates are probably always going to replace everything - another reason why MSPs are the only good choice here. I'll chat to some of the guys who work on the Visual Studio installer, since it uses the same technology and is far more complex than Python's one. They may have some suggestions about how to approach this. > Other issues: > - what MSI version do you require, and what is the minimum > Windows version supporting that MSI version? I need to double-check the support still, but the aim is to support back to Windows Vista, so I think that's Windows Installer 3.0. Of more concern is the installer EXE, which is going to require a minimum level C runtime that may not be available before we've installed... > - Since you are going to install into Program Files by default, > I think the library should be precompiled by default - there > is little chance that a regular user can save .pyc files when > running Python. It might be possible to even include the pyc > files in the distribution, if we can arrange to somehow support > relative paths in co_filename. Agreed. The library will be precompiled by default if you choose the All Users button on the front page, and you can control this independently through the customize option (to precompile Just for Me or install without precompiling). > Regards, > Martin Cheers, Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
