Sigh..., I am back from vacation and as far as I can see, there are no comments except from Gordon. And it looks like all I have managed to do is get Gordon mad at me :-(
Gordon McMillan wrote:
James C. Ahlstrom wrote:
I published a proposed library file format here on distutils and it is described in the doc strings. But I didn't describe why I didn't use Greg's nor Gordon's format. Both formats remove the 8-byte .pyc header. But import.c validates this header for .pyc files and it should be retained.
Why? So import.c can try to recompile from non-existant source?
If you let Greg or me build the archive, you'll find that the compiles get done if they're needed. Then the package contains a python and .pyc's that match that version.
With or without a check, a mismatch will produce an ugly mess.
I am not saying the myprog.pyl file is created incorrectly nor that the version does not match python.exe.
The point is that mylib.pyl is a separate file, and so it may be out of phase with python.exe because the user upgraded python.exe but not mylib.pyl.
Currently Python will import a file.pyc even if there is no file.py present. If that file.pyc has a bad magic number then Python throws an ImportError. I think a myprog.pyl file is exactly analogous.
There was no file source information, but a user will want to print out the file names in the library.
If they want to, the can get the name from the module's __importer__ attribute. They have everything they need to call archive.contents(), too, (if you're letting them get to an interpreter prompt).
I don't understand. I want to check which files were used to create myprog.pyl, and this can only be recorded in myprog.pyl. I don't want the module names "sub1", I want "C:/path/to/sub1.py". This could be used as a check before a product is shipped. But I guess I can live without it.
Greg's format could not be appended to another file. Gordon can build the library onto another file with a program, but can not append the same file to different programs.
Um, you mean because there's a "os.remove()" in Builder.py?
Builder.py is mostly concerned with parsing the config file and determining dependencies. The actual archive building is done by the archive class, with some utility functions in archivebuilder.py.
My statement stands. I was hoping to ship myprog.pyl and allow the recipient to use "cat myprog.pyl >> python.exe" if they wanted. I know I can re-make a new python2.exe for each system.
I realize you don't like having to have four .py files in the current directory. I don't like messing with python internals, especially when (among other things) you can use this to distribute a stripped down but otherwise standard python.
I agree that changing Python internals is usually bad, and your design has the very great advantage that no changes are required.
I will throw out my design and re-start using your software. But since I have tried this before I know it won't work. But maybe I can come up with a more minimal set of changes.
In addition, both Greg & I are hoping (with some encouraging signs) that his imputil will attain sanctified status, which would probably mean that something like this could be done with just one 'extra' file.
But in the meantime, are you sure you can't get the same effect by using normal embedding techniques in the .exe (ie, instead of just calling Py_Main?). (Well, not quite normal techniques, since you have to use GetProcAddress).
The best I came up with so far is to use freeze to incorporate my Python files in a DLL, and then use a special main to link in the frozen modules. This currently works, but it is not ideal.
I am going away on vacation tomorrow, so I really hope all this works OK. I will catch up on all your comments when I get back.
Have a good time.
Thanks. I went scuba diving for a week, and then went on a one week cruise with a large family group in honor of my mother's 80th birthday. It was great fun!