
[cc-ing this to the list] Steve Howe wrote:
I'm not suggesting any end users use this script, just the people who prepare the windows package.
But this makes installation on Windows harder -- it requires people to at the very least download and install two packages, possibly even from multiple locations. I think an installer should make life as easy as possible. A developer who wants to use lxml downloads one package, installs it, and gets going. People who want or need control (such as people who want to bundle lxml with a larger application with an installer of its own, or lxml developers on Windows) can arrange things their own way still, of course. In addition, packaging everything needed for lxml into one package also makes it easier to control which version of libxml2 is used by lxml on Windows (not all combinations might work, after all). I see this as a good thing. While newer versions of lxml might work with older versions of libxml2 and newer versions of libxml2 might work with older versions of lxml this is not always guaranteed. It's better to have a stable combination of lxml and libxml2 (per lxml release) that we support (open-source-ly) on Windows, and for anything else you're on your own. A digression: I've seen some of the problems brought by various combinations of the Python XML core libraries, PyXML and 4suite. While I don't expect libxml2/lxml combinations to be that troublesome (the PyXML situation with Python is special), I'd like to avoid something even remotely similar with lxml -- I've experienced how difficult it made life for developers using PyXML. I think we should reserve the right to say "lxml 0.foo is only supported with libxml2 version bar.baz, anything else you're on your own", when we need to. (on any platform). We're not doing this now, and hopefully we don't have to as libxml2 is stable enough, but I still want to be able to say such a thing in the future if necessary. Something interesting to investigate in all this may be the recent developments in the Python world like setuptools and Python eggs for distribution of Python packages. I haven't had any experience yet with those, but I think there's some dependency management in play. Dependency management might be a good compromise; it makes installation easy while retaining separation between packages. Whether the recent Python package management developments can actually do this I don't know, however -- the libxml2 dlls are not a python package after all. Perhaps someone can investigate this and report to the list. Regards, Martijn
participants (1)
-
Martijn Faassen