New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can we get an MSI installer for something past 3.4.4? #75331
Comments
I've noticed that the only installers that are able to successfully complete on my windows 7 x64 system are the MSI installers. Unfortunately, python.org hasn't released an MSI version since 3.4.4 it seems. Is it possible to get an MSI installer for one of the more recent versions? |
The short answer is no. We no longer use the MSI installer. Perhaps the windows experts will be interested in exploring why you can't use the current installers, since they work for most people. |
Looking at your log, you clearly have some sort of configuration blocking installers or else corruption somewhere on your system. There really isn't enough information available for me to be able to tell. Perhaps you have a virus scanner running that is blocking the installer? |
If that's the best thing that you can suggest, it's obvious why my request That is unfortunate that you have decided to opt out of using the MSI I've enjoyed working with Python for years and was hoping for a new MSI I guess I'll wait to see if your Windows guys have anything to add but save Your exe files all fail to execute properly, and ends up throwing the same Are you expecting users to compile the source code into a MSI installer, if If that's what it's going to take, I'll do it myself, get what I need done On Tue, Aug 8, 2017 at 2:57 PM, Steve Dower <report@bugs.python.org> wrote:
|
To be clear, Steve *is* our main Windows developer, and specifically the person who developed the Windows installers we now use. They work perfectly for many people, including myself, so there certainly isn't a general issue with them. I myself routinely install Python with the new installers on Windows 7 x64 systems, so it's definitely something specific to your system. Is your PC running a "corporate" build that might include security restrictions or other permission limitations that might be affecting the behaviour of the installer? As a workaround, Python is installable using nuget, from https://www.nuget.org/packages/python. I don't know much myself about nuget, but basically "nuget install python" will create a local copy of Python in the current directory that you can use without needing to be installed. |
Ok, it sounds like as good a solution as I can expect. No, I don't have a corporate build but I think my registry developed issues It's been a while but that is the only thing I can come up with that would Your exe isn't the only one that gives me issues but its usually a false I have tried every suggestion I have found online and nothing seems to If the problem is the registry issue that I suspect, then nothing short of I have communicated with Microsoft, who's answer was to upgrade to Windows I have two systems with python installed, both with windows 7 x64, the The closest thing I can figure is there is some permission handling that is I can't fix my system if the problem that I suspect is the culprit so my It definitely seems like that will be more successful than continuing to be From what I have been reading online, its simple enough with Visual Studio Thanks for enlightening me to the most of your abilities. It seems pretty clear that I on my own on this one. On Wed, Aug 9, 2017 at 6:10 AM, Paul Moore <report@bugs.python.org> wrote:
|
Okay, if that's the way you want to go. Be aware that the old MSI code is gone though, so rebuilding it will not be trivial. Though if you do, there are a few people who would find it more convenient, so you may be able to enlist help maintaining it (we didn't get any offers of help, just requests for free work, so you may not get it either...) If you're having trouble with a range of installers, there's a process you can run to reset your security policy, which is what I'd suggest doing. I'd have to find the details for you, but it basically resets permissions on everything. Doesn't delete any files, but may help with this problem. Let me know if you'd like me to find the details (requires Windows Pro IIRC, at least pre-Win 10). |
Steve, when we changed installers was that when we also fixed the security/permissions problems with the install dir? If permissions are the issue the OP's problem may have nothing to do with it not being msi. |
Yes, but the permissions issue here isn't the install directory - it is probably the TEMP directory or some other system restriction. It's basically impossible to tell from the logs, and I don't even know where to start asking for configuration settings to see what may be wrong. |
If you would like to keep track of others who would find it useful, I'd be Also, any information or good references that you could recommend that Steve mentioned the temp directory as possibly being part of the problem Steve also mentioned that it's not as easy to produce an installer as it On a scale of one to ten, with ten being the most difficult, how difficult From the Microsoft article on producing MSI installers, Is there something I'm not seeing or understanding in the process? Again, if you know of any references that might help educate me or direct I already have a couple strategies I'm thinking of to do this but I would -David Gentry On Thu, Aug 10, 2017 at 2:40 PM, Steve Dower <report@bugs.python.org> wrote:
|
The general requirements of an installer are:
These are all the features of our current installer, and nearly all of them work for basically every user. Many of these are literally not achievable with just an MSI, or require significantly more complicated commands to be run by the end user, rather than providing options in a user interface. If you're still interested in giving it a go, visit http://wixtoolset.org/ and have a look at their tools. These are the gold-standard right now for building MSIs (and Burn bundles, which is what we currently have). |
Thank you for the information. That will definitely be helpful. Also, thank you for being so detailed with your explanation. Even though it will be difficult and may take more time than I was Therefore, I will be trying my hand at crafting the MSI, though like you The toolset you offered should help out a lot. Thank you for all of your expert advice. I have one last question before I begin on my journey. You mentioned "burn bundles" at the end of the message. Are these something On Mon, Aug 14, 2017 at 12:55 PM, Steve Dower <report@bugs.python.org>
|
Burn bundles are part of Wix, but it's the part you don't like :) If you just want a single MSI, you won't want a bundle. But you will have to leave out nearly half of the features I listed because they simply are not possible without it. |
So basically what your saying is that the MSI that I compile will only work Hmm, that kind of sucks. Disregarding the difficulty of manually converting from source to MSI, if I I have a strategy I am considering employing to solve the problem where the Basically, I have a 5x raspberry pi 3 neural network unit that I am The problem is essentially converting the raw source code into the Is this an idea that intrigues you even slightly? Should you feel like there is something that would inherently and I just hate investing a bunch of time into a project and the code I create <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon\> On Tue, Aug 15, 2017 at 10:12 PM, Steve Dower <report@bugs.python.org>
|
The idea interests me from a theoretical point of view, but then I did my PhD in that field. I don't believe it's a practical solution, if only because you would need to manually generate the result in order to validate before releasing, and that's the step you're going to avoid. I don't think there's anything left to pursue here. Good luck with your efforts. |
I was going to update some CI that tests all supported versions of Python and pins the Python 3 versions. That CI was previously using the MSI installers for Python 3.4. To my surprise, the MSIs stopped being generated after the 3.4.4 release! https://www.python.org/ftp/python/3.4.4/ has MSIs (and MacOS .pkg files). But all subsequent releases (e.g. https://www.python.org/ftp/python/3.4.7/) do not. I'm OK with the decision to abandon MSIs and move to the .exe installer for newer Python releases (like 3.5 and 3.6). However, ceasing to produce the MSIs (and MacOS .pkg files for that matter) midway through 3.4's support cycle feels wrong to me. 3.4.4 was the last release with binary distributions for Windows and MacOS. 3.4.5 and newer releases have fixes to security issues. That means people using the binary distributions of 3.4 on these platforms are stuck on 3.4.4 and are thus vulnerable to known security issues. That's... not great. I think the MSI (and .pkg) distributions should be restored for 3.4. Furthermore, I would encourage Python to adopt the practice that distribution mechanisms aren't modified during a Python version's support cycle. Someone will inevitably rely on any distribution format that is published. And taking it away in a support cycle will orphan those users on an old, buggy release. |
It is standard procedure for us to stop producing binary releases when a version switches to security-only mode. The burden on our volunteers would become overwhelming otherwise. If you'd like to propose a change to this policy, start by posting on python-list, and then if there is general support someone there will bring the conversation to the development team. Resurrecting old bugs is not an efficient way to request this kind of change. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: