[Distutils] WinNT and distutils
Mon, 31 Jan 2000 09:34:29 -0500
On 28 January 2000, Greg Stein said:
> Some people have suggested that distutils does some of its install work
> via the new import stuff.
> I'm not sure what that entails (I don't understand why distutils would
> need the custom importing/packaging that imputil provides).
I agree with you: I don't understand why distutils would want to depend
on imputils. It seems desirable for distutils to be able to generate
archives (or whatever) that can only be imported from using imputils,
but I don't see a need to take it farther than that.
One can speculate about a world where Python module distributions are
distributed as archives with a __run__.py (JPython convention brought to
my attention by Barry) that is the setup script. But I think Python
itself would have to grok the archive and its __run__.py, and anyways
that all seems rather far out at this point.
> It won't work until 1.6 because we don't have the 1.6 design yet :-)
> But, there is no reason it shouldn't (with some creative try/except around
> some imports). Note that win32api isn't going into 1.6 -- either a new
> module from scratch, or a small extraction of win32api. In any case, it
> certainly won't (can't) be called win32api.
Ahh, OK, I wasn't really clear on that. I had a vague idea that some
sort of registry access would be in 1.6, I gather that Mark's win32api
provides registry access, and thus I assumed that something called
win32api would be in 1.6. So much for blithe assumptions.
So it seems to me as if something like the following will be needed:
import win32api, win32con
get MSVC++ registry keys from it
do the same thing with whatever the official Python 1.6 registry
access mechanism is
just assume cl.exe is on the path
if we got the MSVC++ registry keys:
use Robin Becker's code to figure out where cl.exe is supposed to be
Ugh. This is starting to look like writing an autoconf script. At
least it's not in Bourne shell... >shudder<... I guess for now I should
stick with the code Robin provided, since there is no "official Python
1.6 registry access mechanism" yet.