Related
up until recently I have only worked with one version of Python and used virtual environments every now and then. Now, I am working with some libraries that require older version of Python. So, I am very confused. Could anyone please clear up some of my confusion?
How do I install multiple Python versions?
I initially had Python version 3.8.x but upgraded to 3.10.x last month. There is currently only that one version on my PC now.
I wanted to install one of the Python 3.8.x version and went to https://www.python.org/downloads/. It lists a lot of versions and subversions like 3.6, 3.7, 3.8 etc. etc. with 3.8.1, 3.8.2 till 3.8.13. Which one should I pick?
I actually went ahead with 3.8.12 and downloaded the Tarball on the page: https://www.python.org/downloads/release/python-3812/
I extracted the tarball (23.6MB) and it created a folder with a setup.py file.
Is Python 3.8.12 now installed? Clicking on the setup.py file simply flashes the terminal for a second.
I have a few more questions. Hopefully, they won't get me downvoted. I am just confused and couldn't find proper answers for them.
Why does Python have such heavy dependency on the exact versions of libraries and packages etc?
For example, this question
How can I run Mozilla TTS/Coqui TTS training with CUDA on a Windows system?. This seems very beginner unfriendly. Slightly mismatched package
version can prevent any program from running.
Do virtual environments copy all the files from the main Python installation to create a virtual environment and then install specific packages inside it? Isn't that a lot of wasted resources in duplication because almost all projects require there own virtual environment.
Your questions depend a bit on "all the other software". For example, as #leiyang indicated, the answer will be different if you use conda vs just pip on vanilla CPython (the standard Windows Python).
I'm also going to assume you're actually on Windows, because on Linux I would recommend looking at pyenv. There is a pyenv-win, which may be worth looking into, but I don't use it myself because it doesn't play as nice if you also want (mini)conda environments.
1. (a) How do I install multiple Python versions?
Simply download the various installers and install them in sensible locations. E.g. "C:\Program Files\Python39" for Python 3.9, or some other location where you're allowed to install software.
Don't have Python add itself to the PATH though, since that'll only find the last version to do so and can really confuse things.
Also, you probably want to use virtual environments consistently, as this ties a specific project very clearly to a specific Python version, avoiding future confusion or problems.
1. (b) "3.8.1, 3.8.2 till 3.8.13" which should I pick?
Always pick the latest 3.x.y, so if there's a 3.8.13 for Windows, but no 3.8.14, pick that. Check if the version is actually available for your operating system, sometimes there are later versions for one OS, but not for another.
The reason is that between a verion like 3.6 and 3.7, there may be major changes that change how Python works. Generally, there will be backwards compatibility, but some changes may break how some of your packages work. However, when going up a minor version, there won't be any such breaking changes, just fixes and additions that don't get in the way of what was already there. A change from 2.x to 3.x only happens if the language itself goes through a major change, and rarely happens (and perhaps never will again, depending on who you ask).
An exception to the "no minor version change problems" is of course if you run some script that very specifically relies on something that was broken in 3.8.6, but no fixed in 3.8.7+ (as an example). However, that's very bad coding, to rely on what's broken and not fixing it later, so only go along with that if you have no other recourse. Otherwise, just the latest minor version of any version you're after.
Also: make sure you pick the correct architecture. If there's no specific requirement, just pick 64-bit, but if your script needs to interact with other installed software at the binary level, it may require you to install 32-bit Python (and 32-bit packages as well). If you have no such requirement, 64-bit allows more memory access and has some other benefits on modern computers.
2. Why does Python have such heavy dependency on the exact versions of libraries and packages etc?
It's not just Python, this is true for many languages. It's just more visible to the end user for Python, because you run it as an interpreted language. It's only compiled at the very last moment, on the computer it's running on.
This has the advantage that the code can run on a variety of computers and operating systems, but the downside that you need the right environment where you're running it. For people who code in languages like C++, they have to deal with this problem when they're coding, but target a much smaller number of environments (although there's still runtimes to contend with, and DirectX versions, etc.). Other languages just roll everything up into the program that's being distributed, while a Python script by itself can be tiny. It's a design choice.
There are a lot of tools to help you automate the process though and well-written packages will make the process quite painless. If you feel Python is very shakey when it comes to this, that's probable to blame on the packages or scripts you're using, not really the language. The only fault of the language is that it makes it very easy for developers to make such a mess for you and make your life hard with getting specific requirements.
Look for alternatives, but if you can't avoid using a specific script or package, once you figure out how to install or use it, document it or better yet, automate it so you don't have to think about it again.
3. Do virtual environments copy all the files from the main Python installation to create a virtual environment and then install specific packages inside it? Isn't that a lot of wasted resources in duplication because almost all projects require there own virtual environment.
Not all of them, but quite a few of them. However, you still need the original installation to be present on the system. Also, you can't pick up a virtual environment and put it somewhere else, not even on the same PC without some careful changes (often better to just recreate it).
You're right that this is a bit wasteful - but this is a difficult choice.
Either Python would be even more complicated, having to manage many different version of packages in a single environment (Java developers will be able to tell you war stories about this, with their dependency management - or wax lyrically about it, once they get it themselves).
Or you get what we have: a bit wasteful, but in the end diskspace is a lot cheaper than your time. And unlike your time, diskspace is almost infinitely expandable.
You can share virtual environments between very similar projects though, but especially if you get your code from someone else, it's best to not have to worry and just give up a few dozen MB for the project. On the upside: you can just delete a virtual environment directory and that pretty much gets rid of the whole things. Some applications like PyCharm may remember that it was once there, but other than that, that's the virtual environment gone.
Just install them. You can have any number of Python installations side by side. Unless you need to have 2 different minor versions, for example 3.10.1 and 3.10.2, there is no need to do anything special. (And if you do need that then you don't need any advice.) Just set up separate shortcuts for each one.
Remember you have to install any 3rd-party libraries you need in each version. To do this, navigate to the Scripts folder in the version you want to do the install in, and run pip from that folder.
Python's 3rd-party libraries are open-source and come from projects that have release schedules that don't necessarily coincide with Python's. So they will not always have a version available that coincides with the latest version of Python.
Often you can get around this by downloading unofficial binaries from Christoph Gohlke's site. Google Python Gohlke.
Install Python using the windows executable installers from python.org. If the version is 3.x.y, use the highest y that has a windows executable installer. Unless your machine is very old, use the 64-bit versions. Do not have them add python to your PATH environment variable, but in only one of the installs have it install the python launcher py. That will help you in using multiple versions. See e.g. here.
Python itself does not. But some modules/libraries do. Especially those that are not purely written in Python but contain extensions written in C(++). The reason for this is that compiling programs on ms-windows can be a real PITA. Unlike UNIX-like operating systems with Linux, ms-windows doesn't come with development tools as standard. Nor does it have decent package management. Since the official Python installers are built with microsoft tools, you need to use those with C(++) extensions as well. Before 2015, you even had to use exactly the same version of the compiler that Python was built with. That is still a good idea, but no longer strictly necessary. So it is a signigicant amount of work for developers to release binary packages for each supported Python version. It is much easier for them to say "requires Python 3.x".
msiexec is command prompt software that installs an MSI program. But I have found that you can install an MSI file from the command line by just typing in the name of the MSI file on the command line.
But in order to uninstall the MSI file, it seems you have to call the msiexec program and give it a /x or /uninstall.
How can I uninstall an MSI from the command line without using the msiexec routine?
Express Options:
Uninstall by Product GUID: (find product GUID) - section 3 below for logging. There is also: MSI logging in depth here:
msiexec.exe /x {11111111-1111-1111-1111-11111111111X}
Uninstall by MSI file:
msiexec.exe /x "c:\filename.msi"
Express Interactive:
Right click MSI file in Windows Explorer and select "Uninstall".
There are many ways to uninstall an MSI package. The below is intended as a "reference":
In summary you can uninstall via: msiexec.exe, ARP, WMI, PowerShell, Deployment Systems such as SCCM, VBScript / COM Automation, DTF, or via hidden Windows cache folder, and a few other options presented below.
The first few paragraphs provide important MSI tidbits, then there are 14 sections with different ways to uninstall an MSI file. Puh.
"Babble, Babble - Over": Sections 1, 2 and 3 are the normal uninstall approaches (and hence recommended). Personally I use option 3 or 5 from section 3 (both options with logging, but option 5 runs silently
as well). If you are very busy, skip all the babble and go for one
of these - it will get the job done.
If you have problems uninstalling altogether and are looking for an alternative to the deprecated MsiZap.exe and / or Windows Installer CleanUp Utility (MSICUU2.exe), you can try the new FixIt tool from Microsoft (or the international page). May apparently work for other install issues as well.
Newer list of cleanup approaches: Cleaning out broken MSI uninstalls.
If you think MSI and Windows Installer is more trouble than it's worth, you might want to read about the corporate benefits of using MSI files.
Installscript MSI setups generally come wrapped in a setup.exe file. To read more about the parameters to use for uninstalling such setups please see these links: setup.exe pdf reference sheet, Setup.exe and Update.exe Command-Line Parameters.
Some MSI files are installed as part of bundles via mechanism such as Burn (WiX Toolkit) or InstallShield Suite projects. This can make uninstall slightly different from what is seen below. Here is an example for InstallShield Suite projects.
Be aware that running uninstall silently or interactively can cause different results (!). For a rather lengthy description of why this is the case, please read this post: Uninstall from Control Panel is different from Remove from .msi
If you are unexpectedly asked for the original installation media when trying to uninstall, please read this answer: Why does MSI require the original .msi file to proceed with an uninstall? and perhaps also section 12 below for some important technical details.
If you got CCleaner or similar cleanup tools installed, perhaps jump to section 11.
If uninstall is failing entirely (not possible to run), see sections 12 & 13 below for a potential way to "undo" the installation using system restore and / or cleanup tools.
1 - Using the original MSI
If you have access to the original MSI used for the installation, you can simply right click it in Windows Explorer and select Uninstall.
You can also uninstall via command line as explained in section 3.
2 - Using the old ARP Applet OR new Windows 8/10 Settings Interface
Just got to mention the normal approach(es) though it is obvious
ARP = Add / Remove Programs Applet (appwiz.cpl)
Windows 10 Settings Interface => New shell for same operation
ARP:
Go start → run → appwiz.cpl → ENTER in order to open the add/remove programs applet (or click add/ remove programs in the control panel)
Click "Remove" for the product you want to uninstall
Settings Interface (Windows 8 / 10):
Use the new Settings GUI in Windows 8 / 10
Windows Key + Tap I => Apps & Features. Select entry and uninstall.
Direct shortcut:
Windows Key + Tap R => Type: ms-settings:appsfeatures and press Enter
Some reports of errors when invoking uninstall this way. Please add comments below if seen.
Try this answer as well
General hint: try disabling anti-virus and try again.
3 - Using msiexec.exe command line (directly or via a batch file)
You can uninstall via the command prompt (cmd.exe), batch file or or even from within an executable as a shell operation.
You do this by passing the product GUID (check below for how to find this GUID) or the path to the original MSI file, if available, to msiexec.exe.
For all the command lines below you can add /qn to make the uninstall run in silent mode. This is how an uninstall runs when triggered from the add/remove applet.
Option 3.1: Basic interactive uninstall (access to original MSI file):
msiexec.exe /x "c:\filename.msi"
Option 3.2: Basic interactive uninstall via product GUID (no access to original MSI file - here is how to find the product GUID - same link as below):
msiexec.exe /x {11111111-1111-1111-1111-11111111111X}
Option 3.3: Interactive uninstall with verbose log file:
msiexec.exe /x "c:\filename.msi" /L*V "C:\msilog.log"
msiexec.exe /x {11111111-1111-1111-1111-11111111111X} /L*V "C:\msilog.log"
Option 3.4: Interactive uninstall with flushed, verbose log file (verbose, flush to log option - write log continuously, can be very slow):
msiexec.exe /x "c:\filename.msi" /L*V! "C:\msilog.log"
msiexec.exe /x {11111111-1111-1111-1111-11111111111X} /L*V! "C:\msilog.log"
The flush to log option makes the uninstall slow because the log file is written continuously instead of in batches. This ensures no log-buffer is lost if the setup crashes.
In other words, enable this option if your setup is crashing and there is no helpful information in your verbose log file. Remove the exclamation mark to turn off the flush to log option and the uninstall will be much quicker. You still get verbose logging, but as stated some log buffer could be lost.
Option 3.5 (recommended): Silent uninstall with verbose log file - suppress reboots (no flush to log - see previous option for what this means):
msiexec.exe /x "c:\filename.msi" /QN /L*V "C:\msilog.log" REBOOT=R
msiexec.exe /x {11111111-1111-1111-1111-11111111111X} /QN /L*V "C:\msilog.log" REBOOT=R
Quick Parameter Explanation (since I recommend this option):
/X = run uninstall sequence
/QN = run completely silently
/L*V "C:\msilog.log"= verbose logging at path specified
{11111111-1111-1111-1111-11111111111X} = product guid of app to uninstall
REBOOT=R = prevent unexpected reboot of computer
Again, how to find the product guid:
How can I find the product GUID of an installed MSI setup? (for uninstall if you don't have the original MSI to specify in the uninstall command).
Top tip: If you create a log file for your uninstall, you can locate problems in the log by searching for "value 3". This is particularly useful for verbose files, because they are so, well, verbose :-).
How to find the product GUID for an installed MSI?
There are several ways, my recommended way is using Powershell: How can I find the product GUID of an installed MSI setup?
Several other ways described here (registry, local cache folder, etc...): Find GUID From MSI File
More information on logging from installsite.org: How do I create a log file of my installation? - great overview of different options and also specifics of InstallShield logging.
Msiexec (command-line options) - overview of the command line for msiexec.exe from MSDN. Here is the Technet version.
4 - Using the cached MSI database in the super hidden cache folder
MSI strips out all cabs (older Windows versions) and caches each MSI installed in a super-hidden system folder at %SystemRoot%\Installer (you need to show hidden files to see it).
NB: This supper-hidden folder is now being treated differently in Windows 7 onwards. MSI files are now cached full-size. Read the linked thread for more details - recommended read for anyone who finds this answer and fiddles with dangerous Windows settings.
Avoid these huge cached files by using admin installations. On the topic of disk space: How can I get rid of huge cached MSI files (and other disk space cleanup tricks).
All the MSI files here will have a random name (hex format) assigned, but you can get information about each MSI by showing the Windows Explorer status bar (View -> Status Bar) and then selecting an MSI. The summary stream from the MSI will be visible at the bottom of the Windows Explorer window. Or as Christopher Galpin points out, turn on the "Comments" column in Windows Explorer and select the MSI file (see this article for how to do this).
Short answer on using Windows Explorer
Once you find the right MSI, just right click it and go Uninstall.
You can also use PowerShell to show the full path to the locally cached package along with the product name. This is the easiest option in my opinion.
To fire up PowerShell: hold down the Windows key, tap R, release the Windows key, type in "powershell" and press OK. Then maximize the PowerShell window and run the command below:
get-wmiobject Win32_Product | Format-Table Name, LocalPackage -AutoSize
Also see this answer: How can I find the product GUID of an installed MSI setup?
5 - Using PowerShell
There is a similar, but more comprehensive PowerShell script available on MSDN. It allows uninstall to be run on several machines.
Entry added by Even Mien:
$app = Get-WmiObject -Class Win32_Product -Filter "Name = 'YOUR_APP'"
$app.Uninstall()
This approach will work, but accessing the WMI class Win32_Product will trigger a software consistency check which is very slow and in special circumstances it can cause an MSI self-repair to be triggered. See this article: Powershell Uninstall Script - Have a real headache
I have not tested this myself, but it appears $app.Uninstall() may run the UninstallString registered in the ARP applet's registry settings. This means it may run modify instead of uninstall in some cases.
Check this topic for more details and ways to uninstall via Powershell: How can I uninstall an application using PowerShell?
6 - Using the .NET DTF Class Library (part of the WiX toolkit)
This option is included for developers getting into deployment and MSI - it is not really practical as a "quick fix". It requires that you download the WiX toolkit - a free framework for creating MSI files compiled from XML source file(s).
A quick blurb on WiX and its "history": Windows Installer and the creation of WiX. And here is WiX contrasted with other deployment tools (commercial) - (strengths and weaknesses - hopefully as objective as possible).
DTF (Deployment Tools Foundation) is distributed as part of WiX as explained here: Is source-code for Deployment Tools Foundation available?.
DTF is essentially a .NET wrapper for the Win32 Windows Installer API. It eliminates all need for COM Interop when working with Windows Installer via automation and is nothing short of a .NET jewel - perhaps the easiest-to-use .NET library I have ever seen. Highly recommended - great even for training students in C#.
The following source from MSI expert Christopher Painter using C# and DTF. Microsoft.Deployment.WindowsInstaller is one of the DTF assemblies. See the other assemblies explained here on serverfault.com:
using Microsoft.Deployment.WindowsInstaller;
public static void Uninstall( string productCode)
{
Installer.ConfigureProduct(productCode, 0, InstallState.Absent, "REBOOT=\"R\"");
}
Anther alternative from Tom Blodget: Checking for successful uninstall
More information on msiexec.exe versus automation on: serverfault.com.
7 - Using the Windows Installer Automation API
Here is a community discussion of this option: Windows Installer Automation API community sample
The API can be accessed via script automation and C++ API calls (my post on serverfault.com)
The following source adapted from MSI expert Christopher Painter using VBScript:
Set installer = CreateObject("WindowsInstaller.Installer")
installer.InstallProduct "product.msi", "REMOVE=ALL REBOOT=ReallySuppress"
Set installer = Nothing
Here is another VBScript for uninstalling by GUID from Symantec: http://www.symantec.com/connect/downloads/uninstall-application-using-guid-registry
Uninstall via upgrade code & ConfigureProduct.
8 - Using a Windows Installer major upgrade
A Windows Installer major upgrade may happen as part of the installation of another MSI file.
A major upgrade is authored by identifying related products in the MSI's "Upgrade table". These related setups are then handled as specified in the table. Generally that means they are uninstalled, but the main setup can also be aborted instead (typically used to detect higher versions of your own application present on the box).
9 - Using Deployment Systems / Remote Administration Systems
SCCM, CA Unicenter, IBM's Tivoli, Altiris Client Management Suite, and several others
These tools feature advanced client PC management, and this includes the install and uninstall of MSI files
These tools seem to use a combination of msiexec.exe, automation, WMI, etc... and even their own way of invoking installs and uninstalls.
In my experience these tools feature a lot of "personality" and you need to adapt to their different ways of doing things.
10 - Using WMI - Windows Management Instrumentation
Adding just for completeness. It is not recommended to use this approach since it is very slow
A software consistency check is triggered every time Win32_Product is called of each installation
The consistency check is incredibly slow, and it may also trigger a software repair. See this article: Powershell Uninstall Script - Have a real headache
Even worse, some people report their event logs filling up with MsiInstaller EventID 1035 entries - apparently caused by WMI queries to the Win32_Product class (personally I have never seen this).
The WMICodeCreator.exe code creation tool can be used to experiment
Install can be invoked via Win32_Product.Install
Uninstall can be invoked via Win32_Product.Uninstall
MSDN sample: Uninstall method of the Win32_Product class
11 - Using a third-party tool such as ccleaner or similar
Several Windows applications feature their own interface for uninstalling not just MSI packages, but legacy installers too.
I don't want to make any specific tool recommendations here (especially commercial ones), but the well known CCleaner features such an uninstall interface (and it has a free version). I should also add that this tool suffered a malware attack recently.
I guess we should all remember that even harmless software can be injected with malware in their download locations (FTP attack).
I use virustotal.com to check my downloads, and also Sysinternals Process Explorer to check running processes after installation - along with regular security software (whichever is available).
A surprising amount of "gray area" software is usually found with this approach (toolbars, smileys, adware, etc...), along with several false positives (they can also cause problems as security software block their access or quarantines them making a lot of fuzz). And certainly real malware as well.
Some usage tips for Process Explorer can be found here - a series of tweets - this Process Explorer tool hooks up to VirusTotal.com to check all running processes interactively - all you need is a few configuration steps.
I should note that Process Explorer yields a file signature check, but no heuristics - as far as I understand (no check for suspicious operations, just a check with 60+ security suites for flagged files). You need a regular security tool for interactive, online heuristic protection.
For what it is worth, I think some security software border on causing more false-positive problems than malware does damage. Famous last words in the era of ransom-ware...
That is a large enough digression - I just don't want to see people download malware. Do your virustotal.com check at least.
Uninstalling like this should work OK. I think these tools mess with too many things when you try their "cleanup features" though. Use with caution. If you only use the uninstall feature, you should be OK.
12 - Using a cleanup tool such as msizap or similar
For completeness msizap.exe should be mentioned though it is deprecated, unsupported and outdated. It should not be used on any newer Windows versions
This command line tool (msizap.exe) also had a GUI available (MSICUU2.exe). Both tools are deprectated.
The intended use of these tools was to clean out failing uninstalls:
Generally for the rare case when the cached MSI with the random name is erroneously missing and uninstall fails for this reason whilst asking for the original MSI. This is a rare problem, but I have seen it myself. Just a few potential causes: Moved to this answer.
Key words: system restore interference, bad cleanup apps, msiexec.exe crashing, power outage, security software interference, MSI development debugging blunders (identical package codes, etc...), user tinkering and hacking (what is in here? save space?), etc...
It could also be used to zap any MSI installation, though that is obviously not advisable.
More information: Why does MSI require the original .msi file to proceed with an uninstall?
This newer support tool (this tool is now also deprecated) can be tried on recent Windows versions if you have defunct MSI packages needing uninstall.
Some have suggested to use the tool linked to here by saschabeaumont: Uninstall without an MSI file. If you try it and it works, please be sure to let us know.
If you have access to the original MSI that was actually used to install the product, you can use this to run the uninstall. It must be the exact MSI that was used, and not just a similar one.
13 - Using system restore ("installation undo" - last resort IMHO)
This is strictly speaking not a way to "uninstall" but to "undo" the last install, or several installs for that matter.
Restoring via a restore point brings the system back to a previous installation state (you can find video demos of this on YouTube or a similar site).
Note that the feature can be disabled entirely or partly - it is possible to disable permanently for the whole machine, or adhoc per install.
I have seen new, unsolvable installation problems resulting from a system restore, but normally it works OK. Obviously don't use the feature for fun. It's a last resort and is best used for rollback of new drivers or setups that have just been installed and are found to cause immediate problems (bluescreen, reboots, instability, etc...).
The longer you go back the more rework you will create for yourself, and the higher the risk will be. Most systems feature only a few restore points, and most of them stretch back just a month or two I believe.
Be aware that system restore might affect Windows Updates that must then be re-applied - as well as many other system settings. Beyond pure annoyances, this can also cause security issues to resurface and you might want to run a specific security check on the target box(es) using Microsoft Baseline Security Analyzer or similar tools.
Since I mentioned system restore I suppose I should mention the Last Known Good Configuration feature. This feature has nothing to do with uninstall or system restore, but it is the last boot configuration that worked or resulted in a running system. It can be used to get your system running again if it bluescreens or halts during booting. This often happens after driver installs.
14 - Windows Installer Functions (C++)
For completeness I guess we should mention the core of it all - the down-to-the-metal way: the Win32 Windows Installer API functions. These are likely the functions used by most, if not all of the other approaches listed above "under the hood". They are primarily used by applications or solutions dealing directly with MSI as a technology.
There is an answer on serverfault.com which may be of interest as a summary of the different programmatic approaches for uninstalling (COM Automation, .NET, Win32 installer functions).
Below you will find a C++ snippet showing how to uninstall Orca, 10.1.17134.12 by product code using a call to the MsiConfigureProductEx function. To uninstall another product replace the GUID specified for prodcode with the one for your product. To find the product code see this answer: How can I find the product GUID of an installed MSI setup?
The uninstall will happen in full GUI mode. To run in silent mode or some other GUI mode (reduced, basic, etc...), please see the: MsiSetInternalUI function.
#include "pch.h"
#define WIN32_LEAN_AND_MEAN //Minimize includes from Windows.h
#include <windows.h>
#include <msi.h> // Windows Installer
#include <tchar.h>
#pragma comment(lib, "msi.lib") // To make code link
int main()
{
const TCHAR noreboot[] = _T("REBOOT=ReallySuppress");
const TCHAR prodcode[39] = _T("{D7B80ABC-1950-37B8-F851-C3783EED9C93}"); // Orca, 10.1.17134.12
UINT res = MsiConfigureProductEx(prodcode, INSTALLLEVEL_DEFAULT, INSTALLSTATE_ABSENT, noreboot);
return res; // Error Codes: https://msdn.microsoft.com/en-us/library/windows/desktop/aa376931(v=vs.85).aspx
}
The snippet was made and tested with the latest version of Visual Studio 2017 as of September 2018:
Create a new "Windows Console Application" from Visual C++ => Windows Desktop.
Copy and paste the above code into your main CPP file (replacing whatever is there).
That should be it to be able to run the code. Maybe set a breakpoint, build and run.
Beware of changes to the default templates in VS2017, and the weird errors that can result: There are too many errors for the IntelliSense engine to function correctly.
UPDATE September 2018: Templates have changed again. I no longer see the above issue.
The MSDN link in the code lists the possible error messages returned from msiexec.exe.
Short answer: you can't. Use MSIEXEC /x
Long answer: When you run the MSI file directly at the command line, all that's happening is that it runs MSIEXEC for you. This association is stored in the registry. You can see a list of associations by (in Windows Explorer) going to Tools / Folder Options / File Types.
For example, you can run a .DOC file from the command line, and WordPad or WinWord will open it for you.
If you look in the registry under HKEY_CLASSES_ROOT\.msi, you'll see that .MSI files are associated with the ProgID "Msi.Package". If you look in HKEY_CLASSES_ROOT\Msi.Package\shell\Open\command, you'll see the command line that Windows actually uses when you "run" a .MSI file.
Also remember that an uninstall can be initiated using the WMIC command:
wmic product get name --> This will list the names of all installed apps
wmic product where name='myappsname' call uninstall --> this will uninstall the app.
The msi file extension is mapped to msiexec (same way typing a .txt filename on a command prompt launches Notepad/default .txt file handler to display the file).
Thus typing in a filename with an .msi extension really runs msiexec with the MSI file as argument and takes the default action, install. For that reason, uninstalling requires you to invoke msiexec with uninstall switch to unstall it.
wmic product get name
Just gets the cmd stuck... still flashing _ after a couple minutes
in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, if you can find the folder with the software name you are trying to install (not the one named with ProductCode), the UninstallString points to the application's own uninstaller C:\Program Files\Zune\ZuneSetup.exe /x
I would try the following syntax - it works for me.
msiexec /x filename.msi /q
The OP did say "without using msiexec." Nowadays winget (standard on modern 10 and 11) can install and uninstall from the command line. Check it out.
I'm assuming that when you type int file.msi into the command line, Windows is automatically calling msiexec file.msi for you. I'm assuming this because when you type in picture.png it brings up the default picture viewer.
I have just acquired a stand alone PC running XP, and I do not want to connect to the internet. I am running python 2.7 on my laptop and was wondering if there was a way to install the python.exe file to a flash drive so I can install python 2.7 on the stand alone. The download from the python.org website goes straight to the path in my c drive, and will not let me save it to the flash drive. I have tried installing from active state, and I am unable to use this as it is not win32. Any help will be much appreciated.
You can download python's zip file then unzip it onto your flash drive, here's the link for the latest release of python 3.6.1 with win32 including all the components that python is required to run as well as the python.exe that you wanted:
https://www.python.org/ftp/python/3.6.1/python-3.6.1-embed-win32.zip
Here's the link to the downloads page, if you wanted another version of python, look for Download Windows x86 embeddable zip file.
If you want a clean, standard CPython installation without bells and whistles on your offline Windows XP machine, you can use your flash drive to transport a Python 2.7 installer from python.org to your Windows XP machine's local hard drive, and then run the installer from there. It could be somewhere between inconvenient and difficult to install third-party packages (as you would find on PyPI) without the full benefit of pip. (Depending on the specific packages you want, you may be able to transport installers or wheels and still use pip in offline mode, without automatic dependency installation.)
If you want a full-featured but potentially big "portable" installation that you can just plop into any directory and use from there, you can try an old version of Portable Python (the project is defunct but the download page is still up as of this writing) or WinPython (note that this answer suggests sticking with 2.7.9 or earlier).
I have compiled a PyXMLSec lib successful on Ubuntu. I want to create a windows-installer for this lib (i.e PyXMLSec-win32-python27.exe). Can I create it from my Ubuntu or it must be from Win32? How can I create it? I prefer from Ubuntu because in Windows, I have some bugs.
Thanks.
You should build and test the installer on Windows. (If you don't test it on Windows, you don't know it works on Windows.)
The commonly used free installation software products used for making Windows installers typically include Wix and Inno Setup. For ease of use, I prefer Inno Setup; it has some free GUIs (linked to from the site itself) for creating the setup scripts used to build the installer, is pretty flexible without any custom work on your part, and easily extendable using it's built-in Object Pascal-based scripting language.
Wix, however, supports building MSI-based installers that use Windows Installer. MSI installs are often required by corporate network administrators because they allow pushing the installation out to computers in the network domain easily. It's harder to work with unless you're pretty familiar with it, so it may not be suitable for a one-off installer requirement like you seem to need.
I want to make an installation file for my python source code"
You have to use NSIS, InnoSetup, BitRock Installer, IzPack or equivalent to produce a platform installer. So you have to take the binary result produced on the first part and package it for os distribution. Almost all the installer systems are thinked for Windows systems. Cross platform : Zero Install, IzPack ... If you use IzPack you can have a cross platform installer paying the price of including a jvm.
And i Believe This >> HELP Can be Light of Your Way ;)
Have a look at the documentation for Build Distribution:
python setup.py bdist --format=msi
I have reinstalled my operating system (moved from windows XP to Windows 7).
I have reinstalled Python 2.7.
But i had a lot of packages installed in my old environment.
(Django, sciPy, jinja2, matplotlib, numpy, networkx, to name just a view)
I still have my old Python installation lying around on a data partition, so i wondered if i can just copy-paste the old Python library folders onto the new installation?
Or do i need to reinstall every package?
Do the packages keep any information in registry, system variables or similar?
Does it depend on the package?
That's the point where you must be able to layout your project, thus having special tools for that.
Normally, Python packages do not do such wierd things as dealing with registry (unless they are packaged via MSI installer). The problems may start with packages that contain C extensions, so moving to another version of OS or from 32 to 64-bit architecture will require recompiling/rebuilding of those. So, it would be much better to reinstall all packages to new system as written below.
Your demands may vary, but you definitely must choose the way of building your environment. If you don't have and plan to have a large variety of projects you may consider the first approach as follows below, the second approach is more likely for setting up development environment for different projects or for different versions of the same project.
Global environment (your Python installation in your system along with installed packages).
Here you can consider using pip. In this case your project can have requirements file containing all needed packages for your project. Basically, requirements file is a text file containing package names (on PyPI and their versions).
Isolated environment. It can be achieved using special tools or specially organized path.
Here where pip can be gracefully combined with virtualenv. This way is highly recommended by a lot of developers (I must remind that Python 3.3 that will soon be released contains virtualenv as a part of standard library). This approach assumes creating virtual shell with its own instance of Python interpreter and installed packages.
Another popular tool for achieving isolated environment is called buildout. It lays out your project source and dependencies in one path so you achieve the same effect as virtualenv creates. The great advantage of buildout that it's built upon an idea of pluggable recipes (pieces of code implementing different common project deployment tasks) and there are hundreds of stable and reliable recipes over Internet.
Both virtualenv and buildout help you to remove head-ache when installing dependencies and solve the problem of different versions of the same package kept on a single machine.
Choose your destiny...
The short answer to this question is "no", since packages can execute arbitrary code on installation and do whatever the heck they want wherever they want on your system.
Just reinstall all of them.