8 ms·
I don't understand the motivation to remove MSI support. The document says: > Microsoft is slowly moving away from MSI in favor of Windows 10 Apps (AppX) as a
by codedokode 5y ago
I don't understand the motivation to remove MSI support. The document says:
> Microsoft is slowly moving away from MSI in favor of Windows 10 Apps (AppX) as a new deployment model
First, MSI has better OS support than AppX, second, many users are still using Windows 7 and won't be able to use AppX. MSI is not some 30-years old deprecated standard.
- AdamN 5y agoThis PEP doesn't really stop functionality for nearly 3 years and even then it's only with the newest Python version so people can stay on the older version for another 2-3 years of further transition fully supported by the Python community. In 5 years, Windows 10 will be the bare minimum for a secure OS from MS.
- qbasic_forever 5y agoWhy can't legacy MSI support be a standalone library? It looks like no one is maintaining it right now anyways so that should be some red flags right there.
- mananaysiempre 5y agoFWIW, CPython officially follows Microsoft’s support schedule on Windows systems, so versions ≥ 3.9 won’t even install on Windows 7. (Some reasonable people like it and some don’t, but this has been the official stance for a long time.) As for MSI, I’m torn: it is the most widely-supported and reliable packaging approach for Windows and, at the same time, a 20-year-old undocumented dumpster fire of an archive format spliced together with a scripting language forced into the mold of an allegedly-SQL relational database for which it is the sole user, and I can’t really find it in myself to blame Microsoft for wanting to kill that. (At the same time, they also cheerfully promote an admittedly documented 10-year-old metadata format [WinMD] grafted onto a bytecode+metadata format for a different platform [.NET] packed into a Win32 executable format [PE] that is built upon an early and obsolete SysV object file format [COFF] with a stub executable for DOS [MZ] prepended in contravention of the original spec—as a substitute for a 30-year-old undocumented metadata format [TLB] that is actually two different incompatible formats [SLGT or MSFT] but at least doesn’t have so many layers, so I can’t exactly promote them as a shining beacon of logic and sanity either.)
- joshcryer 5y agoPython > 3.9 works just fine on Windows 7 with the api-ms-win-core-path-l1-1-0.dll Wine hack: https://github.com/nalexandru/api-ms-win-core-path-HACK https://github.com/nalexandru/api-ms-win-core-path-HACK It's interesting because once Win 10 support drops there will no longer be any x86 Windows path for Python, but there's still a lot of x86 Windows hardware that still works. I suppose that's more an argument to move to Linux/FreeBSD though on that hardware... I can understand dropping support for something but single breaking changes shouldn't merit it.
- mark-r 5y agoWindows 7 is the best version of Windows Microsoft ever made, and I won't give it up until I have absolutely no choice. I'm already disappointed that I can't get Python 3.9 - I don't understand why they have to actively bar you from installing it rather than just telling you to use it at your own risk.
- waste_monk 5y agoBecause it prevents whole classes of support issues - if you can't install it, you can't raise a ticket complaining that something doesn't work under 7 and then waste support time... even if you say "if you're running windows 7 you're on your own" people will still try it on, or ask for one little tweak to make things work... all effort that could be better spent on forward progress or real support issues. It is far easier to prevent people from being able to have issues in the first place. Also, I agree that 7 was a fine OS, but it is more than two years in the grave... you cannot expect continued support for it. It is sad, but a statement of fact.
- mark-r 5y agoI consider "in the grave" to be a feature. It means Microsoft isn't trying to pull the rug out from under me each night with updates.
- waste_monk 5y ago
- deleted 5y ago[deleted]
- ptx 5y agoThe functionality in the msilib module is somewhat low-level anyway (it basically just opens the database for you and leaves the arcane incantations required for doing anything as an exercise for the reader) so it probably wouldn't be hugely difficult to replace it with ctypes calling msi.dll directly. If I were to replace my msilib-based installer, I would migrate to Wix# [1], a fantastic high-level wrapper for WiX that lets you express your installer in a few lines of C# (and then generates the thousands of lines of XML that WiX needs, but you don't need to touch it). I wouldn't have used msilib if I had known about Wix# at the time. [1] https://github.com/oleg-shilo/wixsharp https://github.com/oleg-shilo/wixsharp