On 25 May 2000, Thomas Heller said:
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).
And the Linux kernel is some C files. ;-) (BTW, I believe Unix binary distributions include Python, but I've only built Zope from source.)
Mark Hammonds win32all extensions are more of a challange (but that would not interest YOU very much, until they are ported to *nix ;-)
Ahh, I hadn't thought about Mark's stuff. You're right, must be my Unix bias.
I think it should use the python installation directory from the registry. How should the installer find python otherwise?
Good point. My understanding is that we can assume "installation directory from the registry" == sys.prefix always. True?
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).
Oohh, ick! That affects *all* built distributions -- RPMs, Debian packages, FreeBSD packages, dumb tarballs, executable installers, *everything*. I totally forgot about that. This means that we need to record the Python version (and/or the API version and marshall magic number) when we create the built distribution. Damn... wonder what the best way to do that is. I'm reluctant to jam one more piece of information into the filename: it's ugly, it's fragile, and it's may not be possible to retrieve when it's needed. I was just about to kill off the kludgey "package_data" file that Harry Gebel introduced to make bdist_rpm work... maybe something like that is needed after all, but to convey information from the packager's installation to the installer when running on the end-user's system.
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.
The way things are going is this: * the bdist_* command runs the install command, "redirecting" the installation into an alternate location. (It does this by setting the 'root' option, eg. to "build/bdist.linux2-i586/rpm", or "build/bdist.nt/wininst".) * by default, install_lib (called by install) byte-compiles .py files. (Soon, it'll probably create both .pyc and .pyo.)
Thus, .pyc (and maybe .pyo) files will be included in the built distribution for free. This makes the installer's job easier, less prone to mysterious errors, etc. etc. Apart from increasing the size of the installer by a factor of ~2-3, it's a win.
I realize this is back-pedalling on a decision made many moons ago, the result of which is that byte-compilation -- when building from source! -- is done at install-time rather than build-time. I have been known to change my mind six times before breakfast, though, so this is not a huge departure for me.
build_wininst will NOT generate c-code needed to be compiled.
Yes, I'm heading in this direction. build_wininst will certainly append metadata and files to be installed to a prebuilt stub program.
I hate to sound like I want *everything*, but it might be nice to make compiling the installer an option. As long as the stub isn't too big (30-50k?), getting a workable stub is more important -- especially if it lets me generate Windows installers on my Linux box!