[lxml-dev] lxml Mac installation idea

[Paul Everitt]

On Nov 2, 2008, at 2:55 PM, Stefan Behnel wrote:

> Hi Ian,
>
> Ian Bicking wrote:
>> Stefan Behnel wrote:
>> but I'd like it to work without buildout, and there's also several
>> buildout recipes and configurations out there and not one clear
>> canonical way to build lxml.
>
> I wouldn't mind to ship lxml with a buildout recipe. I think the  
> current
> problem is that if we wait to find one that works well for as many  
> people as
> possible, we'll wait forever. So I'm fine with adding any script  
> that's
> somewhat tested and in use. Even a set of scripts that you can try  
> is better
> than none if people can't manage to build lxml themselves.

FWIW, we have a very lean buildout that only focuses on the problem of  
building lxml.  I could contribute it if you'd like.

>>>> Another option would be simply a different tarball that contains  
>>>> the
>>>> libxml2/libxslt source, and its setup.py would always build those.
>>>> It could be versioned like 2.1static or something, which should  
>>>> keep
>>>> it from being implicitly used by easy_install, etc. (since  
>>>> 2.1static
>>>> is considered an earlier version than 2.1).  This might be more
>>>> reasonable?
>>>
>>> The problem with this (and with the static Windows builds) is that
>>> libxml2/libxslt both have their release cycles, which are  
>>> independent of
>>> lxml's releases. If you want to upgrade your libxml2 in a static
>>> build, you'll have to copy it to the right place anyway.
>>
>> Another option is yet another environmental variable to set the
>> libxml2/libxslt versions, which are set to defaults.  If you chose a
>> version that didn't exist in the tarball it'd download that version.
>
> What about providing a script that checks for the most recent  
> version first,
> and then builds lxml with that? The "LATEST_IS_X.Y.Z" file in the  
> libxml2 FTP
> directory will help here. Then it's fine to override the latest  
> version with
> an env variable if people need to.
>
>
>>>> Maybe the two versions could be arranged with some svn:externals,
>>>
>>> You mean lxml and libxml2? That would mean you either build libxml2
>>> from a tag
>>> (implying the same problems as with a shipped, ready-to-get-outdated
>>> version),
>>> or from the trunk, which is definitely not suitable for most users.
>>
>> No, I was just thinking about ways of structuring a full build (that
>> includes the libxml2 library) and the current build.
>
> Shipping with the latest libxml2/libxslt is not a big problem,  
> setup.py could
> be changed to support a "--all-sources" option for sdist. There  
> could be a
> separate tar.gz (or zip) file on PyPI that easy_install won't find  
> at all. And
> when the build detects that the libxml2 and libxslt sources lie next  
> to the
> src directory, it can switch to a static build automatically.

That sounds pretty good.

>> I do now have ssh access to a Mac.  Unfortunately it's behind our  
>> VPN,
>> so I'm not sure if I can get you access to it too, but I'll ask  
>> about that.
>
> I'm still waiting for the usual "we can pay you the hardware, so  
> that you can
> do the testing yourself" offers. ;o)

I'll chip in.  I wonder if there are OS X hosting companies where we  
could rent a login.

--Paul