[issue29231] Broken MSIs in Python 3.5+
New submission from KeyWeeUsr: In versions _lower_ than 3.5.0 there was a `.MSI` installer for Windows, which had a really nice hidden option. That option looked like this: msiexec.exe /a "file.msi" /qb /L*V "file.log" ALLUSERS=0 TARGETDIR="target" CURRENTDIRECTORY="%cd%" which basically allows me to ignore admin rights, because the MSI turns to some kind of installer for whole network, thus the permission workaround for older Python versions. With Python 3.5.0 was introduced a new `.EXE` installer, which has `.MSI` files packed in itself, you can get them out with: python-3.5.0.exe /layout [optional target directory] yet there's a really annoying thing going around with this solution. When I do this, the `.MSI` files have a `-d.msi` suffix and when I manually unpack it with the `msiexec` command above, **every file** has that suffix too, which makes it a _completely damaged_ installation. Renaming the files isn't really an option as each file has `-d.`, not `-d.msi.` suffix, so it's too hard to rename it in a simple way with tools such as Batch, unless I want to check for multiple cases (e.g. folders). Is there any way how to extract the content of the installer to a separate folder, like it was possible before **without** any additional stuff put into `Programs and features`, such as `Python 3.5.0 (64bit)` or similar? Or other question - is there any way how to forbid the installer to access `Programs and features`, shut it from asking admin privileges and registry at all? It's quite useful if I want to have multiple python fresh installations not bound to anything at all with testing as its main purpose. Note, that I have no intention to use python launcher (that `py.exe` thing), virtualenv or any other alternative "solution" as every of them allows me to install only a one **global** Python installation of the same version and/or is too big for quick usage and at the same time I need to have an option for testing on a fresh interpreter not modified by anything and completely cut off from the OS stuff. Any ideas how can I achieve the same behavior even on newer Python versions with the EXE installer? ------ components: Installation, Windows messages: 285157 nosy: KeyWeeUsr, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Broken MSIs in Python 3.5+ type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue29231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29231] Broken MSIs in Python 3.5+
Changes by KeyWeeUsr : -- versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue29231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29231] Broken MSIs in Python 3.5+
KeyWeeUsr added the comment: Re blog post "Why are there so many Python installers?" > As a result, the old installer always requires administrative privileges just > in case you choose to install for all users. This prevents installation of > Python on machines where you do not have full control over the system. So not true. Read the first command I used, that doesn't require any permission at all. I was able to install Python without any registry or P&F stuff at "Guest" account in an internet cafe where you couldn't even throw stuff to the Trash with the same MSI installer. Notice the "/a" switch, not "/i" (install). Secondly, I'm glad for the change, but the installer is still in an imperfect shape - leaves traces. That makes you able to use only a single version (as mentioned before). Unless, of course, you don't want to copy&paste the whole folder, which although works is also stupid and still requires at least one successful installation with traces in the system. > Always requires administrator privileges <-- no Only allows installation for all users <-- no Only allows configuration at the command line (via msiexec) <-- not sure what the "configuration" means in this context Prevents the executable installer from installing for all users <-- I didn't really use that, but... what? Seems weird. Have you tried with "/a ALLUSERS=1"? It should purge the elevation. Anyway, this has nothing to do with the issue, because what I'm talking about are MSIs that are _extracted_ from the current EXE installer via "/layout" switch. There comes the problem - you can't install from those MSIs (not directly, but probably works with EXE as a casual python installation - I don't want that), because the MSIs are ***corrupted*** in some weird way, probably some debug command is called together with the "/layout" judging from the "-d" string in the filenames - useful only for debugging the inside of the MSIs, otherwise completely unusable. Please, just try to do what I wrote to see what's actually going on. If there is any way how to fix the "/layout" to unpack correctly, ++ for the new installer. Otherwise, although the EXE has a lot of features I use for system-wide interpreter, I hate the change. -- ___ Python tracker <http://bugs.python.org/issue29231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29231] Broken MSIs in Python 3.5+
KeyWeeUsr added the comment: python-3.5.2.exe /layout 11.01.2017 19:30 . 11.01.2017 19:30 .. 11.01.2017 19:30 3 035 136 core_d.msi 11.01.2017 19:30 2 240 512 core_pdb.msi 11.01.2017 19:3098 304 dev_d.msi 11.01.2017 19:30 110 592 exe_d.msi 11.01.2017 19:30 102 400 exe_pdb.msi 11.01.2017 19:30 5 378 048 lib_d.msi 11.01.2017 19:30 4 820 992 lib_pdb.msi 29.10.2016 11:1329 269 656 python-3.5.2.exe 11.01.2017 19:30 1 179 648 tcltk_d.msi 11.01.2017 19:30 139 264 tcltk_pdb.msi 11.01.2017 19:30 331 776 test_d.msi 11.01.2017 19:30 286 720 test_pdb.msi 12 File(s) 46 993 048 bytes 2 Dir(s) 1 245 736 960 bytes free --- msiexec /a exe_d.msi targetdir=%cd%\ Msiexec window has title "Python 3.5.2 Executables (32-bit debug)" and the targetdir contains: 11.01.2017 19:36 . 11.01.2017 19:36 .. 25.06.2016 21:5751 712 pythonw_d.exe 25.06.2016 21:57 364 544 pythonw_d.pdb 25.06.2016 21:5751 712 python_d.exe 25.06.2016 21:57 364 544 python_d.pdb 4 File(s)832 512 bytes 2 Dir(s) 1 264 963 584 bytes free Notice, that everywhere is "_d" I talk about so much. > ...and puts them in a location where they will be used later without > redownloading... Yes, in a state that only the EXE installer is able to use them. > *hypothetical* msiexec /a python-2.7.13.msi targetdir=%cd%\ 11.01.2017 19:45 . 11.01.2017 19:45 .. 11.01.2017 19:45 DLLs 11.01.2017 19:45 Doc 11.01.2017 19:45 include 11.01.2017 19:45 Lib 11.01.2017 19:45 libs 17.12.2016 20:4938 591 LICENSE.txt 17.12.2016 20:34 474 595 NEWS.txt 11.01.2017 19:45 835 584 python-2.7.13.msi 17.12.2016 20:4427 136 python.exe 17.12.2016 20:43 2 639 872 python27.dll 17.12.2016 20:4427 648 pythonw.exe 03.12.2016 21:0156 938 README.txt 11.01.2017 19:45 tcl 11.01.2017 19:45 Tools 17.12.2016 20:44 111 104 w9xpopen.exe 8 File(s) 4 211 468 bytes 9 Dir(s) 1 162 199 040 bytes free Fully usable, portable and working Python interpreter for Python installers <3.5.0 without a single beep about admin rights (kivy, numpy, scipy, cython, mingwpy, etc.). With some workaround probably even usable for ALLUSERS=1, but I'm not going to try that on my system. How is Debug installer not an issue/bug in a Python Release? Am I missing something or is it ok to unpack Debug installers from an official installer and not the actually used ones, the ones that produce Release that works? -- ___ Python tracker <http://bugs.python.org/issue29231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29231] Broken MSIs in Python 3.5+
KeyWeeUsr added the comment: > Ah, you're using the full installer, which has the non-debug versions > embedded and therefore does not ever need to download them. Hm, makes sense now, however, isn't that a bug? I mean, even if it's embeded... I'm just curious ^^ > If you start from the web installer... Aha, there's my problem! After using the web installer everything seems ok for me. Python now runs happily! RE the unsupported: yeah, I kind of ignored that intentionally. Don't get me wrong, but the functionality you so badly want to push away is a wonderful thing. Ok, there's venv, I'm mostly satisfied with that or system-wide interpreter, but there are cases when you have to debug some annoying problems and you might broke the installation before thus a hypotetical issue arises. Maybe you deleted a file unintentionally, put a header for compilation here or there, renamed something... What is the first thing someone asks you on for example IRC? "Have you tried a fresh Python installation?" Uhm, sure, because it's so easy if the installer throws things everywhere it can (registry, p&f, ...). That's mostly not an issue, simple "Repair" is enough unless... you have a large build environment and reinstalling the environment from scratch could take a **long** while depending on the complexity of the environment. How do you test a fresh installation then? <-- Really, that's a serious question. I could come only with this before, though nuget coule be usable too ^^ Also, the network installer is almost the same thing as common MSI, but without elevation. It's like ~500kB or something and does basically this - adds keys to registry, to p&f, etc with a folder that you choose for installing via the network installer afaik. I just skip the part that makes Python unportable or burned into the system. What I do is basically what you do after compilation. Take binaries and put them somewhere, so that they run, nothing less, nothing more. Thanks for your help, guys :) -- resolution: not a bug -> works for me ___ Python tracker <http://bugs.python.org/issue29231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
