[Python-Dev] New Windows installer for Python 3.5

Steve Dower Steve.Dower at microsoft.com
Sat Jan 10 01:09:48 CET 2015

David Anthoff wrote:
> It would be great if the new installer supported silent, portable installs.
> What I have in mind is a silent installation that drops all the necessary files
> for a working python into a folder, but does not put ANY file anywhere else and
> does not register anything anywhere on the system. So no PATH modification, no
> registering of this install as one of the available python interpreters, no
> uninstall entry or anything like that. By "all the necessary files" I mean that
> it drops things like the MSVC runtime dlls etc into that folder into which I'm
> installing python, but again doesn't try to install things like that system or
> even user wide.
> I'll give you my very specific use-case, but I think this might be useful for
> others as well: we are trying to build an installer for some other product X
> that internally requires a python instance to work. This python instance should
> NOT be visible to anything other than product X, i.e. no user should ever start
> it directly or anything like that, it really is an implementation detail of
> product X. If we had an official python installer that supported silent,
> portable installs, I could just call that python installer inside the setup
> program for X, and it would drop a fully working python installation into a
> sub-directory of the install directory of product X. And we would be happy :)

I'll look into this, but it probably isn't going to work as part of the installer. I have previously looked into being able to install arbitrary side-by-side copies of Python, but that's near impossible as well. Windows Installer doesn't really let you just copy files - it isn't part of its intended functionality. It isn't too difficult to build custom MSIs with certain parts of Python (such as the DLLs and the standard library, but no docs, headers or EXEs) in a way that won't conflict with other installs, but you're still using an MSI here which is not necessarily ideal.

The easiest way is still going to be to install a copy of Python without administrative privileges, which *currently* will drop all the files you want into the main install path (wherever you customise that to be), and then copy them directly into your installer, but that may change depending on the redistribution requirements of the CRT. There are still limitations within Python itself that would be nice to fix, such as looking at the registry too soon when it could resolve directories relative to its own location, but these are independent from the installer. If you don't need python.exe, then it should be fine as long as you put pythonXY.dll alongside the executable loading it (otherwise a system version may take priority).

As you can see, this is a fairly deep hole with lots of caveats :)

We could release a ZIP file containing all the Python files. The only reason I hesitate on this is that it could cause significant confusion for someone who doesn't really understand the implications, while people like yourself who have thought about this are also capable of finding workarounds and don't really need the ZIP file apart from convenience. Making some of the fixes to make python.exe more portable would relieve my concerns here.

> The old MSI installer sort of had something like that with the MSI
> administrative install option. But it never really worked because the
> administrative install didn't drop the MSVC runtime dlls anywhere, as far as I
> could tell. At some point I hacked around that by modifying the MSI file in my
> setup program to also drop the MSVC runtime dlls, but that was VERY hacky...

I'm a little surprised that worked at all for what you were trying to do. You'd be better off installing it once and then copying the files yourself. 

But overall, this is the sort of thing I do want to enable. I firmly believe that Python from python.org is for *developers*, and those who just want to run a Python application should be able to get a complete package. This is very different from the *nix approach, but it makes far more sense to Windows users. A good example is TortoiseHg, which bundles everything so that users never even know they have Python 2.7 or Mercurial installed on their machine. Making it easier for people to bundle Python into their own applications is a good thing, as far as I'm concerned.


> Thanks,
> David

More information about the Python-Dev mailing list