Mark Hammond wrote:
I havent been following this thread as closely as I would like,
That's OK, I missed out on the prior distutils-sig discussions anyway.
but I am a little confused. Are we building yet another packager here, or is this work building on the work Gordon currently "owns"?
It is not another packager. It provides a way to bootstrap Gordon's installer without requiring exceptions.py etc. to be found with the usual sys.path mechanism. All Python files can be in the library files. This has to be done with C code.
If I recall correctly, when Greg posted his version of what grew into Gordon's, there was discussion over the direction import.c should take. Are your patches in line with that?
I hope so. The "makepyl.py" program for making library files is almost identical to Greg's easygen.py, and I wrote his name at the top. But I did alter the file format so that it could be appended to python15.dll, and so source names could be listed. I am open to any file format that works. I was hoping that we could finalize the format in this sig. It doesn't have to be my format. I read all prior distutil-sig archives, but in case I missed something, could you provide a reference to the discussion you are referring to?
Im just thinking that poor Guido has already discussed this once, so may be reluctant to accept new hacks when the correct direction has been mapped out. As far as I can see, Gordon's code works fine without C level changes, so Im a little unsure what direction this is going, and exactly what this is solving that Gordon's doesnt.
I solves the bootstrap problem. Any Python-only solution has to read several Python *.pyc files before it can get started. This requires using the regular sys.path mechanism which is what I am trying to replace. My C code can be used to boot up Gordon's installer. Also note Marc's mxCGIPython project. He has valiantly collected dozens of binary frozen library versions just so someone can install Python on their server without a hassle. A portable Python library file is a good idea. I got serious about this because of the recent thread started by Mikael Lyngvig in c.l.p. We really need a way to enable bullet-proof Python program distribution on machines where Python is not installed, on machines which have an invalid Python distribution, and on machines which have a valid Python but the wrong version. It is my perception that we are not there yet. Jim Ahlstrom