> Platform current Debian Sid python2.5.
> 0) nothing to do with repoze.
> virtualenv -p python2.5 ... does not work.
> python2.5 /usr/lib/python2.5/site-packages/virtualenv.py ... is fine.
> Also, current Debian may have multiple python-dev packages, choose
> version you need, as in python2.4-dev or python2.5-dev. python-dev
> is a virtual package giving the current default python's package, and
> no older or more recent versions.
> 1) I don't know if this is easy to fix, but I suspect it is. buildout
> downloaded and
> built libxml2 and libxslt as expected. buildout then died, with a message
> needing a new setuptools.
> bin/python-bfg -U setuptools
> as in the failure message installed setuptools fine.
Yeah; this is the right fix.
> Then the freshly built libxml2 and libxslt were deleted, the tarballs
> and rebuilt.
> Is there any way to move the setuptools check so that it occurs before the
> download/build cycle?
This would be a fix to zc.recipe.cmmi I believe, although I don't know what.
You could also try adding this line to your [buildout] section:
download-cache = somedirectory
That might at least prevent buildout from redownloading the libx* software.
FTR, this is a one-time fix, I believe.
> 2) built a project from the template per instructions. bin/paster was
> cd myproject; ../bin/python-bfg setup.py test -q
> did not run. Failed because it could not find ../bin/README.txt.
> touch ../bin/README.txt
> and then rerun.
> Now fails on ../bin/CHANGES.txt. touch and rerun, and it complete
> Should either be fixed or documented. Seems pretty flaky to want .txt
> in ../bin anyway!
This is a buildout-related thing having to do with what the expression:
in bfg's setup.py results in under a buildout-generated Python "interpreter".
I've added some error handling to bfg's setup.py that will make your workaround
unnecessary in the next revision (0.5.4) of BFG.
Repoze-dev mailing list