On 03-11-14 10:22, Reinout van Rees wrote:
Turns out the `env.best_match(req, ws)` fails on anything that is
installed globally with a version that doesn't match the one we want.
In my colleague's case, he has nose 1.3.1 installed globally.
Buildout has a pin on 1.3.4.
env.best_match() returns a VersionConflict.
So it seems we should ignore that too.
I'm on to something.
The `env.best_match()` works based on the working set. So: why is the
working set filled with all the system stuff? Normally the working set
starts out empty!
I did a bit of extra logging and found out that buildout extensions and
buildout recipes get installed with a system-wide working set. Regular
requirements are installed based on a n empty working set.
The problem I'm seeing is with pbp.recipe.noserunner (ancient, but
handy). This has a dependency on "nose" which it finds globally with a
wrong version.
The other problem is with collective.recipe.sphinxbuilder, which depends
on jinja2 which is installed globally in some cases ("I need ansible
installed globally").
=> Why does the buildout install and the extension/recipe install start
out with a full-blown working set? It might be a left-over from the time
when we used the globally installed setuptools. The newest bootstraps
make this unnecessary, right?
Reinout
--
Reinout van Rees http://reinout.vanrees.org/
[email protected] http://www.nelen-schuurmans.nl/
"Learning history by destroying artifacts is a time-honored atrocity"
_______________________________________________
Distutils-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig
