I am currently trying to get buildout as my default deploy system however, I'm facing two issues for which I don't understand buildout well enough and for which I haven't found answers on the net.
My first issue is I need to get both numpy and matplotlib installed.
So I added both to the eggs section of buildout.
numpy seems to get downloaded and installed fine, however, matplotlib won't. The latest complains numpy isn't installed.
At this point, my guesses - after investigations - are that matplotlib checks numpy availability by importing it. However, as buildout has not set the numpy egg in the path, matplotlib fails and ends.
I have noticed there's a way to set headers and library path for compilers but I can't find a way to set the numpy's egg path, even when I move matplotlib to a section with the egg receipe.
Does someone know a way to get numpy eggs prepend to the paths so that matplotlib can detect it ?
My second question is, I also want to install pysvn. This package needs a patch to be setuptool friendly. I would like to know if there's a simple way within the buildout.cfg file to apply a patch to a package before it gets eggified ?
At 10:45 AM 7/28/2010 +0200, Hartmut Goebel wrote:
>Am 27.07.2010 22:38, schrieb P.J. Eby:
> > "easy_install -eb tmpdir requirement" will download and unpack source
> > (or check out from svn:) to tmpdir/projectname (with projectname in
> > all-lowercase).
>Unfortunately this does not install from source.
"easy_install -eb tmpdir requirement && easy_install
tmpdir/projectnameinalllowercase" will, though. (As will
"easy_install -eb tmpdir requirement && cd tmpdir/projectnamelower &&
python setup.py install", though this latter choice may or may not do
an egg-based install.)
The zc.recipe.egg:custom recipe allows the specification of build
options for a custom egg. But what do we do if we want to specify
custom build options for an egg that is a dependency of a recipe (or
perhaps the recipe itself)?
Case in point
We have a recipe, erp5.recipe.mysqldatabase, that uses the
MySQL-python. However, since we have a non-distribution installation
of MySQL (we need to patch it with the Senna full text index), we need
to pass compilation instructions to MySQL-python so that it actually
finds the correct MySQL include and lib directories, which we do
This works for buildout parts with recipes based on zc.recipe.egg
(e.g. collective.recipe.zope2instance), even if some of the eggs
mentioned depend on MySQL-python, as long as the zc.recipe.egg:custom
part for MySQL-python runs first.
But if the recipe itself depends on MySQL-python, we don't get the
opportunity to pass custom build options to MySQL-python, since
buildout will try to satisfy the recipe dependencies of all parts even
before installing the zc.recipe.egg:custom part.
zc.buildout has APIs   for passing custom build options for
eggs, but appart from zc.recipe.egg:custom, I couldn't find any way to
use these APIs for dependencies of recipes.
Since we can specify versions for eggs by specifying a section with
version information, I was hoping that we could also specify build
options somehow. Since there are many pieces of information (including
environment variables). I think that we'd need a whole section for
each egg. Something on the lines of:
build-options-sufix = -options
# options like the ones for the zc.recipe.egg:custom recipe
Is there something like this available, and I just missed it?
Can something like this be implemented as a buildout extension?
PS: Conversely, it would also be nice to be able to specify different
"versions" sections per zc.recipe.egg part instead of a single global
one, exactly so that we can compare different version combinations
with a single buildout.
like other people, I'm experiencing some problems with binary dists and
eggs across different linux distros. Is it possibile to tell
easy_install or pip just to ignore any egg or bdist which can be found
on the index and just use the sdist? And is there any way to integrate
such behaviour with zc.buildout automatic dep fetching?
I have made a beta release of zc.buildout 1.5.0.
Among other changes, this release includes the ability to use zc.buildout with a system Python, if you use the new z3c.recipe.scripts instead of zc.recipe.egg for generating scripts.
In my experience, working with a system ("non-clean") Python can be fragile in many ways. However, this release addresses the problems I have encountered so far.
Your feedback is welcome. I hope to make a final release sometime next week.
I'm wondering how to reproduce the equivalent of "make -j<n>" on a
In my setup, I'm using distutils.Extension to build a C(++, somehow)
extension to Python 2.6. I have a few dozens files in the "sources"
parameter of the Extension module and I would like to get a chance to
use my multi-core CPU to speed up my extension's build.
My desired outcome: having setup.py build using a few instances of my
C-compiler in the same time, instead of only one.
There are probably an environnement var or two that I'm missing. Or
maybe it could be an interesting feature for distutils2 ?
Thank you for your help.
Florian Le Goff
I was going to update zc.buildout to use doctest instead of
zope.testing.doctest and zope.testrunner instead of
zope.testing.testrunner, and I noticed trunk has some failing tests.
They all use the --setup-source option, but:
bootstrap.py: error: no such option: --setup-source
So there is something wrong there. I'll probably comment those failing
tests out for the moment, unless somebody fixes them or tells me to
remove them completely. :-)
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python3porting.com/
+33 661 58 14 64