> 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/ ...  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 
> about
> needing a new setuptools.
> running 
> 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 
> redownloaded
> and rebuilt.
> Is there any way to move the setuptools check so that it occurs before the 
> wasted
> 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 
> fine.
> cd myproject; ../bin/python-bfg 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 
> normally.
> Should either be fixed or documented.  Seems pretty flaky to want .txt 
> files
> in ../bin anyway!

This is a buildout-related thing having to do with what the expression:


in bfg's results in under a buildout-generated Python "interpreter".

I've added some error handling to bfg's that will make your workaround
unnecessary in the next revision (0.5.4) of BFG.


- C

Repoze-dev mailing list

Reply via email to