[Distutils] Thinking about a Windows Installer

[Greg Ward]

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.

Yes.

> 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!

        Greg
-- 
Greg Ward - just another Python hacker                  gward@python.net
http://starship.python.net/~gward/
I appoint you ambassador to Fantasy Island!!!