[cc-ing this to the list] Steve Howe wrote:

Hello Martijn,

Thursday, August 18, 2005, 12:47:35 PM, you wrote:

...

Hm, what about leaving the binaries in the original location and writing a script that can download them when making the windows installer? I'd prefer to keep svn for maintaining the source for now, and by using a script we can ensure we get the right versions automatically, so we don't place a lot of burden on the person who runs the script to make the installer.

...

After all, we're not maintaining those binaries ourselves, and it's not unusual for package-build scripts to download stuff from the web. If zlatkovic.com tends to go down or something we can always move some of the packages onto codespeak's lxml website or something, and then download with the script from there.

I think the zlatkovic.com admins might not like a third-party script to be downloading from them (I would not like, for sure). Also, you guys plan to download the .zip package, unpack it, locate the dlls and install them somewhere the PATH ?

I'm not suggesting any end users use this script, just the people who prepare the windows package.

I think the best solution is having a regular lxml package and a separate one with just the dependency dlls. This way, when the libxml/libxslt gets updated, just that package needs to be downloaded, and the same for when lxml gets updated. This way, we can also keep lxml's download smaller, and who wants to get the libxml/libxslt packages from zlatkovic.com can do it themselves. The dlls package should be seen as a *courtesy*.

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