[Distutils] Setting environment variables before building eggs w/ extensions using zc.buildout

[whit]

Martin Aspeli wrote:
> Nathan R. Yergler wrote:
>> I had a problem come up today that I've run into before, and I'd like
>> to figure out a way to prevent it from sucking my time down in the
>> future.  Several apps we run at Creative Commons use lxml
>> (http://codespeak.net/lxml) for XML, XSLT and XPath processing.  lxml
>> builds on libxml2, and provides an element tree interface, plus
>> additional capabilities.
>>
>> We use zc.buildout to assemble our server-side applications, and that
>> has generally been a huge sanity saver.  However, lxml can rob some of
>> that sanity periodically.  If a system like one of our CentOS machines
>> has an older version of libxml2 installed in /usr/lib, the extension
>> building process will link against it without complaint.  That is,
>> until you try to do something added in the later, recommended version
>> of libxml2 like XSLT.  Once you scratch your head and remember what
>> the problem is, you remember to export LD_LIBRARY_PATH=/usr/local/lib,
>> and then re-run the buildout.
>>
>> Does zc.buildout currently have any way to set an environment variable
>> during it's run?  I didn't see anything at
>> http://cheeseshop.python.org/pypi/zc.recipe.egg/, but I didn't know if
>> there was something at the zc.buildout level (as opposed to the recipe
>> level) that would do the trick.  The quick/dirty thing I'd do is
>> export the appropriate value of LD_LIBRARY_PATH.  The perhaps more
>> intelligent thing I'd do is use the cmmi recipe to build a version of
>> libxml2 that I *know* has the features I need as part of the buildout,
>> and then point LD_LIBRARY_PATH at that.
>>
>> Or has anyone else run into a similar situation, who might have some insight?
> 
> I would be interested in something like this, specifically for building 
> Deliverance.
> 
> Deliverance does have a buildout, that attempts to do this, but the 
> deliverance buildout is pretty rough. Or rather, it's not easily 
> re-usable, so if you want to build deliverance as part of a bigger 
> project, it can be tricky.
> 
> I'd be interested in seeing and/or helping out with such a solution 
> because I need to build deliverance as part of this project anyway, and 
> I'd like an elegant way to do it.
> 
> See http://www.openplans.org/projects/deliverance and 
> http://codespeak.net/svn/z3/deliverance/buildout/trunk/.
> 
> Martin
> 
>

fyi, the deliverance.buildout will soon go away

-w




-- 

------ d. whit morriss ------
- senior engineer, opencore -
- http://www.openplans.org  -
- m: 415-710-8975           -

"If you don't know where you are,
  you don't know anything at all" 


Dr. Edgar Spencer, Ph.D., 1995