Christopher Barker wrote: > Greg Ewing wrote: >> I've been thinking for a while about creating something >> simpler that doesn't attempt any automatic module discovery >> at all. You would be required to construct a project file >> that explicitly lists all the required modules and libraries, >> including standard library modules. > > I've thought for a while that there is way too much re-invention of the > wheel with the various stand-alone builders. I'd love to see more > flexibility, and ideally code sharing, by breaking down the process into > the various parts: > > [...] > So, aside from allowing more code sharing, this approach would make it > easier to plug in different pieces, like Greg's proposed manual > specification of modules. > > As for that proposal -- I agree with other posters that that really > would be onerous. However, a hybrid would be great -- run some sort of > automated tool that outputs an easy-to-read-and-edit text file that > could be edited, and have the bundle builder use that. Then you culd > e3dit it, write it frm scratch, whatever you like.
Is anyone here familiar with Py++ [1]? What Christopher describes reminded me very much of that tool. Py++ is not a tool to produce standalone packages like py2app does, instead it's a tool to generate Python bindings for C/C++ libraries, but it seems their inner workings share similarities. Just like py2app has to find out what modules get imported by an application, Py++ needs to find out what functions/classes are in a library and which of them need to be turned into Python functions/classes. Py++ does that by running gccxml on the header files to extract the contents of the files which is then further processed. For simple libraries it might be enough to let Py++ just convert everything it finds in the headers, but for more complex libraries you want to customize that and leave out some stuff. Now the thing is, Py++ is not implemented as a standalone tool you just run on some input files, but instead, it's a framework for writing wrapper generators. This means, the user writes the main script (in Python) which invokes Py++ functionality and this means the actual control of the entire process is in the user's hands. In simple cases, it's enough to leave everything up to Py++ which means your main script will be very short. But if you want to, you can intercept any step in the processing pipeline and modify the data. For example, as mentioned above, the first step is to get the declarations from the header files which builds a tree of declarations that's stored in memory. Before the tree is passed on, your main script can inspect and modify it. You could even choose to skip that gccxml step entirely and produce the declaration tree by some other means. Subsequent Py++ steps just work on that tree, it doesn't matter anymore who created it. After that, the wrapper source code is generated which is again a tree of text blocks. Before this tree is written to disk to generate the source files, you can again intercept this and modify the tree. This design makes Py++ very flexible because you can inject your own logic into the pipeline to tailer the process to your needs. Now it sounds like exactly the same thing could be done in py2app (which I have never used so far, by the way, but from reading the mails here it sounds like it doesn't already provide this sort of flexibilty). Its first step is to find out what modules need to be included. If this produces a well-defined data structure with an API to modify/create it and the user gets the chance to modify that data before it's passed on (or even recreate it from scratch), then all use-cases that have been mentioned here could be handled by the same tool. Sorry if this all doesn't make any sense or py2app already has different means of achieving this flexibilty. As I said, I haven't used py2app yet (but it's on my todo list to try it out), it's just because Christopher's mail sounded so much like Py++ that I thought I'd chime in for a moment. Cheers, - Matthias - [1] http://www.language-binding.net/ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
