Victor Ng wrote:
I wont' be able to touch it until later this week, but I'll just branch the trunk and reorganize everything into one source tree if nobody really minds.
Excellent! Let me know when you want a review and I'll take a look. I hope I will have a bit of time to work on lxml next week.
There's a couple bugs I need to squash and a good bit of restructuring that I'd like to get done so that I can start using this XML library in my day job. :)
I'm very curious to hear your thinking on using vlibxml2's system for memory management as a base for the rest of lxml's pyrex based stuff (etree, the dom). Do you think this would be easy or would a fairly large restructuring still be necessary? I guess I need to sit down and try to get some sample code working.
As for the automated build, at work, I setup a build process which basically runs distutils, runs the testsuite and then emails the results.
That sounds fine for starters, after the restructuring of the repository is complete so we have one distribution and one test runner to run all tests.
Alternately, we could overload the test runner to do some XML/HTML output a'la Cruise Control: http://cruisecontrol.sourceforge.net/. I'd really like to get some XML output generated when a test suite is completed - it would really make it easier to do stuff like a web status board.
I'll take a look at Cruise Control.
Anwyay - I'll concentrate getting the new file layout sorted out in a couple days. I'll probably mark the victree stuff as 'deprecated' or something. I'm not too interested in keeping it alive if etree does everything anyway.
That's certainly my aim; etree is intended to replicate the ElementTree API as well as possible. One part of victree that interested me was the implementation of ElementTree's path evaluation system on top of xpath -- we could fold that into etree.pyx. Regards, Martijn