I'd really like to keep vlibxml2 and lxml separate. This is mostly for technical reasons as the libxml2 library has some really quirky behavior in it's API.
So what about a source distribution that contains both libraries (if they're done at all, vlibxml2 is obviously much further in that department)? vlibxml2 contains a lot of very important foundational work concerning memory management that I hope we can get the higher level lxml stuff to use as well after a bit of refactoring.
So, what I'm proposing is merging the vlibxml2 into lxml's 'src' directory, but being its own package. What do you think? Of course we'd also need to figure out what to do with the extensions package; I'm not familiar enough with vlibxml2's source layout to know where everything goes. Ideas?
Sounds good to me. Phillip has set me up on SVN at codespeak now. I'll check in my code tonight, make a branch and play around with source layout and maybe we can come to an agreement on how everything should fit together.
If you'd like and can come up with a good name, we could rename the whole 'lxml' distribution into something else that may be more neutral. We could then call it all <foo>.libxml2, <foo>.libxslt, <foo>.dom and <foo>.elementtree. I.e. one top level package to make the namespaces clear, with sub-modules/packages that offer particular functionalities. vlibxml2 would become 'libxml2'. Though perhaps this all promises *too* much API compatibility with the original libxml2/elementtree/etc for us to feel comfortable about?
Naming is pretty low on my priority list. I don't want to have vlibxml2 renamed to libxml2 mainly because libxml2 will have a superset of features for the foreseeable future. I'm going to take a crack at learning SWIG to see if I can close that gap a little faster though. Maybe close the gap entirely. :) vic