From: "Greg Ward" <gward@python.net>
(When someone can download Zope and run "python setup.py install", and setup.py is a reasonably normal Distutils-style setup script, then I will hang up my keyboard and go home.) Does not sound impossible, because: Zope is not more than some python-modules and some c-extensions. Well, python itself is also included (on Windows, have to check this on unix). Mark Hammonds win32all extensions are more of a challange (but that would not interest YOU very much, until they are ported to *nix ;-)
A few questions/comments:
* the default installation directory should obviously be where Python will find it: sys.prefix. So you'll either have to run "python -c 'import sys; print sys.prefix'" or get this information from the registry. I'm guessing the latter is preferable and doable -- as long as you can put arbitrary code into the self-extractor. I think it should use the python installation directory from the registry. How should the installer find python otherwise?
* what if there are multiple Python installations -- are they sufficiently differentiated in the registry? Eg. I might have Python 1.5.2 and 1.6a2 installed, and I would have to choose which one to install to.
Would read the registry entries and ask the user which version to use. If this is possible at all: .pyc files or compiled c-extensions are specific to the python version (Not necessarily for pyc files, but see the current discussion on python-dev). Probably the default should be the python version used to build the installation. Question: The installer should probably compile the .py files to .pyc/.pyo? If this has to be done, we have no other choice than to embed (or call) python.
What if it's a question of 1.6a1 vs 1.6a2 -- are Python's registry entries sufficently fine-grained to resolve this?
No. Registry entries are for 1.5 or 1.6.
* should we allow writing to a different directory than the default (sys.prefix)? (This would require writing a .pth file in sys.prefix.) Or is this getting too close to a "real" installer?
Not complicated.
* how would the actual installer be created? I'm hoping that the CCompiler abstraction would be good enough -- just create yourself a CCompiler (which could be a MSVCCompiler, BCCompiler, Mingw32CCompiler, ...) object, compile a few things, and link an executable.
build_wininst will NOT generate c-code needed to be compiled.
* interesting data point/existence proof: the Java installer- generator InstallAnywhere let me create an executable Windows installer *entirely* on my Solaris box -- I think it carries around a "stub" executable, and somehow generates the real executable by munging it with my Java code (and other stuff to install). Needless to say, this is *very* cool; it is also an incredibly fat, slow, and heavyweight product. If you can let me generate Windows installers under Solaris or Linux, I'll buy you *two* beers at the next Python conference. (I already owe you one.) ;-)
Yes, I'm heading in this direction. build_wininst will certainly append metadata and files to be installed to a prebuilt stub program. Thomas